Вышел Bash 3.0

правильно писать надо так #!/usr/local/bin/bash

> я то ли раз, то ли два умудрялся наваять скрипт с /bin/sh, который не пошел сразу в solaris. Детали не спрашивайте - это было давно:)

Я тебе так скажу - это соляркин sh кривой, и не делает того, что по стандарту POSIX обязан.

Например, конструкция вида

if somecommand; then
othercommand
fi

Не работает. Требуется:

if somecommand
then
othercommand
fi

Хотя по-моему верхний вариант еще родной sh от Стива Борна, который был написан на АДЕ, транслировавшейся в C посредством C-шного препроцессора, ещё понимал.

Только что попробовал. Работает на :

#!/bin/sh

if [ 1 = 2 ]; then
echo 1
else
echo 2
fi

На всякий случай даже запускал его как "/bin/sh test.sh"

% uname -X | grep -v Node
System = SunOS
Release = 5.8
KernelID = Generic_108528-23
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 4

2svu: вопрос на засыпку: а КАКОЙ (выделение моё ;) sh тогда оставить в качестве ПОЛНОСТЬЮ POSIX-совместимого в /bin/sh? ;)

Честно скажу - не знаю (поздравляю, засыпали:). Правда. Встречный вопрос - во фряхе под /bin/sh кто скрывается?

>правильно писать надо так #!/usr/local/bin/bash

Неправильно. /usr/local должен быть в отдельном разделе. А у тебя при аварийной загрузке с единственной партицией для корня bash не будет доступен.

моветон не моветон, всегда пишу вначале что bash а не sh чтобы потом вопросов под соляркой не возникало

2svu * (*) (30.07.2004 15:21:57):

> Честно скажу - не знаю (поздравляю, засыпали:). Правда.
> Встречный вопрос - во фряхе под /bin/sh кто скрывается?

Во фряхе под /bin/sh скрывается POSIX-совместимый sh :)

А маскировку bash под sh давить! Тут Вы правы.
Сколько раз уже на таких скриптах приходилось обламываться.

>Заметьте, никто не призывал выкинуть bash. bash - это наше все (после XML, разумеется:). Мой первый пост заканчивался словами: "Наверное, все-таки надо было оставить /bin/sh и /bin/bash разными..."

Это был бы "Not Linux way"

2ansi * (*) (30.07.2004 15:32:28):

> Это был бы "Not Linux way"

Молодец! :)

2svu: конечно засыпал :) насколько я помню, ни один их *sh не является полностью posix-совестимым, они лишь МОГУТ эмулировать некий "абстрактный POSIX sh", естественно - с различной степенью приближения к стандартам POSIX. Так что симлинк с /bin/sh -> /bin/bash - более чем оправдан - заменить-то по сути и нечем :)

Может, фрюшный все-таки взять? Соббсно, смысл разделения bash и sh я вижу (в первую очередь) - в отсечении bash-изов в скриптах для /bin/sh.

А чем bash-измы отличаются от ksh-измов? tclsh-измов? zsh-измов? Может, просто не заниматься любовью с мозгом (как сказал! :) и использовать тот шелл, который больше нравится и использовать #!/bin/bash , #!/bin/ksh , #!/bin/sh , etc для какждого конкретного случая?

4steam:
>А чем bash-измы отличаются от ksh-измов? tclsh-измов? zsh-измов? Может, просто не заниматься любовью с мозгом (как сказал! :) и использовать тот шелл, который больше нравится и использовать #!/bin/bash , #!/bin/ksh , #!/bin/sh , etc для какждого конкретного случая?

Теперь читаем восьмое сообщение сверху и понимаем, что до некоторых _наконец-то_ дошло.

//Loseki

> и использовать #!/bin/bash , #!/bin/ksh , #!/bin/sh , etc

Дык кто бы спорил? Я, соббсно, не имею ничего против #!/bin/bash. Я просто указывал на проблему со скриптами, которые как бы #!/bin/sh, хотя на самом деле #!/bin/bash. Или вообще запретить законодательно (объявить плохим стилем) использование /bin/sh на основании того, что "идеального" /bin/sh в природе не существует?

L='a b "c c" d' и пр.

После подстановки $L кавычки теряют свое спец. значение,
становятся обычным символом.
eval возвращает им спец. значение. Можно так:

$ eval "
>for i in $L
>do
>echo \$i
>done
>"
a
b
c c
d
$

Только обязательно \$i а не $i, чтобы до выполнения
команды не было подстановки (в отличие от L!)

Древний юниксоид

Да, забыл добавить -- в скрипте:

eval for i in $L\; do echo \$i\; done или eval "for i in $L; do echo \$i; done"

Д.ю.

А у меня в дебиане...

nick@xxx:~$ ls -la /bin/sh
lrwxrwxrwx    1 root     root            4 2004-05-19 10:01 /bin/sh -> dash

8)))))

Весьма поучительный тред. Из всех дравших тут глотку только один человек разбирается в sh/bash скриптах. (меня особо умилили массивы в sh 8)

Бедный ты бедный, сделай dpkg-reconfigure -plow dash и отмени нах ссылку на /bin/sh

>и как это пофиксить?

#!/bin/sh

IFS="_" L="a_b_c c_d"; for i in $L; do echo $i done

интересно, что на ftp://ftp.gnu.org/pub/pub/gnu/bash/ этого релиза нет, хотя ссылка на файл с comp.unix.shell есть ... это как понимается? :/

Прочитав новость уже было обрадовался, но вспомнил, что несколько месяцев пользуюсь zsh и менять его на bash не собираюсь. Автодополнение параметров комманд, целей для make и имен комманд при желании прочтитать ман - это то, что нравится лично мне в zsh! IHMO, лучше пока ничего не придумали :))

>Автодополнение параметров комманд, целей для make и имен комманд при желании прочтитать ман - это то, что нравится лично мне в zsh! IHMO, лучше пока ничего не придумали :))

У меня тоже самое, но при использовании bash.

С/у, Ден.

как это будет не пидароксально - но у меня тоже !

Подскажи, как настроить атодополнение параметров.

мля .. признаю - обосЦался ...

это я перепутал с той системой которая мне по наследству досталась - там у меня получалось - хотя что там ща шел был - я не смотрел - а то что на баше писал - всё атлечна была....

>Видишь ли, есть такая штука - "стандарт POSIX" называется, умные дяди >писали... а нужна она, чтоб можно было, скажем, configure-скрипты и >тому подобные вещи пускать под любым унихом, у которого есть POSIX >shell.

Интересно, как запустить bsd или slack скрипты под шапкой или мандракой :)

Вообще-то тут абсолютно верно был подмечен "dash" как более близкий к POSIX sh чем bash. Далее выдержка из описания:

Description: The Debian Almquist Shell
"dash" is a POSIX compliant shell that is much smaller than "bash".
We take advantage of that by making it the shell on the installation
root floppy, where space is at a premium.
.
It can be usefully installed as /bin/sh (because it executes scripts
somewhat faster than "bash"), or as the default shell either of root
or of a second user with a userid of 0 (because it depends on fewer
libraries, and is therefore less likely to be affected by an upgrade
problem or a disk failure). It is also useful for checking that a
script uses only POSIX syntax.
.
"bash" is a better shell for most users, since it has some nice
features absent from "dash", and is a required part of the system.

Для ленивых ключевая фраза: >It is also useful for checking that a script uses only POSIX syntax.

>Это Ваши домыслы. Расширенные конструкции, отсутствующие в sh, никуда не исчезают.

Это очень хорошо. Тебя же не огорчает, что на твоем PIV не исчезают инструкции MMX, SSE, когда он обрабатывает программу, собранную под i386?

>> Это Ваши домыслы. Расширенные конструкции, отсутствующие в sh, никуда не исчезают.

>Это очень хорошо. Тебя же не огорчает, что на твоем PIV не исчезают инструкции MMX, SSE, когда он обрабатывает программу, собранную под i386?

Линуксоид? RH знаешь? Тогда вот аналогия: какими словами ты назовешь урода, упаковавшего собранную под PIV программу с MMX и SSE в blah-blah.i386.rpm? А если он еще при этом будет заявлять, что "так оно же под x86, и не моя проблема, что твой i386 не умеет расширенные конструкции, я всегда свой проц с собой таскаю на такой случай".

>>> Это Ваши домыслы. Расширенные конструкции, отсутствующие в sh, никуда не исчезают.

>>Это очень хорошо. Тебя же не огорчает, что на твоем PIV не исчезают инструкции MMX, SSE, когда он обрабатывает программу, собранную под i386?

>Линуксоид? RH знаешь? Тогда вот аналогия: какими словами ты назовешь урода, упаковавшего собранную под PIV программу с MMX и SSE в blah-blah.i386.rpm? А если он еще при этом будет заявлять, что "так оно же под x86, и не моя проблема, что твой i386 не умеет расширенные конструкции, я всегда свой проц с собой таскаю на такой случай".

Ребята чето вас не в ту степь понесло.... :-)))

> Ребята чето вас не в ту степь понесло.... :-)))

Аналогия самая прямая.