bash vs sh: моя запутаться

Ребенок познает мир — как мило.

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

(Пальцем в небо) баш видит, что его запустили под именем ш, и он запускается в каком-либо режиме совместимости.

до этого я уже догадался, интересно где именно он спотыкается.
есть у меня скриптик в 1800+ строк, в котором используются вроде как все конструкции из кода в ОП, но он таким не страдает

А если bash use deadbeef ololo?

И дай выхлоп именно find_category в первом случае и во втором

bash трам-пам-пам работает - это понятно
выхлопы

[ megabaks@desktop ] ~ $ sh portopts/test deadbeef ololo
[ megabaks@desktop ] ~ $ bash portopts/test deadbeef ololo
media-sound

[ megabaks@desktop ] ~ $ 

до этого я уже догадался, интересно где именно он спотыкается.

	done <<< "${categories}"

Это чисто башевская конструкция.

https://github.com/megabaks/portconf/blob/master/portconf
151 раз используется «<<<» и при этом он нормально овер sh отрабатывает

Хмм, я запустил тоже, такая же фигня

Причем, оно валится сразу же после первого source

user@meowr /tmp $ sh test.sh 
waat
test.sh: line 5: /etc/make.conf: Нет такого файла или каталога
user@meowr /tmp $ cat test.sh 
target=bash

find_category(){
echo waat
        source "/etc/make.conf"
echo wat

Видимо, в sh так нужно. При этом set +x не влияет

Т.е. если вот так сделать, то все работает:

        if [ -f "/etc/make.conf" ]; then
                source "/etc/make.conf"
        elif [ -f "${PORT_ETC}/make.conf" ]; then
                source "${PORT_ETC}/make.conf"
        fi

странно это всё...
ща попробую

и при этом он нормально овер sh отрабатывает

тестить скрипты на баше в режиме совместимости почти бесполезно

для этих целей больше подходит dash, ибо он больше на настоящий sh похож и не позволяет башизмов

$ read lol <<< lol
sh: 2: Syntax error: redirection unexpected
$ 

бинго!
сраный sh спотыкается именно на этом.
а bash молодец.
оставлю на всякий случай костыль.
решено.

ставить сие не имеет смысла.
а перепиливать под sh тем более глупо - в том же portconf 151 раз используется <<< - всё это перепиливать на костыли совместимости не имеет смысла, тем более что в генте bash есть всегда - таки часть портажа на нём

почему-бы тебе явно не написать #!/bin/bash в самом начале? Причём это /bin/bash должно указывать именно на bash. Вот так:

$ file /bin/bash
/bin/bash: ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Тогда неоднозначностей не будет, и ОС будет точно знать, чем ей пользоваться. Можно и ключей напихать.

#!/bin/bash --posix

echo $POSIXLY_CORRECT

скажет «y».

почему-бы тебе явно не написать

это и написано - если ты внимательно читал, то должен был заметить, что ./ололо работает как надо

дык в чём твоя проблема?

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

и тут до Штирлица начало что-то доходить

тем более глупо - в том же portconf 151 раз используется <<< - всё это перепиливать на костыли

а, не, ложная тревога

в генте bash есть всегда - таки часть портажа на нём

Шта!? Это дискриминация! Пойду, прибью bash у себя в уютненькой!

/bin/sh -> bash это не то же самое, что /bin/bash

Баш догадывается, что его вызвали не по имени, а по симлинку? Srsly?

Он не о симлинке догадывается, а знает, по какой команде он был запущен.

Баш догадывается, что его вызвали не по имени, а по симлинку? Srsly?

Да. Нулевой аргумент /bin/sh, а не /bin/bash и баш меняет поведение. Это обычная практика. Например все команды LVM, это линки на один бинарник /sbin/lvm

Про нулевой аргумент забыл, прошу прощения.

Баш догадывается, что его вызвали не по имени, а по симлинку? Srsly?

оно читает argv[0], там как раз имя записано.

Вот ещё примеры:

swapoff -> swapon

umount -> ../bin/umount

reboot -> halt
poweroff -> halt

Например все команды LVM

ещё busybox эпичный пример.