Pull to refresh

Comments 106

Понимаю, все темы флеймовые, а последняя в собенности, но синтаксис крайне архаичиный.

И в чем же выражается архаичность синтаксиса bash?
Гхм, честно говоря, не понимаю, что тут архаичного. А как было бы не архаично?

Принципиальный недостаток это, да, ммм…
if(){

}
более привычно.
Принципиальные недостатки тоже есть, но это надо сеть загуглить. Насколько помню там что то с большим количеством предопределенных переменных и статусами возврата.
Если в целом то меня скорее напрягает то, что надо не стандартный синтаксис изучать в дополнение к другим синтаксисам. Наверно возраст))))
Именно. POSIX не совместимо. Тем более что половина дистрибутива это скрипты на bash. По любому час икс когда в них привидеться залезть приближается.
Мне кажется странно, что в наше время, когда новые языки появляются чуть ли не раз в месяц, bash не замещают чем нибудь более современным по синтаксису. Теоретически же можно конвертировать все скрипты автоматически.
bash не замещают чем нибудь более современным по синтаксису

Честно говоря, не в обиду, звучит смешно. Чем
if () {}

современнее чем
if .. fi

unix, bash и язык C родились примерно в одно время, в начале 70-х

И потом — взять вот и заменить. А обратная совместимость?
Теоретически же можно конвертировать все скрипты автоматически.

Теоретически можно. Но зачем?
Я пишу одновременно на трех языках программирования и в нескольких DSL.
Еще один синтаксис специфичный в голове держать тяжеловато как то. Особенно если он такой специфический.
У Вас сколько синтаксисов и DSL одновременно в работе?
С/C++/C#, bash, Java, Pascal, Basic, D, asm x86, Maple, Matlab… в разное время на чем-то из перечисленного что-то писал
Это не одновременно я так понимаю. Когда одновременно пишешь на нескольких, то каждый отличающийся сильно мозг нагружает, а еще думать надо что делаешь. Я поэтому bash уже месяца три никак осилить не могу, надо отдельно время выделить, сконцентироваться и т.д. Не то что с Java например было. Месяц… два и уже Swing и J2EE читаешь

Не одновременно, но проблем с переходом от одного к другому не возникало. Ах да, Lua ещё забыл…

Собственно, вопрос восприятия и усвоения — вопрос субъективный и к технической стороне вопроса относится мало.
Перфокарт я конечно в деле не использовал, но имел дело и с VAX и с ЕС. С тех пор я много разных языков встречал и использовал. Но такого не понятного синтаксиса визуально как bash я ни разу не встречал. Может впечатление архаичности и ложно, тут я не до конца компетентен. Но избавиться от него не могу. А Вы прямо любой скрипт открываете в системе и сразу ясно какие команды что делают в принципе?
А Вы прямо любой скрипт открываете в системе и сразу ясно какие команды что делают в принципе?

Нет не любой. Так вообще никто не может. Просто одни принимают что-то созданное до них как данность и разбираются, другие предлагают наполеоновские планы по глобальным реформам без видимых объективных причин. Разница в подходе к вопросу
Я имею ввиду не в целом. Это конечно понять не возможно сразу, а что отдельные инструкции делают. Я вот в примере ниже процентов 10 инструкций понимаю о чем речь.
Я вот в примере ниже процентов 10 инструкций понимаю о чем речь.

Это дело наживное
обнадежили)))))
не боги конечно горшки обжигают, но придется озадачиваться этим серьезно когда нибудь.
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
Самая жесть системных скриптов))))
Как по мне, то я бы предпочел на одном языке везде писать. На суть алгоритмов это не влияет.
Настройте себе snippets, будете на одном диалекте везде писать.
Это кстати очень интересная идея с сильной абстракцией. Благодарю. Надо ее обдумать.
Ничего у вас не получится, но попробуйте, за одно полюбите различные синтаксисы )
Как раз нет. Мне в отдаленной перспективе предстоит язык разрабатывать наверно. Идея со снипетами как раз туда похоже может лечь красиво. Только не понятно как еще.
Ну я желаю вам удачи, конечно.
Благодарю, но и не говорите, задача не тривиальна.
Ну так пишите на чем-то одном, если текущая ситуация вас напрягает. Выбор за вами. Если выбор не за вами, то у вас 2 варианта — либо оставить таки выбор за вами, либо перестать жаловаться на то что «еще один синтаксис специфичный в голове держать тяжеловато как то».
Выбор не за мной, а за решаемой задачей и имеющихся условиях. А они требуют писать параллельно на нескольких языках и DSL.
Ну либо вы решаете задачу, либо задача решает вас =) Я просто не совсем понимаю, почему необходимость держать сколько-то «синтатаксисов» в __вашей__ голове как-то пересекается с особенностями прочих сред и языков? Ну да, такой синтаксис в bash. Да, исторически сложилось. Ну не пользуйтесь, если не нравится. Скрипты в shell можно писать на… да почти на чём угодно можно писать. Ну а если скрипт не нравится — напишите решение вашей задачи на С, на Java, на Go…

Тут выше поднимался вопрос. Дело в posix совместимости и системных скриптах. Если что то лечить, чинить, настраивать — то придется bash использовать. Так что уж придется в него углубляться.
И работая под linux постоянно сталкиваешься со скриптами на bash. Интересно же заглянуть что внутри) А я сейчас как не загляну — ничего не понятно.
Я пишу одновременно на трех языках программирования и в нескольких DSL

Невероятные способности (сарказм). Придет время, когда вы поймете, что это далеко не предел.
Скорее придет время, когда я забуду как комп включать (ирония)

более привычно

Более привычно для кого, C-программистов? bash командный интерпретатор, он разбирает команды, а не конструкции языка.
И интерпретирует скрипты с конструкциями sh
У командной оболочки нет конструкций, у нее есть команды. Команда if определяет начало условного блока, команда fi ее конец. Языки основанные на командах просты в реализации, потому часто в качестве sh используются именно они.
Я понимаю о чем Вы говорите, но вот прям ссылка.
Если есть скрипт, переменные, циклы и условия — значит есть и конструкции языка. Другой вопрос, что он интерпретируется выполнением команд в отдельных процессах не редко, т.е. что то типа соеденяющий процессы конструктив. Если я правильно понял учебник bash.
Ну буханку тоже можно назвать тролейбусом, разница только в том, что для интерпретации конструкций языка нужен один механизм разбора, а для интерпретации команд, совершенно другой. Потому как бы вам этого не хотелось, bash не может использовать {...} для обозначения блоков. Отсюда можно сделать простой вывод — пишите на C, вызывать его можно в Linux точно так же, как и bash скрипты.
Самое интересное, что я эту мысль обдумывал. Зачем с bash извращаться, когда можно на C написать.
для интерпретации конструкций языка нужен один механизм разбора, а для интерпретации команд, совершенно другой
— а в чем разница? Объясните если не сложно. Вопрос интересный.
В отсутствии необходимости учитывать контекс (с оговорками) при разборе синтаксиса и в использовании минимального набора состояний. Длинная тема, в двух словах не опишешь.

Как так, zsh может, а bash нет? Механизм разбора в bash не более основан на интерпретации команд, чем в IPython. Здесь есть построение AST, расширить парсер (который основан на YACC), чтобы понимать тот же синтаксис, что понимает zsh особых проблем не составляет: вполне современный механизм разбора, к командам не имеющий никакого отношения, кроме того, что он, собственно, разбирает. Блоки в фигурных скобках, к слову, здесь есть: как при определении функций, так и просто на ровном месте в целях группировки.


VimL я привёл потому, что он использует архаичные методы: никаких YACC, никакого AST, берём строку исходного кода и исполняем как есть прямо по мере разбора. Нужен цикл? Будем разбирать строку на каждой итерации. И, главное, вся работа выполняется командами и функция парсера верхнего уровня знает только пустые строки, комментарии, то, что можно приписать каждой команде (т.е. диапозон строк, для которых команда будет исполняться, иногда используемые по другим назначениям) и, собственно, команды.


Сильно подозреваю, что tcsh написан так же: некоторые ошибки на это намекают.

вполне современный механизм разбора

Важно замечание ) Bash разросся из простого командного языка.
VimL я привёл потому

Да, Vim использует каноничный командный интерпретатор.

Даже если 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 отличаются от остальных команд только тем, что изменяют состояние редактора.

Даже если fi выглядит как команда, он ей совершенно не является

Мне просто лень вдаваться в подробности реализации bash )
Хотите язык реально основанный на командах — смотрите VimL

Спасибо, обязательно посмотрю ))
Вообще, год назад к 1-му апреля я подготовил патч для bash, который расширяет синтаксис, эквивалентно заменяя then, do, done, fi на {}, при этом сохраняя и старый синтаксис.
Так как патч был шуточный, я и статью на хабр выложил (названия не помню, и статья не прошла). А не прошла она т.к. этот патч к bash я назвал ebash…
Да это то о чём вы подумали, но в статье это звучало как Effective Bash, и обыгрывалась тема экономии символов.

Да код становится совершенно не очевидным, т.к. списки в bash также используют {}…
В том, что вы не можете писать нормальные функции. В том, что нет нормальной обработки ошибок. В том, что нет нормальных структур данных.

И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?

Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).

Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Очень сумбурно, непонятна аудитория вашей статьи.
Признаюсь об аудитории я не размышлял. Просто изложил все с чем столкнулся и личные впечатления. Мне кажется полезно тем, кто планирует переход, прочитать про чужой опыт. В сети в основном либо мануалы, либо руководства по конкретным ситуациям. Например проблема с почтовым сервером для меня стала неожиданностью, после hMailServer под Windows.
Если бы изложение было бы более литературным, захватывающим чтивом, я думаю, Вам простили бы даже небольшую информационную нагрузку. Что касается аудитории: линуксоиды просто посмеются (могут и высмеять), а «люди не в теме» вынесут из статьи, что у линукса проблемы со шрифтом и архаичная (ха-ха-три-раза) командная строка, а из коробки ничего не работает. Как-то так.
Не способен писать литературно :( Но поделиться хотел опытом без технических деталей.
Кстати про проблемы со шрифтами.
Меня больше всего возмущает в ситуации со шрифтами, что государство закапывает кучу денег в разные проекты, а шрифтов российских не сделало. Есть какие то, но они насколько я понял, не очень качественные.
Я был в курсе, но на них был плохой отзыв от специалиста. Вы считаете они качественные?
Если в курсе то зачем давать заведомо ложную информацию?
Отзыв какого специалиста? Их качество не смущало. PT Mono у меня стоит в текстовых редакторах и консоли, остальные шрифты использовал в дизайне. Правда я в основном на Windows и только сервера на Linux.
Спец по linux сказал, когда я у него про шрифты консультировался и эти шрифты в пример приводил. Они кстати, я сейчас еще раз посмотрел, под Windows. Под freetype в этих шрифтах хинтинга нет, если я все правильно понял. Так что информация не ложная.
1. Шрифты плохо выглядят под 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 они дают своё мыло для решения проблем.
Там же запись было, что чтобы хинтинг не делать растры вставили. Вопрос же в LCD мониторах.
Хорошо соглашусь что государство сделало шрифты, только почему не под открытый стандарт. В целом это кривой подход.
Я не знаю что там с хинтингом в линуксе (вообще ШГ в линуксе это норма), но ребята явно занимались им.
А в вики написано:
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, где зачастую достаточно нагуглить одну галку, погребенную в дебрях GUI, и потом не вспомнишь, зачем она вообще была нужна (а в новой версии windows ее еще и перепрятать могут).
А после того, как разберешься — сразу ЧСВ поднимается, и чувствуешь себя героем :) Да и при дальнейшем копании в системе начинаешь больше понимать, как и почему так все работает.
Причем больше понимаешь не только в линуксе, но и в windows. Например, я раньше и не догадывался, что в windows есть понятие mount-а.
А за что минусы то? Писал исходя из собственного опыта. Получается, у меня неправильный опыт был? Поясните, пожалуйста.

Основной посыл комментария — «linux нужно осваивать для повышения Чувства Собственной Важности» :) По‐моему, вы просто выбрали неудачные формулировки для выражения своей мысли.

Основной посыл задумывался в самой первой строчке («заставляет разбираться в том, что делаешь»). А про ЧСВ — это вообще с юмором писал. Не умею я шутить, видимо :(
Спасибо за пояснение.
«Поставил линукс — напиши на хабр». Классика.
Чтобы не мучиться с почтой есть iRedMail.
iRedMail во первых не встал на систему как мне надо, а во вторых я потом два дня его вычищал из системы, т.к. он мне некоторые конфигурации порушил и вообще прав много хотел для своей деятельности.
Это конечно более легкий путь, но не совсем правильный.
Я по результатам рекомендовал его не использовать.
Немного накипело: знаете, что меня бесит как пользователя в среде *nix? Ресайз окна. мелкие поняли какой должна быть область по ширине бордера, чтобы зацепить окно. Никто в GUI никсовых не подумал, что эта область должна быть больше 1px бордера.

P.S. фряшник.
Да… а я все думаю, что так окно тяжело зацепить за край мышкой иногда. Это оно?
Меня реально напрягает, что в GNOME например когда комбинации клавиш настраиваешь окно не раздвигается и нельзя прочитать полный текст на что кнопка привязана. Я с этим в нескольких местах сталкивался.
Cinnamon, зона ресайза явно больше одного пикселя. Только что проверил.

Fluxbox. Зажал Alt и тащи правой кнопкой хоть из самого центра, правда изменять размер можно только направо‐вниз, если не использовать специальную resize зону (которая у меня на большинстве окон отключена вместе с рамкой вокруг окна). Этих зон две в нижних углах, что добавляет налево, но не вверх. Зона явно больше одного пикселя, как и сама граница. Но всё равно придётся целиться.


Уверен, будь у вас 1px, то с 1920x1080 вы бы границу просто не заметили бы.

Это работает и в MATE, да и в других DM наверняка есть. Система — Параметры — Окна, можно переключить на Winkey, если Alt не устраивает. А так Alt+левая кнопка — перемещение окна, Alt+правая — ресайз.

Часто нет желания нажимать на лишние сочетания клавиш. Так же как и в консольке нет желания брать мышку.

Да, с 1px я погорячился. У меня на ноуте 1366x768 и область ресайза все таки где-то 3px, в которые тяжело попасть, при этом размер границы 1px.
Сейчас еще провел один маленький эксперимент: на Windows 7 отключил в параметрах указателя «Включить повышенную точность установки указателя» — уровень удобства пользования UI стал ниже, но все равно выше, чем в никсах. Интересно, есть-ли подобные параметры для других систем.
Ресайз окна зависит от используемого оконного менджера. Да, в оконном менеджере GNOME сделано плохо.
Но практически везде есть возможность ресайза с зажатым модификатором — и не нужно целиться в край окна.
> Первым недостатком системы я считаю отсутствие стандарта и стандартного интерфейса на конфигурационные файлы.

Эм, а «в самой лучшей ОС» такой стандарт есть, что ли? И каков же он? 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 обычно не на высоте в первую очередь потому, что это скрипт.

Про настройку команд с ключами, я как говорил развивать тему не хочу, но решение мне известно. Конечно я в этом не на 100% уверен, т.к. надо на практике проверить, но на 90%.
Скрипты на javascript.
Я как пример привел. Это тема требует размышлений, может 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.

ОК, просто звучало очень неоднозначно. Т. к. "javascript и совместимые языки" с высокой долей вероятности указывают на те языки, что транслируются в js.

В таком дистре, как OpenWRT, используется есдиная система конфигов (UCI — Unified Configuration Interface). И оно реально очень удобно.
Супер тема! И кстати модель файлов конфигурации очень мощная.
Автор, этот комментарий, возможно, изменит твою жизнь, так что будь осторожен:
Изменяющий жизнь текст
Ядро Linux позволяет реализовать собственный дистрибутив на его основе. Возможно создать свою ОСь с json в качестве стандарта конфигурирования, JavaScript в качестве командного интерпретатора и единым интерфейсом для всех подсистем. Дерзайте.

Открыть через 5 лет
Вот, автор, прошло уже 5 лет. Вы успели написать несколько утилит и подсистем, стремясь реализовать свою, стандартный дистрибутив. К сожалению, за это время json уже канул в лету, JavaScript никто не пользуется, а ваша ОСь уже не такая стандартная, как казалось ранее. Но не расстраивайтесь, несколько дней назад на хабре кто то написал о недостатках Linux и даже уже начал писать свой стандартный дистрибутив с yaml и Go. Пожилаем ему удачи.
Если раннее не пользовались линуксом и переходите с винды, то выбирайте дружественные к пользователю дистрибутивы — Linux Mint, Ubuntu и т.п… Для экспериментов используйте VirtualBox — так если и поломаете внутри что-то, то потом откатите.
В комментариях выше правильно подсказали про почтовый сервер http://www.iredmail.org/, есть еще статья здесь
Все остальное в целом работает и я очень доволен тем, что система полностью под моим контролем

В Дебиане?
Не согласен. Кто хочет полный контроль — сидят на генте или слаке. Вот там свобода так свобода.
Я, пока осваивал генту, выучил синтаксис Shell-скриптов, в первые же месяцы разобрался как писать и подсовывать системе свои патчи. А после вдумчивого конфигурирования ядра (неделю примерно) уже имелись хоть какие-то представления о его структуре (пришлось лезть в сырцы и смотреть на причины конфликтов при сборке).
Зато после освоения генты путь LFS-BLFS до рабочего стола с кедами и плюшками прошел дня за 4 (при этом отучил всё, что можно от python2 и Qt4).

PS: И да — гента стала моим первым дистром, на котором я освоился. До этого были отдельные попытки с убунтой, но дольше пары недель они не длились — сильно проблематично разработчику там, приходится ставить просто пакет и его dev-версию, что бы в проекте подключить нормально. В генте это всё «из коробки». Поэтому это личное ИМХО как разработчика софта.
По поводу конфигов: есть проект etcd с API, json и распределенкой. Вам остается только переписать все сервисы на вашей системе для его понимания
github.com/coreos/etcd
По поводу bash: пишите на python, lua, groovy или в крайнем случае на C. Это не возбраняется

Ещё есть Tcl. Из коробки есть почти в любом дистре. Плюс, приятное дополнение в виде Tk.
А вот у луа проблемы в плане работы с ОС (всякие операции с файлами и т.д.). Всё-таки он позиционируется больше как встраиваемый язык, так что там нет богатой стандартной библиотеки и удобной системы пакетов.

Как итог хочу сказать следующее. Windows и Linux не сопоставимы между собой как по возможностям, так и по уровню контроля над ситуацией. Сравнение явно в пользу Linux и рекомендую всем сдвигаться в этом направлении.

Преподносится как вывод, хотя в тексте нет ничего, подтверждаюшего это.
неужели это статья уровня хабра? больше похоже на сочинение школьника

Имхо, выглядит как заметка из серии "мой дневник". Очередной "переход" — это всего лишь "пора начать использовать 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 это просто хороший тон :)

А еще плюс Ansible в том, что ему не нужен агент на целевой машине.

Благодарю. Когда придет время озадачусь.
Судя по результатам голосования в конце статьи идея понятна части аудитории.
Sign up to leave a comment.

Articles