Bash-3.0 contains the following new features (see the manual page for
complete descriptions and the CHANGES and NEWS files in the bash-3.0
distribution):
o Features to support the bash debugger have been implemented, and there
is a new `extdebug' option to turn the non-default options on
o HISTCONTROL is now a colon-separated list of options and has been
extended with a new `erasedups' option that will result in only one
copy of a command being kept in the history list
o Brace expansion has been extended with a new {x..y} form, producing
sequences of digits or characters
o Timestamps are now kept with history entries, with an option to save
and restore them from the history file; there is a new HISTTIMEFORMAT
variable describing how to display the timestamps when listing history
entries
o The `[[' command can now perform extended regular expression (egrep-like)
matching, with matched subexpressions placed in the BASH_REMATCH array
variable
o A new `pipefail' option causes a pipeline to return a failure status if
any command in it fails
o The `jobs', `kill', and `wait' builtins now accept job control notation
in their arguments even if job control is not enabled
o The `gettext' package and libintl have been integrated, and the shell
messages may be translated into other languages
Кстати, это подножка для скриптописателей. Они пишут #!/bin/sh - используют в скриптах bash-измы - а потом удивляются, что на солярке-хпуксе-... оно не работает. Наверное, все-таки надо было оставить /bin/sh и /bin/bash разными...
> The `gettext' package and libintl have been integrated, and the shell messages may be translated into other languages
Гы... Интересно: сколько найдётся любителей попользоваться командной строкой, неспособных перевести со словарём с английского на свой родной?
Как-то в моём представлении (и опыте) коммандлайнер --- это одна из финальных ступеней развития, начинавшегося с понимания того, что перед использованием программы, к ней полезно почитать документацию, причём на языке оригинала (как правило английском).
Когда bash вызывается как /bin/sh, он максимально пытается эмулировать посиксовый sh. Так что это Ваши домыслы :) Выдержка из man bash:
If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.
> коммандлайнер --- это одна из финальных ступеней развития, начинавшегося с понимания того, что перед использованием программы, к ней полезно почитать документацию
сколько пафоса.. чтение доков оправдано для функционально СЛОЖНОЙ программы. аргументы командой строки оправданы только для АВТОМАЦИИ, скажем читать ман вгета чтобы просто скачать файл - эта какая ступень развития? (привет фригету кстати!) гуй, хоть и неавтоматизируемый, но до некоторой степени САМОДОКУМЕНТИРУЕМ, даже названия кнопок уже заменяют поиск букв аргументов в мане. да, когда прога посложнее, или иначе говоря - ориентирована на повер юзеров, доки читать полезно и нужно. но если ориентирована на юзеров (гуй!), необходимость чтения документации - плохой знак.
> Это Ваши домыслы. Расширенные конструкции, отсутствующие в sh, никуда не исчезают
А Вы читайте, читайте дальше: "...while conforming to the POSIX standard as well" и "When invoked as sh, bash enters posix mode after the startup files are read". Не знаю, на сколько близко он соответствует этим стандартам, а проверять мне лениво, но ДОЛЖЕН им при вызове сооветствовать. По крайней мере, по документации.
> svu абсолютно прав насчет bash-измов. Только тот, кто всю жизнь просидел в линуксе и виндах, не сталкивался с ними.
Каждый шелл имеет свои особенности, и это не есть отличительная черта bash-а.
>Кстати, это подножка для скриптописателей. Они пишут #!/bin/sh - используют в скриптах bash-измы - а потом удивляются, что на солярке-хпуксе-... оно не работает.
Это цитата из ru.linux годичной давности (почти слово в слово)? :)
можно триста раз прочитать, что там кто-то пишет, но практика показывает обратное: скрипт написанный типа на sh под линуксом отказался работать под freebsd-шным sh. причем грабля была в работе с массивами. так что теория без практики - мертва.
подскажите где нейти человеческую доку по программированию в sh?
типа башевского advanced bash scripting, где бы нормально описывалась работа с массивами, мат вычисления и т.д. и т.п.
Нда...нашли блин недостаток - bash он видите ли не sh.
Вы бы еще сказали, что хаммер плохо эмулирует запор.
:)
А у меня и на HP-UX и на Solaris везде bash стоит и меня совсем не волнует, что мои скрипты могут содержать bashизмы. Как я думаю всяких фанатов *sh не волнует что их *sh несовместима с sh совсем.
Видишь ли, есть такая штука - "стандарт POSIX" называется, умные дяди писали... а нужна она, чтоб можно было, скажем, configure-скрипты и тому подобные вещи пускать под любым унихом, у которого есть POSIX shell.
Совершенно согласен.
Что отнють не делает всевозможные csh/ksh/*sh фуфлом, верно?
Чем вам мешает bash?
Я скорее соглашусь, что проблема в том, что в linux нет чистого sh.
Руки прочь от bash!
:)
Выделение мое:) Я точно не помню - но я то ли раз, то ли два умудрялся наваять скрипт с /bin/sh, который не пошел сразу в solaris. Детали не спрашивайте - это было давно:) Вообще, где бы посмотреть, чем это TRIES отличается от реального /bin/sh?...
***
вот, а вы мне объясните, почему такая прога:
for i in a b "c c" d; do
echo $i
done
выводит:
a
b
c c
d
а такая:
L='a b "c c" d'
for i in $L; do
echo $i
done
выводит:
a
b
"c
c"
d
и как это пофиксить?
Заметьте, никто не призывал выкинуть bash. bash - это наше все (после XML, разумеется:). Мой первый пост заканчивался словами: "Наверное, все-таки надо было оставить /bin/sh и /bin/bash разными..."
Всё дело в волшебных пузырьках, то бишь в кавычках. В дебрях man'а это где-то расписано. Если на пальцах, то одинарная кавычка отменяет "специальность" двойной.