Не нашёл описания методологии выполнения тестирования. Как замерялось время (timeit в Python, time в Bash?), сколько проходов каждого теста использовалось для усреднения результатов? Использовались ли одни и те же файлы, либо же каждый раз создавались новые?
Воспроизводимость. Куски кода, это хорошо, но желательно ещё добавить ссылку на репозиторий с проектом тестирования, чтобы любой желающий мог проверить результаты через автоматизированный скрипт работающий с создаваемой на лету tmpfs. Скажем так, те, кто ходил по врачам и знакомы с понятием доказательной медицины (включая такие понятия как предвзятость), скорее всего пройдут мимо этой статьи, пролистав её до конца.
Путаница в терминологии. Вы сравниваете не Bash и Python, а библиотеки Python и команды UNIX-подобных систем. Они никакого отношения непосредственно к языкам не имеют. Например, Awk — это вполне самостоятельный парсер, который ничего не мешает вызывать напрямую из Python минуя командный интерпретатор. А pandas в Python не входит, в Python входит модуль csv.
Неправильно подобранные решения/алгоритмы для сравнения. При анализе логов в Python используется медленная регулярка, а в Bash — нет. Самым примитивным решением в Python будет split() для разделения на колонки, а не регулярки. В случае сокетов и использования disk_usage из shlibs вообще не должно быть сильно большой разницы между языками, как мне кажется. Там всё будет зависеть больше от скорости работы системных вызовов и работы почтового сервера (в том числе всевозможных задержек). Поэтому сразу возникает вопрос, а что тут замерялось-то со стороны языков? А если скрипт многократно запускался, то у Python инициализация самого интерпретатора и модулей в разы медленнее, чем у Bash (см. ниже).
Собственно, инициализация интерпретатора в Bash намного быстрее, чем в Python. Но это касается лишь инициализации, а не длительной работы скрипта. То есть многократный запуск маленького быстрого скрипта на Python будет медленнее, чем на Bash. Это учитывалось? В статье эта информация должна быть отражена, поскольку может оказывать значительное влияние на само тестирование, искажая его результаты.
Про пробелы — PEP 8 не рассматривает случаи, когда каждое значение функции указывается на отдельной строке. А в этом случае читабельнее код именно с пробелами. Тут приходится мириться с предупреждениями IDE.
Разница должна была быть, если бы кавычки попытались добавить с экранированием. А те, кто пришли из Сишки, Питона и подобных языков, наверняка бы это попытались сделать. То есть теоретически таких может быть большинство читающих людей статью. И тут возникла бы интуитивно непонятная ошибка, которая легко решается через использование косых кавычек, которые, в свою очередь, делают код плохо читаемым (еле заметны).
Уже неактуально, я прямо в статью добавил информацию о разнице между `` и $(). Эта ветка обсуждений явно пошла вообще не в то русло, поэтому эта тема стоит разбора прямо в статье.
Список файлов в каталоге Рабочий стол, если вложенная команда была с опцией -d. Если в каталоге ничего нет, просто ничего не покажет. Суть задачи именно в правильной расстановке кавычек, сама команда особого смысла не имеет. То есть не должно выдаваться сообщение об ошибке (предполагается, что каталог существует).
Окей, колоризованный вывод команда по умолчанию не делает, за это отдельная опция, которую надо включать, поэтому в таких ситуациях сразу надо проверять, не выставлен ли случаем алиас и что вообще запускается через:
type ls
which ls
Покажите вывод этих команд, пожалуйста.
Но еще покажите, пожалуйста, вывод решения квеста, скажу его, раз уж решать его все равно, судя по всему, никто не намерен:
set -e
cd ~/'Рабочий стол'
/bin/ls "`/bin/ls -d \"${PWD}\"`"
Я с телефона набирал это сообщение, команды не проверял, но вроде правильно написал.
Семантику, то есть не чисто синтаксис, а то, как он используется в совокупности с командами, насколько понятен код. Синтаксис как раз почти не рассматривал. Про синтаксис Python можно почитать тут, например, это наборы правил, что и как писать:
По примерам из написанной мной статьи видно, насколько удобен и читабелен язык в тех или иных ситуациях, насколько интуитивно его использование в тех или иных ситуациях.
Для примера, Python без доп. библиотек для запуска процессов и создания между ними конвейеров не очень удобен, в то время как Bash очень интуитивен.
А вот при математических вычислениях уже неудобен Bash, особенно если учитывать, что работа на самом деле ведется со строками, которые переводятся в числа и назад.
Опция -d выводит информацию только о самом каталоге. Без других опций там колонка будет только одна - то же самое имя, которое подавалось в качестве аргумента.
На самом деле cat не выдаст абсолютно такой же результат. В моем примере после номеров строк точки стоят. Придётся ещё команду sed использовать, чтобы один в один сделать. .
Но пример именно такой, поскольку необходимо было дать пример циклов со счётчиком. А сторонние команды я использовал по-минимуму, поскольку к bash они непосредственно не относятся, а статья именно по bash. Ну и на этом моменте статьи нужно было стараться использовать уже рассмотренные в статье возможности. То есть от простого к сложному с как можно меньшим забегает наперёд. Классический подход в подаче обучающих материалов.
Когда я писал "тавтологию" из двух ls, я думал, что будет понятно, что суть квеста в исправлении кавычек, а не команды. Иначе б квестом это не называл и придумал бы пример из реальной жизни. :)
С Vala пришлось бы разбираться и читать документацию, поскольку на Vala до сих пор не писал, ушло бы больше времени. Статья же родилась в ходе тестового задания, на которое мне давали неделю (дерево с ленивой подгрузкой данных). Я и так выбрал GTK 4 с расчётом написания статьи на Хабр, зная, что большая часть времени уйдёт на эксперименты, чтение документации и изучение существующих примеров (которых почти нет), поскольку до этого работал только с GTK 3. А так, да, с Vala код был бы читабельнее, хотя своего какого-либо мнения (плюсы/минусы) у меня по этому языку пока нет.
Оформление обычно в CSS задаётся (хотя для графических библиотек некоторая часть указывается в коде). В рамках окружения рабочего стола CSS для GTK задаётся темой оформления. Для разных устройств можно создавать разные темы оформления. На свой вкус можно менять уже существующие.
Можно было бы в одной теме всё задать, но в GTK не поддерживается @media. Нашёл тему об этом ещё 2016 года, там же объясняется, почему поддержку правила @media до сих пор не добавили в GTK: responsive design.
Чем же это может вредить? С таким же успехом навредить может кастомизация горячих клавиш. Мне не нравится F2 для переименовывания файлов, я её на другое действие переназначаю. Алиасы предназначены для катомизации терминала под себя, как будет удобно именно отдельному человеку. Из людей, с кем я работал, один взял мой вариант, а другой сделал себе свои, совсем другие, алиасы.
Что касается пересечений с названиями команд, то писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами. Если часто требуется выполнять эту команду из консоли, то можно не прописывать автоматическое подключение алиасов в bashrc, а инициализировать их раз в день в рабочей консоли отдельной командой. Либо же подобрать другое название, например, dc (diff, color).
И если уж называете вредительсвом, то давайте расшифровку того, что имеете в виду, какие именно случаи, и какой вред в этих случаях алиасы могут нанести.
Поделиться существующей практикой и идеями. Я уже достаточно давно использую алиасы, они оказались намного удобнее, чем вводить команды целиком, причём именно в таком виде, легко запоминаются, нет никакой путаницы, действия доводятся до автоматизма. Собственно, основной моей деятельностью в консоли является работа с git.
Ну и в интернете список алиасов всегда под рукой. :)
К статье есть много замечаний.
Не нашёл описания методологии выполнения тестирования. Как замерялось время (timeit в Python, time в Bash?), сколько проходов каждого теста использовалось для усреднения результатов? Использовались ли одни и те же файлы, либо же каждый раз создавались новые?
Воспроизводимость. Куски кода, это хорошо, но желательно ещё добавить ссылку на репозиторий с проектом тестирования, чтобы любой желающий мог проверить результаты через автоматизированный скрипт работающий с создаваемой на лету tmpfs. Скажем так, те, кто ходил по врачам и знакомы с понятием доказательной медицины (включая такие понятия как предвзятость), скорее всего пройдут мимо этой статьи, пролистав её до конца.
Путаница в терминологии. Вы сравниваете не Bash и Python, а библиотеки Python и команды UNIX-подобных систем. Они никакого отношения непосредственно к языкам не имеют. Например, Awk — это вполне самостоятельный парсер, который ничего не мешает вызывать напрямую из Python минуя командный интерпретатор. А pandas в Python не входит, в Python входит модуль csv.
Неправильно подобранные решения/алгоритмы для сравнения. При анализе логов в Python используется медленная регулярка, а в Bash — нет. Самым примитивным решением в Python будет split() для разделения на колонки, а не регулярки. В случае сокетов и использования disk_usage из shlibs вообще не должно быть сильно большой разницы между языками, как мне кажется. Там всё будет зависеть больше от скорости работы системных вызовов и работы почтового сервера (в том числе всевозможных задержек). Поэтому сразу возникает вопрос, а что тут замерялось-то со стороны языков? А если скрипт многократно запускался, то у Python инициализация самого интерпретатора и модулей в разы медленнее, чем у Bash (см. ниже).
Собственно, инициализация интерпретатора в Bash намного быстрее, чем в Python. Но это касается лишь инициализации, а не длительной работы скрипта. То есть многократный запуск маленького быстрого скрипта на Python будет медленнее, чем на Bash. Это учитывалось? В статье эта информация должна быть отражена, поскольку может оказывать значительное влияние на само тестирование, искажая его результаты.
Попавил, спасибо за замечание. Разумеется, непривычно он выглядит по сравнению с остальным кодом на bash.
Про пробелы — PEP 8 не рассматривает случаи, когда каждое значение функции указывается на отдельной строке. А в этом случае читабельнее код именно с пробелами. Тут приходится мириться с предупреждениями IDE.
Кстати, спасибо за ответ! Мне никогда даже в голову не приходило косые кавычки без экранирования попробовать. Что-то новое узнал. :)
Разница должна была быть, если бы кавычки попытались добавить с экранированием. А те, кто пришли из Сишки, Питона и подобных языков, наверняка бы это попытались сделать. То есть теоретически таких может быть большинство читающих людей статью. И тут возникла бы интуитивно непонятная ошибка, которая легко решается через использование косых кавычек, которые, в свою очередь, делают код плохо читаемым (еле заметны).
Уже неактуально, я прямо в статью добавил информацию о разнице между
``и$(). Эта ветка обсуждений явно пошла вообще не в то русло, поэтому эта тема стоит разбора прямо в статье.Выполните команду
lsи увидите. К чему такой странный вопрос?Список файлов в каталоге Рабочий стол, если вложенная команда была с опцией -d. Если в каталоге ничего нет, просто ничего не покажет. Суть задачи именно в правильной расстановке кавычек, сама команда особого смысла не имеет. То есть не должно выдаваться сообщение об ошибке (предполагается, что каталог существует).
Окей, колоризованный вывод команда по умолчанию не делает, за это отдельная опция, которую надо включать, поэтому в таких ситуациях сразу надо проверять, не выставлен ли случаем алиас и что вообще запускается через:
Покажите вывод этих команд, пожалуйста.
Но еще покажите, пожалуйста, вывод решения квеста, скажу его, раз уж решать его все равно, судя по всему, никто не намерен:
Я с телефона набирал это сообщение, команды не проверял, но вроде правильно написал.
Семантику, то есть не чисто синтаксис, а то, как он используется в совокупности с командами, насколько понятен код. Синтаксис как раз почти не рассматривал. Про синтаксис Python можно почитать тут, например, это наборы правил, что и как писать:
https://docs.python.org/3/reference/grammar.html
По примерам из написанной мной статьи видно, насколько удобен и читабелен язык в тех или иных ситуациях, насколько интуитивно его использование в тех или иных ситуациях.
Для примера, Python без доп. библиотек для запуска процессов и создания между ними конвейеров не очень удобен, в то время как Bash очень интуитивен.
А вот при математических вычислениях уже неудобен Bash, особенно если учитывать, что работа на самом деле ведется со строками, которые переводятся в числа и назад.
Опция -d выводит информацию только о самом каталоге. Без других опций там колонка будет только одна - то же самое имя, которое подавалось в качестве аргумента.
На самом деле
catне выдаст абсолютно такой же результат. В моем примере после номеров строк точки стоят. Придётся ещё команду sed использовать, чтобы один в один сделать. .Но пример именно такой, поскольку необходимо было дать пример циклов со счётчиком. А сторонние команды я использовал по-минимуму, поскольку к bash они непосредственно не относятся, а статья именно по bash. Ну и на этом моменте статьи нужно было стараться использовать уже рассмотренные в статье возможности. То есть от простого к сложному с как можно меньшим забегает наперёд. Классический подход в подаче обучающих материалов.
Когда я писал "тавтологию" из двух ls, я думал, что будет понятно, что суть квеста в исправлении кавычек, а не команды. Иначе б квестом это не называл и придумал бы пример из реальной жизни. :)
Поправка, забыл параметр
-dуказать, чтоб именно информацию о каталоге выводила ls:Квест предлагаю. Кто сможет заключить переменную в кавычки в следующем примере?
С Vala пришлось бы разбираться и читать документацию, поскольку на Vala до сих пор не писал, ушло бы больше времени. Статья же родилась в ходе тестового задания, на которое мне давали неделю (дерево с ленивой подгрузкой данных). Я и так выбрал GTK 4 с расчётом написания статьи на Хабр, зная, что большая часть времени уйдёт на эксперименты, чтение документации и изучение существующих примеров (которых почти нет), поскольку до этого работал только с GTK 3. А так, да, с Vala код был бы читабельнее, хотя своего какого-либо мнения (плюсы/минусы) у меня по этому языку пока нет.
Оформление обычно в CSS задаётся (хотя для графических библиотек некоторая часть указывается в коде). В рамках окружения рабочего стола CSS для GTK задаётся темой оформления. Для разных устройств можно создавать разные темы оформления. На свой вкус можно менять уже существующие.
Можно было бы в одной теме всё задать, но в GTK не поддерживается
@media. Нашёл тему об этом ещё 2016 года, там же объясняется, почему поддержку правила@mediaдо сих пор не добавили в GTK: responsive design.Большое спасибо за пояснение! Действительно. Этого момента не знал.
Чем же это может вредить? С таким же успехом навредить может кастомизация горячих клавиш. Мне не нравится F2 для переименовывания файлов, я её на другое действие переназначаю. Алиасы предназначены для катомизации терминала под себя, как будет удобно именно отдельному человеку. Из людей, с кем я работал, один взял мой вариант, а другой сделал себе свои, совсем другие, алиасы.
Что касается пересечений с названиями команд, то писать /bin/dd будет даже более хорошей практикой в скриптах, поскольку исключает пересечение с алиасами. Если часто требуется выполнять эту команду из консоли, то можно не прописывать автоматическое подключение алиасов в bashrc, а инициализировать их раз в день в рабочей консоли отдельной командой. Либо же подобрать другое название, например, dc (diff, color).
И если уж называете вредительсвом, то давайте расшифровку того, что имеете в виду, какие именно случаи, и какой вред в этих случаях алиасы могут нанести.
Поделиться существующей практикой и идеями. Я уже достаточно давно использую алиасы, они оказались намного удобнее, чем вводить команды целиком, причём именно в таком виде, легко запоминаются, нет никакой путаницы, действия доводятся до автоматизма. Собственно, основной моей деятельностью в консоли является работа с git.
Ну и в интернете список алиасов всегда под рукой. :)