Почему bash является оболочкой по умолчанию в большинстве ОС?

38

Почему bash является оболочкой по умолчанию в большинстве операционных систем (Ubuntu, Fedora, OSX и т. Д.)? Почему многие продвинутые пользователи в основном используют zsh? Если это так хорошо, почему это не по умолчанию?

Я использую оба, я не вижу разницы, потому что все мои задачи просты :)

Талал
источник
5
Все является кривой Гаусса: если верно, что большинство продвинутых пользователей используют ksh, то также верно, что большинство людей используют другую оболочку, и это само по себе объясняет, почему kshэто не оболочка по умолчанию. Однако я не думаю, что это является причиной, давайте подождем некоторого убийственного ответа, который, я уверен, этот вопрос получит.
Кос
1
На самом деле, я считаю, что Ubuntu использует dash в качестве оболочки по умолчанию ...
Bakuriu
1
У этого есть хороший ответ, я голосую, мы оставляем это открытым.
Сет

Ответы:

33

Я немного почитал об этом, и, похоже, я пришел к выводу, что это оболочка по умолчанию GNU (используемая большинством ОС на базе Linux), и поэтому он просто поставляется в составе GNU, а также имеет 20-летний опыт разработки. стабильный и хорошо округленный, он просто лучший среди всех, удовлетворяющий потребности всех, кроме самых продвинутых пользователей.

Для получения дополнительной информации прочитайте Почему стандарт bash в Linux? (тот же вопрос по Unix и Linux).

Просто чтобы добавить немного больше к этому, есть много других оболочек, чтобы попробовать, если вам интересно, вот несколько из этого ответа :

  • У Zsh есть более продвинутые интерактивные возможности, но есть некоторые причуды, когда дело доходит до сценариев (теперь меньше, чем когда-либо). В начале и середине 1990-х годов, когда Linux находился в зачаточном состоянии, zsh был практически неизвестен.

  • Ksh был стандартом де-факто для коммерческих объединений с середины 1980-х годов, но до 2000 года это было проприетарное программное обеспечение, поэтому в Linux его нельзя было использовать. Кроме того, у ksh были возможности редактирования командной строки на более низком уровне по сравнению с bash.

  • Pdksh , бесплатный клон ksh, был бы вариантом, но он не был известен и имел слабые возможности редактирования командной строки. (Pdksh больше не является очень активным проектом, хотя он все еще используется в некоторых BSD, теперь, когда ATT ksh свободен.)

  • Некоторые дистрибутивы устанавливают зольную версию как /bin/sh. Ясень (под которым я подразумеваю любое из рыхлого семейства оболочек, называемых пеплом) разработан так, чтобы быть маленьким и быстрым, без интерактивных функций (он предназначен только для редактирования скриптов). Возрождение пепла относительно недавно; в 1990-х годах существующим вариантам не хватало многих возможностей.

  • Tcsh была самой продвинутой интерактивной оболочкой, пока не появилась zsh, но она несовместима с sh и не очень хороша для сценариев .

Марк Кирби
источник
1
Когда вы копируете и вставляете вещи из другого места, вы должны четко указать, что это так.
Муру
1
@muru Я предоставил ссылку на оригинальный пост, но я понимаю, что вы могли бы сказать, что это может быть яснее.
Марк Кирби
Каков источник вашего комментария о том, что у zsh есть несколько причуд в отношении сценариев? Неважно, я вижу, что комментарий пришел откуда-то еще.
Скутер
1
У вас также есть рыба (что несовместимо с синтаксисом sh).
Лео Лам
1
Не могли бы вы объяснить, что было недостаточно в редактировании оболочки Korn? Мне всегда казалось, что это нормально, даже в 90-х.
Джонатан Леффлер
9

Bourne Shell ( ш назад в день) от AT & T ветви Unix была улучшена и вытеснены в Korn Shell, KSH . ksh также вышел из AT & T Bell Labs и не был GPL (текущая версия - Eclipse Public License). C-оболочка csh вышла из версии Unix для Беркли и также не была GPL (лицензия BSD) и также использовала синтаксис, отличный от sh. Z-shell, zsh - это улучшение sh, но не GPL (MIT-подобная лицензия). Bash был улучшением sh, использовал GPL и GNU. Только на одной лицензии Bash, вероятно, был бы выбором для операционной системы GPL. Особенно с оболочкой, являющейся основной частью дистрибутива.

Но Bash был также проектом GNU, который, как мне кажется, дал ему более активную разработку и сделал вклад легче, чем унаследованный продукт из Berkeley Unix или AT & T Unix. Можно привести очень хороший пример того, что zsh является и был лучшей оболочкой, чем Bash, но этого недостаточно, чтобы преодолеть другой статус лицензии и не-GNU проекта.

В те времена, когда дистрибутивы Linux впервые появлялись и выбирали оболочку по умолчанию (с начала до середины 90-х годов), не было ни github (2008), ни даже SourceForge (1999). На данный момент, я думаю, что проекты GNU имели реальное преимущество перед проектами не-GNU в том, что их замечали и рисовали, включая новых разработчиков. Таким образом, дистрибутивы могут смотреть на Z-shell лучше, но также ожидают, что Bash получит хорошую поддержку и поддержку в будущем, а также добавит больше возможностей, что позволит ему догнать zsh.

Теперь, когда Bash имеет годы статуса по умолчанию, он стал стандартом де-факто с книгами, написанными об этом. Есть одна книга, которая охватывает как Bash, так и Z-shell , но нет книги, которая охватывает только ее, хотя есть несколько книг, которые делают это для Bash.

И в этот момент, если дистрибутивы изменят настройки по умолчанию для обновлений существующей системы, это нарушит настройки, так как некоторые файлы инициализации имеют разные имена (например, .bashrc против .zshrc), а содержимое файлов может иметь несовместимый синтаксис. Поэтому они очень неохотно делают это, оставляя новые загрузки с zsh по умолчанию и обновления с bash. Вероятно, они не хотят поддерживать два разных значения по умолчанию для одного и того же дистрибутива, и пользователи / компании также не хотят иметь с ними дело.

Самокат
источник
1

Все языки оболочки Unix ужасны. Некоторые особенно ( csh), некоторые, может быть, немного меньше (на kshсамом деле я не знаю), но на самом деле, когда речь идет о таких аспектах, как читаемость и жесткость для больших проектов, ни один из них не может приблизиться к хорошо разработанным языкам общего назначения, таким как Python, C # или Haskell. Таким образом, когда вы хотите что-то твердое, вы никогда не выберете какой-либо вкус оболочки.

Вы выбираете их, когда хотите быстро сделать простые вещи. Для этого вам нужно:

  • Краткий синтаксис и достаточная согласованность, чтобы вы могли его запомнить (сложно найти сокращенные операторы). Это имеет большое значение, если ваша оболочка установлена ​​везде, потому что вы действительно не запомните более одного из этих монстров-клуджей.
  • Хорошие интерактивные функции, так что вы можете взломать прямо в терминал и получить работу без необходимости переключаться между несколькими файлами сценариев.
  • Возможность получить любой фрагмент скрипта из любой точки мира и заставить его работать. shСовместимость - большой плюс, и, опять же, чем популярнее, тем лучше.

Итак, вы видите, популярность в этих языках оболочки является гораздо более важной, чем для языков общего назначения. Следовательно, даже если kshязык «немного лучше» сам по себе, на самом деле не так уж много преимуществ в его использовании, если bashон немного более популярен (как это было в соответствующем секторе, поскольку он был впервые выбран по умолчанию). для GNU).

Люди, которые действительно делают переключение, обдумывают это и достаточно опытны, чтобы легко справиться с переключением на свою любимую оболочку. OTOH, новичок, который вынужден работать с менее популярной оболочкой, будет очень запутан, если он попросит что-то в Интернете, и это не сработает. Следовательно, любой дистрибутив, нацеленный не только на ветеранов Unix, подвергается некоторому риску, если он делает что-то, кроме bashстандарта, шаг, от которого сравнительно мало людей выиграют (и только немного).

leftaroundabout
источник
1
Любой язык, который заботится о количестве пробелов, не «хорошо продуман», но я согласен, что популярность - это ключ.
Нагора
1
@Нагора: мнения разные. FWIW, вы всегда можете написать Haskell с фигурными скобками и точками с запятой вместо пробела, и я предполагаю, что Python имеет аналогичные запасные варианты. Только никто этого не делает, потому что группировка на основе отступов просто удивительна для читабельности.
оставил около
1
  1. Это было там, когда это было необходимо
  2. Этого достаточно, чтобы начинающие пользователи могли потратить неделю на настройку своего приглашения.
  3. В общих случаях использования это достаточно хорошо (наиболее распространенным является запуск одной команды)
  4. Где это не достаточно хорошо, Perl, Python и Lua могут восполнить провал.
  5. Perl делает ужасную интерактивную оболочку
  6. хотя fish, ksh или zsh теоретически могут быть лучшей оболочкой, для меня недостаточно улучшений, чтобы беспокоиться, когда perl работает так хорошо или переносимость является проблемой, поэтому я все равно нацеливаюсь на dash.
hildred
источник
0

«Критическая масса» - главный ответ ИМО. Bash предназначен не только для работы с командной строкой, но и для сценариев, и существует огромное количество сценариев Bash. Независимо от того, насколько лучше альтернатива для взаимодействия, необходимость иметь возможность «подключить и играть» в этих сценариях перевешивает такие преимущества. Таким образом, единственная оболочка, которая может реально отменить Bash сейчас, это полностью обратная совместимость, и наиболее вероятным кандидатом для этого является ... следующая версия Bash.

нагора
источник
1
Вы можете использовать любые скрипты bash независимо от того, какая у вас оболочка по умолчанию. Вот что означает «она» (#! / Bin / bash) в верхней части скрипта.
Пантера
1
@ bodhi.zazen Пока оболочка bash существует в системе. Я знаю по крайней мере версию Solaris, которая не включает bash.
Тулаинс Кордова
@ bodhi.zazen Ментальные затраты на необходимость переключения между двумя оболочками - одна для взаимодействия и одна для сценариев. Это вообще не стоит беспокоиться.
Нагора
1
@Nagora Что ментальная стоимость запуска сценария?
Кос
@kos, если вы буквально просто запускаете сценарии, нет. Если вам нужно поддерживать и адаптировать сценарии, то вам нужно помнить, что зачастую между небольшими различающимися базовыми оболочками существуют довольно небольшие различия, и в этом случае существует постоянная стоимость металла и стоимость переключения контекста, когда вам приходится выполнять некоторую работу в «другой» синтаксис.
Нагора