Comments 106
Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный.
И в чем же выражается архаичность синтаксиса bash?
Принципиальный недостаток это, да, ммм…
}
более привычно.
Принципиальные недостатки тоже есть, но это надо сеть загуглить. Насколько помню там что то с большим количеством предопределенных переменных и статусами возврата.
Если в целом то меня скорее напрягает то, что надо не стандартный синтаксис изучать в дополнение к другим синтаксисам. Наверно возраст))))
if(){} более привычно.
Ну так есть же вот, но POSIX не совместимо.
Вообще же командных оболочек много, можно выбрать любую на вкус и цвет
Мне кажется странно, что в наше время, когда новые языки появляются чуть ли не раз в месяц, bash не замещают чем нибудь более современным по синтаксису. Теоретически же можно конвертировать все скрипты автоматически.
bash не замещают чем нибудь более современным по синтаксису
Честно говоря, не в обиду, звучит смешно. Чем
if () {}
современнее чем
if .. fi
unix, bash и язык C родились примерно в одно время, в начале 70-х
И потом — взять вот и заменить. А обратная совместимость?
Теоретически же можно конвертировать все скрипты автоматически.
Теоретически можно. Но зачем?
Еще один синтаксис специфичный в голове держать тяжеловато как то. Особенно если он такой специфический.
У Вас сколько синтаксисов и DSL одновременно в работе?
Собственно, вопрос восприятия и усвоения — вопрос субъективный и к технической стороне вопроса относится мало.
А Вы прямо любой скрипт открываете в системе и сразу ясно какие команды что делают в принципе?
Нет не любой. Так вообще никто не может. Просто одни принимают что-то созданное до них как данность и разбираются, другие предлагают наполеоновские планы по глобальным реформам без видимых объективных причин. Разница в подходе к вопросу
case "$prog" in
*less) more=less ;;
*) more=more ;;
esac
if test "`echo -n a`" = "-n a"; then
# looks like a SysV system:
n1=''; n2='\c'
else
n1='-n'; n2=''
fi
oldtty=`stty -g 2>/dev/null`
if stty -cbreak 2>/dev/null; then
cb='cbreak'; ncb='-cbreak'
else
# 'stty min 1' resets eof to ^a on both SunOS and SysV!
cb='min 1 -icanon'; ncb='icanon eof ^d'
fi
Я например еле еле отдельные куски с ходу понимаю
Я спокойно одновременно пишу на C99, lua, Zsh, Python, VimL. В таких случаях считаю за благо, когда некоторые вещи либо совершенно непохожи на себя же в других языках, либо абсолютно одинаковы. «Слегка различные» функции/синтаксические конструкции/… — гораздо бо́льшее зло.
К примеру, в zsh вы можете написать
if (test -z $1) {
echo "First argument is empty"
}
но это запустит test -z
в подоболочке. Конкретно в if это почти всегда незаметно¹, но в таком стиле можно и while циклы писать.
К примеру,
echo abc | while read i ; do
echo $i
done
выведет abc, тогда как
echo abc | while (read i) {
echo $i
}
выведет пустую строку. И вы будете долго отлаживать код, потому что положились на сходство синтаксиса, хотя синтаксис здесь на самом деле while {restricted-list} { {list} }
², где под {restricted-list}
понимается что‐то вроде «любая команда в скобочках»: группировка {read i}
(в этой форме второй цикл заработает), тесты [[ -z $var ]]
/(( i%4 != 3 ))
(но не [ … ]
, для одинарных нет специального синтаксиса), … запуск в подоболочке (true)
.
¹ Подумаешь, лишний fork. Во‐первых zsh умеет делать exec без fork’а, если видит, что исполняемая команда последняя, так что лишний fork один, а не два. Во‐вторых, в большинстве случаев проседание производительности незаметно.
² Обычный цикл: while {list} do {list} done
, так что можно писать
while echo abc | grep foo
do
echo Here
done
… или
# Infinite cycle
while false ; false ; false ; false ; false ; false ; true
do
echo There
done
Как по мне, то я бы предпочел на одном языке везде писать. На суть алгоритмов это не влияет.
И работая под linux постоянно сталкиваешься со скриптами на bash. Интересно же заглянуть что внутри) А я сейчас как не загляну — ничего не понятно.
Я пишу одновременно на трех языках программирования и в нескольких DSL
Невероятные способности (сарказм). Придет время, когда вы поймете, что это далеко не предел.
более привычно
Более привычно для кого, C-программистов? bash командный интерпретатор, он разбирает команды, а не конструкции языка.
Если есть скрипт, переменные, циклы и условия — значит есть и конструкции языка. Другой вопрос, что он интерпретируется выполнением команд в отдельных процессах не редко, т.е. что то типа соеденяющий процессы конструктив. Если я правильно понял учебник bash.
для интерпретации конструкций языка нужен один механизм разбора, а для интерпретации команд, совершенно другой— а в чем разница? Объясните если не сложно. Вопрос интересный.
Как так, zsh может, а bash нет? Механизм разбора в bash не более основан на интерпретации команд, чем в IPython. Здесь есть построение AST, расширить парсер (который основан на YACC), чтобы понимать тот же синтаксис, что понимает zsh особых проблем не составляет: вполне современный механизм разбора, к командам не имеющий никакого отношения, кроме того, что он, собственно, разбирает. Блоки в фигурных скобках, к слову, здесь есть: как при определении функций, так и просто на ровном месте в целях группировки.
VimL я привёл потому, что он использует архаичные методы: никаких YACC, никакого AST, берём строку исходного кода и исполняем как есть прямо по мере разбора. Нужен цикл? Будем разбирать строку на каждой итерации. И, главное, вся работа выполняется командами и функция парсера верхнего уровня знает только пустые строки, комментарии, то, что можно приписать каждой команде (т.е. диапозон строк, для которых команда будет исполняться, иногда используемые по другим назначениям) и, собственно, команды.
Сильно подозреваю, что tcsh написан так же: некоторые ошибки на это намекают.
Даже если fi выглядит как команда, он ей совершенно не является. Есть стандарт на синтаксис оболочки: посмотрите на синтаксис в http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_10_02, из него явно следует, что в AST (абстрактное синтаксическое дерево) if затянется одним куском. Да и если вы попробуете выполнить if echo abc ; then echo def
(т.е. без fi), то вы получите syntax error сразу, echo abc
запускать никто не будет, не говоря уже об echo def
. Если бы if
было обычной командой, то вы бы увидели abc
, потом def
, а потом что‐то вроде runtime error, говорящую о том, что конец файла достигнут, а fi не найдено.
Все (проверял в busybox, posh, bash, dash, ksh, zsh) оболочки при вводе if echo abc<CR>then<CR>echo def<CR>
будут ждать от вас fi
и только потом что‐то запустят (или EOF и потом сообщат вам о синтаксической ошибке). Хотите язык реально основанный на командах — смотрите VimL. Он запустит echo abc
даже в echo [system('echo abc')
(команда не завершена: отсутствует закрывающая квадратная скобка), да и внутри if
и endif
отличаются от остальных команд только тем, что изменяют состояние редактора.
Так как патч был шуточный, я и статью на хабр выложил (названия не помню, и статья не прошла). А не прошла она т.к. этот патч к bash я назвал ebash…
Да это то о чём вы подумали, но в статье это звучало как Effective Bash, и обыгрывалась тема экономии символов.
Да код становится совершенно не очевидным, т.к. списки в bash также используют {}…
И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Кстати про проблемы со шрифтами.
Меня больше всего возмущает в ситуации со шрифтами, что государство закапывает кучу денег в разные проекты, а шрифтов российских не сделало. Есть какие то, но они насколько я понял, не очень качественные.
Отзыв какого специалиста? Их качество не смущало. PT Mono у меня стоит в текстовых редакторах и консоли, остальные шрифты использовал в дизайне. Правда я в основном на Windows и только сервера на Linux.
2. У них было обновление и вносили правки под юниксы: http://paratype.livejournal.com/12393.html?thread=38761#t38761 ещё было повторное обновление http://paratype.livejournal.com/21560.html
3. А в первой записи http://paratype.livejournal.com/10009.html#cutid7 они дают своё мыло для решения проблем.
Хорошо соглашусь что государство сделало шрифты, только почему не под открытый стандарт. В целом это кривой подход.
А в вики написано:
PT Sans is included in the Fedora Linux package repository since February 2010, in the Gentoo Linux repository since January 2011, and in OS X since Lion.Не думаю что плохой шрифт приняли бы в ту же Федору. Так что мне думается тут больше проблемы конкретно вашей и специалиста систем.
А после того, как разберешься — сразу ЧСВ поднимается, и чувствуешь себя героем :) Да и при дальнейшем копании в системе начинаешь больше понимать, как и почему так все работает.
Причем больше понимаешь не только в линуксе, но и в windows. Например, я раньше и не догадывался, что в windows есть понятие mount-а.
Основной посыл комментария — «linux нужно осваивать для повышения Чувства Собственной Важности» :) По‐моему, вы просто выбрали неудачные формулировки для выражения своей мысли.
Чтобы не мучиться с почтой есть iRedMail.
Это конечно более легкий путь, но не совсем правильный.
Я по результатам рекомендовал его не использовать.
P.S. фряшник.
Меня реально напрягает, что в GNOME например когда комбинации клавиш настраиваешь окно не раздвигается и нельзя прочитать полный текст на что кнопка привязана. Я с этим в нескольких местах сталкивался.
Fluxbox. Зажал Alt и тащи правой кнопкой хоть из самого центра, правда изменять размер можно только направо‐вниз, если не использовать специальную resize зону (которая у меня на большинстве окон отключена вместе с рамкой вокруг окна). Этих зон две в нижних углах, что добавляет налево, но не вверх. Зона явно больше одного пикселя, как и сама граница. Но всё равно придётся целиться.
Уверен, будь у вас 1px, то с 1920x1080 вы бы границу просто не заметили бы.
Да, с 1px я погорячился. У меня на ноуте 1366x768 и область ресайза все таки где-то 3px, в которые тяжело попасть, при этом размер границы 1px.
Сейчас еще провел один маленький эксперимент: на Windows 7 отключил в параметрах указателя «Включить повышенную точность установки указателя» — уровень удобства пользования UI стал ниже, но все равно выше, чем в никсах. Интересно, есть-ли подобные параметры для других систем.
Но практически везде есть возможность ресайза с зажатым модификатором — и не нужно целиться в край окна.
Эм, а «в самой лучшей ОС» такой стандарт есть, что ли? И каков же он? Ini? И какой смысл иметь единый стандарт, если какие-то приложения конфигурируются парами ключ-значение, а каким-то нужен фактически тьюринг-полный язык для конфигурирования?
> Второй недостаток это все таки безумные количества колючей на командах. Я конечно уже освоился с базовым арсеналом, но опять же хотелось бы иметь стандартного мастера для конструирования параметров и ключей команды.
Опять некий мифический «стандартный мастер» для конфигурирования любых приложений. Что значит «конструирование параметров и ключей», я не знаю, но скорее всего вам нужны bash aliases. Нет, вру, сначала разумеется нужна статья на хабр, где вы авторитетно открываете всем глаза на то, как надо работать с юниксовыми консольными приложениями.
> И третьим недостатком я считаю синтаксис bash. Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный.
И кто тогда неархаичный? Синтаксис то ли Си, то ли Perl с фигурными скобками, который вы выше приводите? Ему как бы тоже не один десяток лет.
Например json+json schema+ например json editor
Мастер:
Не буду вдаваться в детали, но решение существует для этой проблемы.
Архаичность bash:
Выше в целом все обсуждено. Меня бы например javascript устроил вполне.
Часть программ настраивается с помощью полноценного языка программирования. JSON тут в пролёте. Те, кому это не нужно, может и могли бы перейти на JSON, но вам знаком такой термин как «обратная совместимость»? Это мало кому нужно (обычно языки в конфигурации просты как три копейки) и много кому поломает их скрипты или иногда даже программы.
Я тоже не понимаю, что именно вы имели ввиду под «стандартным мастером». Команды, вводимые в оболочку, нужно воспринимать как библиотечные функции в других языках программирования: за некоторыми исключениями (слабо представляю себе библиотечную функцию, запускающую тяжёлое GUI‐приложение) они выполняют именно эту роль. Я как‐то не слышал про мастера конструирования для библиотечных функций. А документация на команды есть, и она более или менее стандартна.
Возьмите node.js и попробуйте там написать сложный shell скрипт с фильтрами. Взвоете. Скрипты на bash ориентированы на сопряжение команд (т.е. основную работу выполняет не bash а какой‐нибудь grep) и довольно удобны для их сферы применения, языки вроде javascript ориентированы на то, что наибольшую часть работы выполняет код на javascript (возможно, библиотечный). В некоторых случаях «на javascript или совместимых языках» (т.е. исполняющихся в JVM или находящихся в разделяемых библиотеках со стандартным C‐шным интерфейсом вызова).
Можно попытаться что‐то скрестить как сделал zsh выше ([t]csh не смотрите, его писали люди, которые явно хотели пытать программистов, а не писать оболочку), но, скорее всего, получите лишь то, что количество символов в скрипте уменьшится на 1%, синтаксис в целом сильно не изменится, а программисты начнут путаться. Или что синтаксис будет как в javascript, но количество символов увеличится в несколько раз, а программисты будут искренне недоумевать, как вы могли назвать свою поделку языком для оболочки. Так зачем заниматься фигнёй с заменой синтаксиса, если сильно лучше не будет, а переделать всё придётся?
Лучше развивать что уже есть. Как используемый мною zsh: чтобы понимать любой скрипт на zsh придётся выучить на целый порядок больше информации: поэтому zsh — это моя любимая оболочка (чтобы добиться того же результата однострочником в bash иногда нужно написать в два и более раз больше символов), но системные скрипты на zsh я бы не приветствовал. При этом возможно писать скрипты, которые нормально работают в POSIX sh, bash, ksh и zsh одновременно.
Конфигурация в JSON.
Конфигурация это данные. JSON прекрасный формат, чтобы его и читать глазками и компиком. Ну а то, что некоторые программы настраиваются кодом, это уже не конфигурации, скрипты какие то наверное.
Во‐первых, есть форматы и получше. Во‐вторых, я не говорил, что JSON плох. Я говорил, что он либо не применим, либо не будет понят уже написанными программами. Никто не будет менять формат конфигурации, просто потому что кто‐то решил сделать какой‐то новый формат стандартным.
UNIX появился задолго до того, как возник Javascript, не говоря уже о JSON. И в среде, где «обратная совместимость» реально важна большинству пользователей.
С обратной совместимостью ситуация понята, но весь софт, который используется практически всегда на поддержке. По крайней мере в Debian как я понял. Такую операцию вполне можно провести. Всем бы жить легче стало. А то открываешь Apache — один стиль, php — другой и т.д. уже в глазах от этих конфигов рябит)))
Для конфигурационных файлов я всегда предпочёл бы YAML: его удобнее читать человеку (компьютеру, наоборот, сложнее). Правда, я бы оформлял всё дело не как файл(ы) с настройками, а как configfs с двумя вариантами доступа: vim /path/to/configfs/root/appname/…/file.yaml
для пользователя с доступом на чтение‐запись и bool config_query(const char *appname, const char *config_file_path, const struct query *query, const enum query_return_type return_type, void *query_result)
(+несколько обвязок вроде config_query_integer
) для собственно приложения (разумеется, с другими API на других языках): чтобы реализовать парсер YAML один раз и без внешних зависимостей (системные библиотеки не считаются) и вообще тратиться на разбор настроек только один раз после записи, а не при каждом старте приложения.
(Если вы нашли очевидные проблемы: во‐первых, один раз после записи ≠ один раз немедленно после записи. Запись должна стирать кэш, а config_query
уже будет проводить разбор, который будет кэшироваться до следующей записи. Во‐вторых, заодно именно здесь должны показываться ошибки, если они есть: системные API для чтения‐записи файлов не позволяют нормально сообщить о проблеме разбора YAML файла. Хотя нужно было добавить ещё аргумент в функцию — для возврата ошибки либо callback, принимающий описание ошибки в аргументах.)
JSON прекрасный формат, чтобы его и читать глазками и компиком.
Ага, особенно радует отсутствие комментов, один вид кавычек, необходимость эти кавычки ставить в ключе, отсутствие trailing comma (это когда нельзя делать так: [1, 2, 3,]
), скудность типов, и ещё куча недостатков. Наличие попыток сделать свой формат на основе JSON или добавить ему костыли — лишнее тому подтверждение.
Если настройки сводятся к ключ-значение, то ini и подобные ему куда лучше. Если настройки начинают выходить за эти рамки, то по мне уж лучше писать конфиг на каком-то языке программирования, например lua или js.
Соглашусь с первой частью, но не со второй. Интерпретируемый/компилируемый конфиг — это жесть, т. к. с ним становится почти невозможно работать из другого софта (в том числе SCM).
Интерпретируемый/компилируемый конфиг — это жесть
Ну это смотря для чего конфиг. Если настроить программу, у которой куча опций плагинов и др. возможностей — самое оно. Собственно, все современные редакторы кода построены по такому принципу. В мире nodejs тоже предпочтительнее использовать js-код, а не просто json. Банально уменьшает количество копипаста.
с ним становится почти невозможно работать из другого софта
Мы же про ОС говорим? И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
Если же некие конфиги будут использоваться кучей программ, то да, нужно что-то статическое и со схемами. Но тут xml наверное будет получше, хотя зависит от задачи.
Собственно, все современные редакторы кода построены по такому принципу.
Не знаю, какие именно редакторы вы имеете ввиду. Тяжелые IDE которыми я пользуюсь имеют статический конфиг. Часть систем сборки — статический декларативный конфиг.
И про всякие более-менее стандартные (не узкоспециализированные) программы. Зачем с конфигом программы работать из другого софта? Кому может понадобится конфиг, например, nginx'а кроме него самого?
Я же недвусмысленно написал пример: разные SCM (ansible, salt, puppet, chef etc). Другой классический пример IDE и системы сборки. Интеграция с gradle обычно не на высоте в первую очередь потому, что это скрипт.
Я как пример привел. Это тема требует размышлений, может javascript не подходит. Может надо отдельный синтаксис и семантику разработать. Хотя сейчас асинхронная часть языка активно развивается. Промисы, генераторы и т.д. Так что может и подойдет.
Синтаксис и функциональность асинхронной части не особо в тему: основная проблема, что я не представляю, как можно сократить cat /var/log/messages | grep \^"$(LANG=C date -d-1day +'%b %d')"
до чего‐то, меньшего чем
stdout.write(pipe(cmd('cat', '/var/log/messages'), cmd('grep', '^' + env({LANG: 'C'}, cmd, 'date', '-d-1day', '+%b %d').read().trim())))
Ни promis’ы, ни какая‐нибудь другая асинхронная фигня, ни callback’и тут особо не помогут: так, как выше, можно писать уже сейчас (если грамотно поизвращаться с callback’ами; если не извращаться, то код будет более похож на JS, но длиннее). Добавите что‐то из новых возможностей — будет ещё длиннее, а не короче: внешние процессы и так запускаются асинхронно, а возможности для асинхронного запуска JS кода здесь нафиг не нужны.
В некоторых случаях «на javascript или совместимых языках» (т.е. исполняющихся в JVM или находящихся в разделяемых библиотеках со стандартным C‐шным интерфейсом вызова).
Взаржал в голос. Не только среди хрюшек, оказывается, есть люди путающие java и js.
Я неправильно выразился здесь. Я не имел ввиду, что JS исполняется на JVM. Я просто под «javascript» имел ввиду класс языков, исполняющихся в VM (javascript, Java/…, Python, lua). Т.е. то, что в предложении раньше назвал «языками вроде javascript».
И для таких языков нормально сопряжение либо средствами VM (Java, C#), либо через C‐шный ffi.
В комментариях выше правильно подсказали про почтовый сервер http://www.iredmail.org/, есть еще статья здесь
Все остальное в целом работает и я очень доволен тем, что система полностью под моим контролем
В Дебиане?
Не согласен. Кто хочет полный контроль — сидят на генте или слаке. Вот там свобода так свобода.
Я, пока осваивал генту, выучил синтаксис Shell-скриптов, в первые же месяцы разобрался как писать и подсовывать системе свои патчи. А после вдумчивого конфигурирования ядра (неделю примерно) уже имелись хоть какие-то представления о его структуре (пришлось лезть в сырцы и смотреть на причины конфликтов при сборке).
Зато после освоения генты путь LFS-BLFS до рабочего стола с кедами и плюшками прошел дня за 4 (при этом отучил всё, что можно от python2 и Qt4).
PS: И да — гента стала моим первым дистром, на котором я освоился. До этого были отдельные попытки с убунтой, но дольше пары недель они не длились — сильно проблематично разработчику там, приходится ставить просто пакет и его dev-версию, что бы в проекте подключить нормально. В генте это всё «из коробки». Поэтому это личное ИМХО как разработчика софта.
github.com/coreos/etcd
По поводу bash: пишите на python, lua, groovy или в крайнем случае на C. Это не возбраняется
Преподносится как вывод, хотя в тексте нет ничего, подтверждаюшего это.
Имхо, выглядит как заметка из серии "мой дневник". Очередной "переход" — это всего лишь "пора начать использовать Linux".
В тему по синтаксису — сам поддерживаю зоопарки машин, и затеи унифицировать ksh/bash/cmd/powershell умерли с появлением систем конфигурации. Если очень поверхностно, то абстракция этого уровня позволяет эффективно видеть саму конфигурацию, а особенности шелла прятать под капотом. Установить пакет? package {"git"}
— пожалуйста. Это для тех, кто хочет универсальности. Обучайте-нанимайте системщиков знающий puppet/chef/ansible/… и все будет хорошо :)
Кстати замечу на данный момент 34% проголосовавших не против увидеть историю в том же стиле про борьбу с сервером, так что тематика и формулировки людям интересны.
По Вашей наводке почитал про системы управления. И если SaaS облако делать на арендованных виртуалках, то наверно без такой системы не обойтись. Но я тут тему изучил, и так как я на Debian уже заложился, то остановился на Bcfg2. Буду признателен, если прокомментируете.
Я не знаком с bcfg2, не использовал, но когда смотрел изначально (года 4 назад) смутила ужасная на первый взгляд архитектура и отсутсивие (или неявность?) документации по непосредственно конфигурации систем.
Я начинал с Puppet, потом немного Chef и сейчас Ansible.
Рекомендую посмотреть в сторону ansible. Оно очень просто, в то же время эффективно.
если SaaS облако делать на арендованных виртуалках, то наверно без такой системы не обойтись.
Не обязательно. Любой конфиг через систему управления конфигурацией становится куском кода, к которому можно потом вернуться, либо дать другому пользователю.
Моя идеология такая: например, вы разворачиваете чуть менее тривиальный nginx+php-fpm, с системой выкатки. Почему-бы не засунуть это все в Ansible, ведь наверняка придется разворачивать еще один такой же сервер через неделю или полгода?
А ведь к тому моменту конфигурация может измениться, и если поддерживать роль Ansible, то новый сервер развернется "сам" :)
К тому же держать конфиг сервера в git это просто хороший тон :)
Выглядит, как натуральное тро-ло-ло.
Опыт перехода с Windows На Linux/Unix. Часть2