() - это subshell

Круглые скобки - запуск подпроцесса (отдельного процесса bash) и выполнение кода в нём:

$ echo $BASHPID; ( echo $BASHPID; )
13427
13279

В принципе Ваш код должен работать правильно, если не считать того, что так делать нерационально.

P.S. Проблемы будут, если попытаетесь изменить какие-то переменные из основной программы внутри порождённого процесса: естественно, в основном процессе они и не подумают изменяться.

О... в этом то и проблема как раз! Спасибо, я понял свою ошибку. То есть какого-то короткого способа записи

if []; then
else
fi

Способ есть, но скобки тебе в этом не помогут. Дай конкретный контекст.

То есть какого-то короткого способа записи

в общем случае нет

можно попробовать «echo ...» поставить раньше - оно реже отваливается, но тоже может: «exec >&-; echo stdout && echo stderr >&2»

Есть:

[[ $condition ]] && { code_if_true; } || code_if_false

Квадратные скобки никаких сабшеллов не создают.

Фигурные же.

А зачем нужны двойные квадратные скобки []?

[[ $condition ]]

Да, фигурные :)

«[[» - это нативный оператор сравнения BASH, который быстрее и функциональнее прочих и неплохо заменяет даже "((" (для алгебраических сравнений).

[[ $x > $y ]]
[[ $x =~ ^foo(bar)?$ ]] && \
  echo ${BASH_REMATCH[1]}
[[ $x && ($y || $z) ]]

etc.

В вашем случае ругается... на код

PRINT="Print1"
[[ "$1" ]] && { echo "true"; PRINT="Print true"; } || { echo "false"; PRINT="Print false" }
echo "$PRINT"

$ ./test 0
./test: 5: ./test: Syntax error: end of file unexpected (expecting "}")

Ты точку с запятой после «Print false» забыл.

Прочитав последнее сообщение понял что у вас bash... просто у меня shell т.к. на arm-девайсе, для которого предназначаются скрипты есть только sh.

И я забыл ; исправил, да в таком виде работает, спасибо

#!/bin/sh
PRINT="Print1"
[ $1 != 0 ] && { echo "true"; PRINT="Print true"; } || { echo "false"; PRINT="Print false"; }
echo "$PRINT"

Так, а в чем прикол? у меня одинаково с круглыми и фигурными исполняется, только с круглыми процесс создается еще.

PRINT=«Print1» не будет заменен на PRINT=«Print true/false» с круглыми.

А, ну да!

тоже может: exec >&-;

Блин, как это сделать теперь обратно?

«[[» - это нативный оператор сравнения BASH, который быстрее и функциональнее прочих

непереносим, относится к т.н. башизмам и за его использование в приличном обществе бъют по лицу.

Есть один нюанс, когда условие true, а code_if_true завершится с отличным от нуля статусом, то выполнится code_if_false.

правильно!

только хардкор, только ash.

непереносим, относится к т.н. башизмам и за его использование в приличном обществе бъют по лицу.

Да какая разница? Ведь bash/shell в приличном обществе и не используют.

относится к т.н. башизмам и за его использование в приличном обществе бъют по лицу.

Ну и общество у вас.

Бсдуны, что с них взять. Как будто никому не плевать на их боли.

А что используют?

Что им мешает в бзде баш использовать?

Подозреваю, что фанатизм

Если у башиста #!/bin/sh, то все правильно, только по лицу. С ноги.

Тут не спорю.

И ещё, в догонку.

непереносим

Всё хочу спросить, куда вы их все, блядь, переносить собираетесь? В Стиме продавать? Шелловские скрипты пишутся в 99.999999% случаев для конкретной системы, а то и машины.

С каких пор сборище идиотов стало называться «приличным обществом»?

BASH есть под все известные мне платформы, я на AIX написал башевого кода не так уж и мало. Если говорить о дефолте, то он вообще чуть ли не в каждом никсе свой, и это чаще не sh, чем sh. А главное, у ТС по-любому sh, так что какая разница?

Плюсую. Ничего не мешает, кроме религиозных воззрений

BASH есть под все известные мне платформы

Зато установлен по умолчанию далеко не на всех.

Если говорить о дефолте, то он вообще чуть ли не в каждом никсе свой

А это не важно. Важно что это POSIX совместимый шелл, на котором башизмы работать не обязаны.

А главное, у ТС по-любому sh

Именно что sh, а не bash. А вы вводите человека в заблуждение, расписывая преимущества непереносимой конструкции, и забыв упомянуть что она, собственно, непереносима.

расписывая преимущества непереносимой конструкции, и забыв упомянуть что она, собственно, непереносима.

Куда переносим-то и зачем? Можно реальные, не фантастические, массовые переносы продемонстрировать? И чттоб «башизмы» помешали.

например, когда пишешь configure.ac или автотулзовские M4 макросы, весьма желательна переносимость

И чттоб «башизмы» помешали.

Ну попробуй, запусти /bin/sh скрипт со своими [[ на дебиане. Там /bin/sh это, на минуту, dash. А скрипт с /bin/bash запусти на FreeBSD. Там его никогда по этому пути не будет.

Есть прекрасная утилита env. А во FreeBSD ещё в 2009-м году был сплошной уродский csh, в котором были абсолютно чудовищные сишизмы. И что? сиш был тогда хорош, потому что BSD?

BASH - самая распространённая командная оболочка для Linux, Linux - самая распространённая *nix-система. bash есть даже для android и ставится элементарно. И да, если на то пошло, тот же python тоже по дефолту есть далеко не везде, а в Debian не только dash, но ещё и некий IceWeasel (потому что Debian, и этим всё сказано). При этом в Debian всё-таки есть, внезапно, /bin/bash.

И что? сиш был тогда хорош, потому что BSD?

были абсолютно чудовищные сишизмы

Про которые все были в курсе и всем не навязывали.

сиш был тогда хорош, потому что BSD?

Во времена оные, оригинальный bourne shell был ну совсем уж restricted. Вот взять dash, выкинуть от туда ${var#$%/} синтаксис и прочие >&- получим времена csh и того родителя bash.

BASH - самая распространённая командная оболочка для Linux,

Проблема как обычно в том, что тот же синтаксис [[ имеет несовместимости с 2-3-4 версиями bash. Я нарывался и было весьма неприятно. Оно и понятно, когда имеем типичный линусковый подход: сейчас мы по быстрому сделаем модно-молодёжно и круто наперекор вашим старческим догмам, а потом оказывается, что имеются противоречия в синтаксисе.

Но это не важно. Самое смешное в этом топике в том, что теперь можно-молодёжно ни за что не юзать if/then/else! Такое чувству, что мир сошёл с ума.

Про которые все были в курсе и всем не навязывали.

Ну, наконец-то баш сравнили с системди. Аплодирую стоя.

синтаксис [[ имеет несовместимости с 2-3-4 версиями bash.

Да, как и в любом другом языке. Вы, уважаемый, на k&r C до сих пор пишете?

удобство, я так понимаю, в принципе не рассматривается? и кто тут религиозен после этого

Да, как и в любом другом языке. Вы, уважаемый, на k&r C до сих пор пишете?

Вы не поверите, но я даже иногда использую синтаксис cmd_if && { cmd1; cmd2 }. Хотя изначально синтаксис с одельностоящими фигурными скобками придуман был для группировки команд с едиными файловыми перенаправлениями. Но оказалось, что для очень коротких комманд, типа { echo Ok; exit 0} вполне сойдёт и для && / || синтаксиса. Но нет же, по молодёжному инфантильно-нигилистическому ясен пень надо обязательно выдирать гланды через задний проход, и кто так не делает, тот старопердун. Смешно и грустно.

В качестве домашнего задания можете попытаться понять, почему в dash до сих пор нет синтаксиса «подстрока» - ${par:offs:len}, подсказка - где там противоречия в синтаксисе у bash.

например, когда пишешь configure.ac или автотулзовские M4 макросы, весьма желательна переносимость

А ещё есть Makefile, который вообще не на шелле. Кто-то призывает их писать на баше? Я же не зря оставил 0.000001%. И это повод отказываться от возможностей новых версий языка?

В качестве домашнего задания

Смахнул слезу со щетины.

Расскажи нахера эти [[ нужны? Кроме поиска приключений на свою жопэ.

Удивительно, какое противостояние вызвал, казалось бы, безобидный топик) bash я ни использовать, ни поставить не могу, поскольку ОС под arm-девайс поставляется мне «as is», в виде образа, который накатываешь через U-Boot, какие-то недостающие мне утилиты я могу взять из Buildroot, но в целом там все весьма скупо...

Честно говоря, я не думаю, что такая ситуация редка, многие проприетаарные решения могут работать десятилетиями просто потому что работает. Мне вот сейчас выдали обновление с 4.9, так вот, то nand отваливается, то kernel panic...

И я уже пару раз нарвался на то, что видя прикольный скрипт, обламывался потому что он работает на bash-е, хотя на гите в описании пишут «shell-script for...», ну написали бы «bash-script for...» я бы даже время на него тратить не стал бы! Многие почему-то проводят знак равенства между ними, наверное это следствие того, что многие работают в полных неурезанных системах.

Многие почему-то проводят знак равенства между ними

что с утят взять. правда, ашотик?