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

Question 1

Этот скрипт представляет собой тонкую оболочку вокруг простого API PulseAudio. Это позволяет вам записывать отсчеты по умолчанию:

#!/usr/bin/env python3

import random
import ctypes
import struct

class NoiseMaker (object):

    PA_SAMPLE_U8 = 0
    PA_STREAM_PLAYBACK = 1

    def __init__(self, rate, channels):
        pat_sample_spec = ctypes.c_buffer(struct.pack("LLB",
            self.PA_SAMPLE_U8, rate, channels))
        self.pa = ctypes.cdll.LoadLibrary("libpulse-simple.so.0")
        self.s = self.pa.pa_simple_new(0, "App", self.PA_STREAM_PLAYBACK,
            0, "App Noise", ctypes.byref(pat_sample_spec), 0, 0,0)

    def write(self, data):
        self.pa.pa_simple_write(self.s, data, len(data), 0)

    def __del__(self):
        self.pa.pa_simple_free(self.s)


one_second_noise = bytes(random.randint(0, 255) for i in range(44100*2))
NoiseMaker(44100, 2).write(one_second_noise)

. Скорость (44100) определяет, сколько выборок есть во второй в реальном времени. Он ожидает байтов в диапазоне 0-255 включительно, который определяется PA_SAMPLE_U8 (эквивалентно «Unsigned 8-Bit», как показано Audacity, например). Если у вас более одного канала, он ожидает чередующихся выборок для каждого из них. Таким образом, одна секунда шума имеет 44100 выборок на канал = 88200 выборок, где (по модулю 2 = 0) для левого канала.

Обратите внимание, что этот скрипт работает только на Python 3 [!d2 ]

Question 2

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

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

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

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

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

Question 3

Question 4

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

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

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

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

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

Question 5

Это было там, когда это было необходимо. У него достаточно глазных конфет, которые начинаются с пользователей, которые могут потратить неделю на настройку своей подсказки. Обычные случаи использования достаточно хороши (наиболее распространенным является запуск одной команды). Если он недостаточно хорош perl, python и lua могут занять слабину. perl делает ужасную интерактивную оболочку, хотя рыба, ksh или zsh теоретически может быть лучшей оболочкой, для меня не хватает улучшения, когда perl работает так хорошо, или переносимость - проблема, поэтому я все равно нацеливаюсь на тире.

Question 6

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

Scooter · Answer 1 · 23 May 2018 в 19:38

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

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

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

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

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

leftaroundabout · Answer 2 · 23 May 2018 в 19:38

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

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

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

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

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

Любой язык, который заботится о количестве пробелов, не «хорошо разработан», но я согласен с тем, что популярность - это ключ. — Nagora, 21 June 2015 в 19:37
@Nagora: мнения меняются. FWIW, вы всегда можете написать Haskell с фигурными скобками и точками с запятой вместо пробелов, и я полагаю, что Python имеет аналогичные резервные копии. Только, никто этого не делает, потому что группировка с отступом просто потрясающая для удобочитаемости. — leftaroundabout, 21 June 2015 в 23:01

hildred · Answer 3 · 23 May 2018 в 19:38

Это было там, когда это было необходимо. У него достаточно глазных конфет, которые начинаются с пользователей, которые могут потратить неделю на настройку своей подсказки. Обычные случаи использования достаточно хороши (наиболее распространенным является запуск одной команды). Если он недостаточно хорош perl, python и lua могут занять слабину. perl делает ужасную интерактивную оболочку, хотя рыба, ksh или zsh теоретически может быть лучшей оболочкой, для меня не хватает улучшения, когда perl работает так хорошо, или переносимость - проблема, поэтому я все равно нацеливаюсь на тире.

Nagora · Answer 4 · 23 May 2018 в 19:38

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

0

ответ дан Nagora 23 May 2018 в 19:38

1

Вы можете использовать любой скрипт bash, какой бы он ни был. Это то, что означает «she-bang» (#! / Bin / bash) в верхней части скрипта. – Panther 21 June 2015 в 01:35
2

@ bodhi.zazen Пока оболочка bash существует в системе. Я знаю, по крайней мере, версию Solaris, которая не включает bash. – Tulains Córdova 21 June 2015 в 02:37
3

@ bodhi.zazen Существует ментальная стоимость переключения между двумя оболочками - одна для взаимодействия и одна для скриптов. Это вообще не стоит беспокоить. – Nagora 21 June 2015 в 19:36
4

@Nagora Какова ментальная стоимость , выполняющая скрипт? – kos 21 June 2015 в 20:00
5

@kos, если вы буквально запускаете скрипты, нет. Если вам нужно поддерживать и адаптировать сценарии, вам нужно иметь в виду часто довольно небольшие различия между различными базовыми оболочками, и в этом случае текущая стоимость металла и стоимость переключения контекста, когда вам нужно выполнить некоторую работу в & Quot; другой & Quot; синтаксис. – Nagora 25 June 2015 в 10:51

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

4 ответа

Другие вопросы по тегам:

Похожие вопросы: