пустая строка трактуется как true?

echo выводит свои аргументы в stdout. Если у неё получилось вывести текст в stdout, что во встроенном echo из bash получается вообще всегда, она возвращает 0, то есть «успех».

echo $(echo $1 || echo bar)

echo "${1:-Default value}"

проверив на пустоту аргумента

echo ${1:-bar}

${parameter:?word} e.g.

arg=${1:?Argument is required}

Здесь нет проверки того, что выводится, вне зависимости от того, трактуется ли пустая строка как true или как false.

echo "" вернёт, обычно, 0 (так как успешно вывело).
||, выполнив свой первый аргумент, увидит «0» (шелловское true). Обрадуется. Второй аргумент выполнять не надо, пустая строка левого вывелась, ок. Вернёт (не выведет, а именно вернёт) 0.

$(...) подставят _вывод_ команды внутри них, не возвращаемое значение. То бишь пустую строку от echo "". И будет в итоге всё как и задумывалось.

Проверить можно, к примеру, сравнив $# с количеством аргументов, или пользуясь shift,

${parameter:?word}

Это не bash-only? Даже в zsh такого не вижу, не говоря о всяких {,k,c}sh.

$(...) подставят _вывод_ команды внутри них, не возвращаемое значение. То бишь пустую строку от echo "". И будет в итоге всё как и задумывалось.

А можно как-то пробросить само значение? Через пайп там, или как? Я сейчас проверил, по ходу, да, все ж пустая строка трактуется как false, на таком вот примере: if test ""; then echo 1; done; fi

man test
...
An omitted EXPRESSION defaults to false.
$ test || echo false
false

Вот так правильно if test "''"; then echo 1; done; fi? То есть, все таки, пустая строка — true, так?

Спасибо за темки по башу. Не перестаю ржать от синтаксиса решения элементарных вещей в нём.

Это не bash-only? Даже в zsh такого не вижу, не говоря о всяких {,k,c}sh.

Ну да наверное. Так posix shell никто и не просил (см. тэги).

Я знаю, что не просили, просто поинтересовался.

Вы путаете шелл с каким-то другим языком. Пустая строка никак не «трактуется», это просто вывод в поток. А так можно либо сохранить ее в переменную и проверить оную на пустоту, либо пропустить поток через что-то что будет возвращать ноль/не ноль в зависимости от наличия данных. foo | grep " || echo Пусто, например

К удаленному сообщению:

$ export A="a"
$ test -n "$A" && echo not empty || echo empty
not empty

$ unset A
$ test -n "$A" && echo not empty || echo empty
empty

проверив на пустоту аргумента

test -z $1 && echo bar

man test

Встроенный работает же. help test

Это не bash-only?

нет

А где ещё можно применить?

В zsh и ksh не работает.

Встроенный

замечание верное, но в этой части от внешнего не отличается.

Спасибо за темки по башу. Не перестаю ржать от синтаксиса решения элементарных вещей в нём.

ну, вообще-то, классическим решением всегда было:

if [ "x$1" == "x" ]; then
  echo argument is NULL
else
  echo argument is $1
fi;

гы, профдеформация :)

разумеется:

if [ "x$1" = "x" ]; then
  echo argument is NULL
else
  echo argument is $1
fi;

но что странно, `==` тоже работает...

Предупреждение

Некоторые из советов не различают отсутствующие и экстремально короткие аргументы, например:

script
и
script "" "" ""

Ага, то ли дело у нас в ассемблере

Спасибо за темки по башу. Не перестаю ржать от синтаксиса решения элементарных вещей в нём

+1, меня тоже всегда смущало: ну ориентирован язык на работу со строками и командами, но зачем же такую копрофагию разводить...

Это Вы наверное TypeScript ещё не видели.

Объективно синтаксис того же LISP'а хуже, но от этого он не перестаёт быть гениальным языком и наверное универсальной технологией программирования будущего.

В BASH вполне нормальный синтаксис, хотя много и не хватает. У синтаксиса BASH есть один недостаток, общий со всем BASH в целом: работает всё это просто катастрофически медленно, спасает только распараллеливание.

Объективно синтаксис того же LISP'а хуже

можно поднобней

и наверное универсальной технологией программирования будущего.

и вот тут тоже поясните

В BASH вполне нормальный синтаксис

неа. работать с [ассоц.] массивами неприятно.

хотя много и не хватает.

это да

У синтаксиса BASH есть один недостаток, общий со всем BASH в целом: работает всё это просто катастрофически медленно, спасает только распараллеливание.

при чем тут синтаксис?

при чем тут синтаксис?

BASH ещё и парсит свои скрипты небыстро. Наверное, если бы синтаксис был чуть менее заковыристым - парсил бы несколько быстрее.

Объективно синтаксис того же LISP'а хуже, но от этого он не перестаёт быть гениальным языком и наверное универсальной технологией программирования будущего

Я часто задаю вопрос на форуме: как ощутить просветление от LISP? Как мне осознать всю его гениальность? Какие-то сравнительные примеры? Искренне верю что этот язык представляет собой то, что я пока не осознал.

Как мне осознать всю его гениальность?

К сожалению, для этого нужно реально изучать программирование, а не просто заниматься им. Т.е. суть в наличии или отсутствии соотв. багажа знаний. LISP - язык людей с хорошей ВУЗовской подготовкой, знающих теорию программирования, основные алгоритмы, ну и математику конечно тоже. А для любого человека, который в лучшем случае слышал про некую «лево-рекурсивную грамматику», но даже близко не знает, что это - LISP никогда не будет понятным. Скажем так, LISP - это язык, порождённый теорией компиляторов.

бред. современные лиспы алголоподобны, и ничем существенно не отличаются от других языков общего назначения.

Лисп - очень понятен каждому человеку, для которого простой и очевидной покажется вот эта статья: https://ru.wikipedia.org/wiki/Лямбда-исчисление

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

Во первых, не надо путать лисп с лямбда исчислением. Традиционно, лисп не имел к нему никакого отношения, это касалось только одного позднего диалекта — scheme, да и то, это значительно модифицированное и расширенное сайд-эффектами LC

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

И я могу сходу привести примеры, которые ярко показывают превосходство этого языка над другими способами ввода схем. Вот для LISP бы такие примеры. Я не настаиваю. Скажу сразу честно: вряд ли я перейду с C++/Python на LISP...

и ничем существенно не отличаются от других языков общего назначения.

Ну да. Я бы сказал, что LISP - это такая кул-хакерская возможность править не программу на языке программирования, а непосредственно прямо дерево её синтаксического разбора, т.е. некий промежуточный результат преобразования исходного кода на императивном языке в машинный код. Причём это дерево может ещё и модифицировать само себя. Неслабо так :)

да нет этого в современных лиспах. там применяется обычный eval для подобных целей

Вот для LISP бы такие примеры.

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

Довольно популярно-доступные примеры есть тут

http://www.newlisp.org/CodePatterns.html

Вот простой пример оттуда, который как раз показывает одну из основных концепций лиспа — полную рефлексию.

;; sum accumulator
(define (sum (x 0)) (inc 0 x))

(sum 1)    → 1
(sum 2)    → 3
(sum 100)  → 103
(sum)      → 103

sum  → (lambda ((x 0)) (inc 103 x))

Прошу прощения, пока не вставило: суть эффективности не раскрыта. Если меня должен был впечатлить этот пример, то боюсь пока нет. Можно ли словами уточнить, какие возможности открываются исходя из такой возможности языка?

это нечто близкое к концепции ООП. Рефлексия. Вместо того чтобы думать о о коде и данных и способах их взаимодействия, вы просто в рантайме модифицируете программу, а затем ее исполняете.

Можно провести параллель с биологическими нейросетями, или, теми же релейными электросхемами. Программа не взаимодействует с данными, она и есть данные. eg нейронные связи изменились, животное меняет свое поведение, просто потому, что нервные импулься идут другими путями. Более простая модель, близкая к природе и физике.