Объясните пару вещей:

1.

#! /bin/sh

$LIST="a b"

for VAR in ${LIST}
do
    echo ${VAR}
done

for VAR in "a b"
do
    echo ${VAR}
done

выведет

a
b
a b

Почему? Вернее, какого хрена?

2.

#! /bin/sh

# правильно
VAR=value

#неправильно
VAR = value

Почему? Вернее, какого хрена?

3. Зачем нужен перевод строки в конце файла в том же кронтабе?

Здравствуйте, Mamut, Вы писали:

M>1.
M>Объясните пару вещей:

Специфицировано башем. В документации даже есть. Элементы, разделённые пробелом, считаются списком. В втором случае у тебя один элемнт. При определении ты говоришь LIST="a b" (без $, кстати), то есть a b (так как " определяют границы), что и подставляется. Во втором случае делаешь "a b", то есть один элемент. Если сделаешь for VAR in "${LIST}" (кстати, можешь просто $LIST), то получишь такой же результат.

M>Почему? Вернее, какого хрена?

Спецификация.

M>2.
M>Почему? Вернее, какого хрена?

Спецификация.

M>3. Зачем нужен перевод строки в конце файла в том же кронтабе?

M>>1.
M>>Объясните пару вещей:

TBG>Специфицировано башем. В документации даже есть.
эээ. да? man bash дает вот это. Там, вроде, нет

TBG>Элементы, разделённые пробелом, считаются списком. В втором случае у тебя один элемнт. При определении ты говоришь LIST="a b" (без $, кстати), то есть a b (так как " определяют границы), что и подставляется. Во втором случае делаешь "a b", то есть один элемент. Если сделаешь for VAR in "${LIST}" (кстати, можешь просто $LIST), то получишь такой же результат.

То есть в одном случае "" означает одно, а в другом — другое? «Удобно», ничего не скажешь. Нет, к этому привыкаешь, не спорю.

M>>Почему? Вернее, какого хрена?
TBG>Спецификация.

Имхо, достаточно нелогичная спецификация

M>>2.
M>>Почему? Вернее, какого хрена?

TBG>Спецификация.

Аналогично

M>>3. Зачем нужен перевод строки в конце файла в том же кронтабе?

А тут?

Здравствуйте, Mamut, Вы писали:

# неправильно
$LIST="a b"
# правильно
LIST="a b"

for VAR in a b c de f
do
    echo ${VAR}
done

a
b
c
de
f

M> # правильно
M> VAR=value
M> # неправильно
M> VAR = value
M> Почему? Вернее, какого хрена?

Потому что во втором варианте VAR будет восприниматься как команда (утилита с именем VAR и параметрами = и value)

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, Mamut, Вы писали:

AB>

AB># неправильно
AB>$LIST="a b"
AB># правильно
AB>LIST="a b"
AB>

Да, доллар я случайно поставил

AB>

AB>for VAR in a b c de f
AB>do
AB>    echo ${VAR}
AB>done
AB>

Но почему?

M>> # правильно
M>> VAR=value
M>> # неправильно
M>> VAR = value
M>> Почему? Вернее, какого хрена?

AB>Потому что во втором варианте VAR будет восприниматься как команда (утилита с именем VAR и параметрами = и value)

Это я понял, но не понимаю логики

Здравствуйте, Mamut, Вы писали:

M>#неправильно
M>VAR = value

Потому что нужно иметь возможность вызывать команды как VAR1=value1 VAR2=value2 command. Поэтому же echo ==COMPILING== ничего никуда не присваивает.

Здравствуйте, Mamut, Вы писали:

А вроде есть.

M>эээ. да? man bash дает вот это. Там, вроде, нет

А ты хотел как? Например, в выражении "\"" что должна означать каждая кавычка?

M>То есть в одном случае "" означает одно, а в другом — другое? «Удобно», ничего не скажешь. Нет, к этому привыкаешь, не спорю.

По мне так логичная.

M>Имхо, достаточно нелогичная спецификация

Я в цитировании вверху отвечаю. Там тоже спецификация.

M>А тут?

Здравствуйте, Mamut, Вы писали:

M> Но почему?

Ну, как бы кавычки — это не определение строки, а определение неразрывности параметра, чтобы он не парсился как список. Например:

$ svn commit -m Строка с пробелами даст ошибку потому что воспринимается как несколько параметров
$ svn commit -m 'Строка с пробелами в кавычках воспринимается как один параметр'

Так же и в скрипте

LIST=неразрывная_строка
LIST="строка с пробелами"

И очень частая грабля:

FILE_NAME="/home/abbat/отчет по продажам.doc"

# ой-ой
rm -f ${FILE_NAME}

# правильно
rm -f "${FILE_NAME}"

M> AB>Потому что во втором варианте VAR будет восприниматься как команда (утилита с именем VAR и параметрами = и value)
M> Это я понял, но не понимаю логики

Логика такова, что в шелловском скрипте основную массу составляют системные команды и очень мало встроенных конструкций. Например:

#!/bin/sh

STRING=""

if ${STRING}
then
    echo "STRING is true"
else
    echo "STRING is false"
fi

if [ ${STRING} ]
then
    echo "STRING is true"
else
    echo "STRING is false"
fi

Дает на первый взгляд парадоксальный результат:

STRING is true
STRING is false

Но все становится на свои места, когда:

STRING="false"

Дает в результате

STRING is false
STRING is true

P.S. символ "[" является алиасом системной утилиты test, ман которого раскроет суть происходящего, false — это тоже системная утилита.

TBG>Я в цитировании вверху отвечаю.

Здесь так не принято, исправляйся.

TBG>А вроде есть.

M>>эээ. да? man bash дает вот это. Там, вроде, нет

TBG>А ты хотел как? Например, в выражении "\"" что должна означать каждая кавычка?

Ух. Попробуем еще раз.

Специфицировано башем. В документации даже есть. Элементы, разделённые пробелом, считаются списком.

В документации нет ни про спецификацию, ни про синтаксис присвоения переменных, ни про списки. И да, если мы говорим про спецификацию чего-либо, то она должна обхяснять, что значит каждая кавычка в выражении "\"" (и таки описывает, если продраться сквозь текст)

К спискам можно отнести секцию word splitting, но человеческим тот язык назвать нельзя.

То есть таки да, документация по bashу — не для слабонервных

M>>То есть в одном случае "" означает одно, а в другом — другое? «Удобно», ничего не скажешь. Нет, к этому привыкаешь, не спорю.

TBG>По мне так логичная.

Возможно Я просто программист в первую очередь. И это, мягко гооря, кажется нелогичным


M>>Имхо, достаточно нелогичная спецификация

TBG>Я в цитировании вверху отвечаю. Там тоже спецификация.

Да, но откуда она стала тебе известна — хз

M>>А тут?

Так что про newline в кронтабе?

M>Объясните пару вещей:
Изначально надо понять, что баш — это не язык программирования. Основная задача любого скрипта на баше — это запуск внешних программ. Следовательно, любой синтаксис башевской операции будет с расчетом на это.

M>Почему? Вернее, какого хрена?
Потому, что "a b" = это один элемент, а b — два. Если бы это было не так, ты бы не мог упаковать список в переменную или не мог бы иметь элементы списка с пробелами.

M># правильно
M>VAR=value
M>#неправильно
M>VAR = value
M>Почему? Вернее, какого хрена?
Потому, что a=b это операция присваивания, а =b — это вызов программы а с параметром =b. Почему — см. выше.

M>3. Зачем нужен перевод строки в конце файла в том же кронтабе?
А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?

V>Потому, что a=b это операция присваивания, а =b — это вызов программы а с параметром =b. Почему — см. выше.

Черт, не получается войны по этим пунктам

M>>3. Зачем нужен перевод строки в конце файла в том же кронтабе?
V>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?

По какому стандарту?

Здравствуйте, Mamut, Вы писали:

V>>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?
M>По какому стандарту?

По определению.
Текстовый файл -- файл, состоящий из строк.
Строка -- последовательность символов, завершенная переводом строки.
Делаем вывод, что текстовый файл завершается переводом строки.

Здравствуйте, Vamp, Вы писали:

M>>3. Зачем нужен перевод строки в конце файла в том же кронтабе?
V>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?

Цитатку бы...

V>>>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?
M>>По какому стандарту?

KDK>По определению.
KDK>Текстовый файл -- файл, состоящий из строк.
KDK>Строка -- последовательность символов, завершенная переводом строки.
KDK>Делаем вывод, что текстовый файл завершается переводом строки.

С чего это вдруг? По определению он может заканчиваться переводом строки (каким из них, кстати?) или EOF. Вполне логично

V>>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?
M>По какому стандарту?
См, например, здесь:

http://stackoverflow.com/questions/729692/why-should-files-end-with-a-newline

The C language standard says A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character.
This is in section 2.1.1.2 of the ANSI C 1989 standard. Section 5.1.1.2 of the ISO C 1999 standard (and probably also the ISO C 1990 standard).

Здравствуйте, Mamut, Вы писали:

KDK>>По определению.
KDK>>Текстовый файл -- файл, состоящий из строк.
KDK>>Строка -- последовательность символов, завершенная переводом строки.
KDK>>Делаем вывод, что текстовый файл завершается переводом строки.
M>С чего это вдруг? По определению он может заканчиваться переводом строки (каким из них, кстати?) или EOF. Вполне логично

Согласно секции Definitions стандарта IEEE Std 1003.1-2008

3.205 Line
A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

3.395 Text File
A file that contains characters organized into zero or more lines.

Здравствуйте, KipDblK, Вы писали:

Вдогонку

3.238 Newline Character (<newline>)
A character that in the output stream indicates that printing should start at the beginning of the next line. It is the character designated by '\n' in the C language.

V>>>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?
M>>По какому стандарту?
V>См, например, здесь:

V>http://stackoverflow.com/questions/729692/why-should-files-end-with-a-newline

V>

V>The C language standard says A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character.
V>This is in section 2.1.1.2 of the ANSI C 1989 standard. Section 5.1.1.2 of the ISO C 1999 standard (and probably also the ISO C 1990 standard).

Оттуда мне больше нравится вариант

This originates from the very early days when simple terminals were used. The newline char was used to trigger a 'flush' of the transferred data.

Тем более, что цитата про C++ относится только к source файлам С++. И то, судя по комментариям, тому же gcc на это наплевать (и правильно).

Здравствуйте, Vamp, Вы писали:

V>>>А это вообще по стандарту. Ты знаешь, что по стандарту текстовый файл обязан кончаться переводом строки?
M>>По какому стандарту?
V>См, например, здесь:

V>http://stackoverflow.com/questions/729692/why-should-files-end-with-a-newline

V>

V>The C language standard [...]

Мы же не о Си-сорцах говорим. Так что выстрел мимо цели.