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

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 [...]

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

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

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

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

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

Вот это уже интереснее. Хотя, имхо, все равно бессмысленно.

M>Тем более, что цитата про C++ относится только к source файлам С++. И то, судя по комментариям, тому же gcc на это наплевать (и правильно).
Не нахожу, что это правильно. Чем жестче соблюдается стандарт — тем лучше. Тем не менее, мой ответ тебя удовлетворил?

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

M>>Тем более, что цитата про C++ относится только к source файлам С++. И то, судя по комментариям, тому же gcc на это наплевать (и правильно).
V>Не нахожу, что это правильно. Чем жестче соблюдается стандарт — тем лучше. Тем не менее, мой ответ тебя удовлетворил?

Нет, меня удовлетворил ответ тут

Автор: KipDblK
Дата: 17.03.10

M>Нет, меня удовлетворил ответ тут

Автор: KipDblK
Дата: 17.03.10

Ну и ладушки.

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

_>>Мы же не о Си-сорцах говорим. Так что выстрел мимо цели.
V>Ты по ссылке ходил?

Да.

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

Плохо читал. Я увидел. Для меня проблем не вызывает.

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

Когда кажется, говорят, креститься надо. В общем, не надо примерять всё на свои привычки.

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

Спецификация. Да, возможно, неудобная, но спецификация. Кстати, в моём кронтабе другая спецификация и другое поведение.

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

Я думаю тебе будет интересно почитать Advanced Bash-Scripting Guide. Есть на нерусском, и на русском

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

KDK>Согласно секции Definitions стандарта IEEE Std 1003.1-2008
Это персональное видение POSIX-ов.

KDK>3.395 Text File
KDK>A file that contains characters organized into zero or more lines.
Ну что же ты, цитруй полностью:

A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. Although POSIX.1-2008 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.

Как видим, тут ещё много интересного, например ограничения на длину строки.
+ В реальности нормальные утилиты которые требуют new-line в конце последней строки — при её отсутствии всеми силами пытаются предупреждать об этом. В итоге проще её обрабатывать чем городить какой-то бред на ровном месте.

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

KDK>>Согласно секции Definitions стандарта IEEE Std 1003.1-2008
F>Это персональное видение POSIX-ов.

Мы все еще про линухи говорим? Напомню вопрос был про крон с его кронтабом и почему в линухах файлы текстовые должны оканчиваться переводом строки. Линух все-таки пока еще следуют пути, завещанном нам великим позиксом. Потому логическая цепочка "В линухе это так, потому что написано в позиксе" вполне верна.

F>Ну что же ты, цитруй полностью:
F>

A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. Although POSIX.1-2008 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.

F>Как видим, тут ещё много интересного, например ограничения на длину строки.
F>+ В реальности нормальные утилиты которые требуют new-line в конце последней строки — при её отсутствии всеми силами пытаются предупреждать об этом. В итоге проще её обрабатывать чем городить какой-то бред на ровном месте.

Ну вот такой стандарт. и утилиты в общем случае не должны обрабатывать такую последнюю строку. Вот такой олдфажный крон

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

KDK>Мы все еще про линухи говорим? Напомню вопрос был про крон с его кронтабом и почему в линухах файлы текстовые должны оканчиваться переводом строки. Линух все-таки пока еще следуют пути, завещанном нам великим позиксом. Потому логическая цепочка "В линухе это так, потому что написано в позиксе" вполне верна.
Тут это звучало как, что такое текстовый файл вообще. В плане цепочки логики — не знаю, не уверен. Сразу же не знаешь, что позикс, а что нет.

KDK>Ну вот такой стандарт. и утилиты в общем случае не должны обрабатывать такую последнюю строку. Вот такой олдфажный крон
Опять же — утилиты описанные в стандарте. Всем прочим, имхо, — надо держаться подальше от таких мест стандарта, которые вводят неясные ограничения и потенциальный источник ошибок. А утилитам в 2010-м году вполе можно было бы и изменится. Впрочем крон штука такая, любой кто о нём хоть что-то читал, знает вроде как про последнюю строку.

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

KDK>>Ну вот такой стандарт. и утилиты в общем случае не должны обрабатывать такую последнюю строку. Вот такой олдфажный крон
F> Опять же — утилиты описанные в стандарте. Всем прочим, имхо, — надо держаться подальше от таких мест стандарта, которые вводят неясные ограничения и потенциальный источник ошибок. А утилитам в 2010-м году вполе можно было бы и изменится. Впрочем крон штука такая, любой кто о нём хоть что-то читал, знает вроде как про последнюю строку.

Стандарт датирован 2008 годом. не думаю, что за 2 года многое поменялось. Тут опять все упирается в то, что некоторые пользуются некошерными редакторами, которые позволяют сделать текстовый файл неправильного формата. Те, кто юзает православные редакторы никогда и не узнали бы об этой "проблеме".

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

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

KDK>>>Ну вот такой стандарт. и утилиты в общем случае не должны обрабатывать такую последнюю строку. Вот такой олдфажный крон
F>> Опять же — утилиты описанные в стандарте. Всем прочим, имхо, — надо держаться подальше от таких мест стандарта, которые вводят неясные ограничения и потенциальный источник ошибок. А утилитам в 2010-м году вполе можно было бы и изменится. Впрочем крон штука такая, любой кто о нём хоть что-то читал, знает вроде как про последнюю строку.

KDK>Стандарт датирован 2008 годом. не думаю, что за 2 года многое поменялось. Тут опять все упирается в то, что некоторые пользуются некошерными редакторами, которые позволяют сделать текстовый файл неправильного формата. Те, кто юзает православные редакторы никогда и не узнали бы об этой "проблеме".

Ну, тут упирается в «данне для людей или люди для данных» и «будь толерантен к тоу, что идет на вход»

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

KDK>>Стандарт датирован 2008 годом. не думаю, что за 2 года многое поменялось. Тут опять все упирается в то, что некоторые пользуются некошерными редакторами, которые позволяют сделать текстовый файл неправильного формата. Те, кто юзает православные редакторы никогда и не узнали бы об этой "проблеме".
M>Ну, тут упирается в «данне для людей или люди для данных» и «будь толерантен к тоу, что идет на вход»

Ну я в этом плане ужасно тоталитарный и нетолерантный человек. Тех кто не соблюдает стандартны или толерантен к их нарушению немедленно предаю поруганию

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

F>Как видим, тут ещё много интересного, например ограничения на длину строки.
F>+ В реальности нормальные утилиты которые требуют new-line в конце последней строки — при её отсутствии всеми силами пытаются предупреждать об этом. В итоге проще её обрабатывать чем городить какой-то бред на ровном месте.

Нередко бывает так, что за дурацким на первый взгляд требованием, скрывается некий смысл. В данном случае, new-line в конце файла — небольшой контроль того, что файл целый, а не его огрызок.

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

M>Нередко бывает так, что за дурацким на первый взгляд требованием, скрывается некий смысл. В данном случае, new-line в конце файла — небольшой контроль того, что файл целый, а не его огрызок.
Небольшой контроль того, что файл целый можно сделать используя CRC/HASH. И то — полной гарантии нет.

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

KDK>Стандарт датирован 2008 годом. не думаю, что за 2 года многое поменялось. Тут опять все упирается в то, что некоторые пользуются некошерными редакторами, которые позволяют сделать текстовый файл неправильного формата. Те, кто юзает православные редакторы никогда и не узнали бы об этой "проблеме".
cron написали используя стандарт 2008-го года? Скорее просто не трогают, то что работает. В том числе и стандарт.

Кошерные-некошерные... Редактора который устроил бы абсолютно всех не существует. Мне например лишняя пустая строка в конце файлов которыя я редактировал — абсолютно незачем.

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

KDK> M>Ну, тут упирается в «данне для людей или люди для данных» и «будь толерантен к тоу, что идет на вход»

KDK> Ну я в этом плане ужасно тоталитарный и нетолерантный человек. Тех кто не соблюдает стандартны или толерантен к их нарушению немедленно предаю поруганию

1.8. Применение философии Unix. Искусство программирования для UNIX. Эрик С. Реймонд.

Будьте "великодушны" к тому, что поступает, и строги к тому, что выпускается."

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

KDK>> Ну я в этом плане ужасно тоталитарный и нетолерантный человек. Тех кто не соблюдает стандартны или толерантен к их нарушению немедленно предаю поруганию
H>1.8. Применение философии Unix. Искусство программирования для UNIX. Эрик С. Реймонд.
H>

Будьте "великодушны" к тому, что поступает, и строги к тому, что выпускается."

Ну вот я и строг к тому, что выпускается редакторами/человеками А то, что человеку поступет, оно может и "плавать" в некоторых рамках. Человек -- он белковый -- разберет %-)

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

KDK> KDK>> Ну я в этом плане ужасно тоталитарный и нетолерантный человек. Тех кто не соблюдает стандартны или толерантен к их нарушению немедленно предаю поруганию

KDK> H>1.8. Применение философии Unix. Искусство программирования для UNIX. Эрик С. Реймонд.
KDK> H>

Будьте "великодушны" к тому, что поступает, и строги к тому, что выпускается."

KDK> Ну вот я и строг к тому, что выпускается редакторами/человеками А то, что человеку поступет, оно может и "плавать" в некоторых рамках. Человек -- он белковый -- разберет %-)

Это применительно к себе

F>>Как видим, тут ещё много интересного, например ограничения на длину строки.
F>>+ В реальности нормальные утилиты которые требуют new-line в конце последней строки — при её отсутствии всеми силами пытаются предупреждать об этом. В итоге проще её обрабатывать чем городить какой-то бред на ровном месте.

M>Нередко бывает так, что за дурацким на первый взгляд требованием, скрывается некий смысл. В данном случае, new-line в конце файла — небольшой контроль того, что файл целый, а не его огрызок.

Да ладно, контроль

данные данные данные \n
данные данные данные \n
\n
данные данные данные \n
данные данные данные \n
\n
---- здесь произошел тот самый обрыв ----
данные данные данные \n
данные данные данные \n
\n

Контроль надо производить другими средствами

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

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

Тут нашел занимательный пример на предмет демонстрации "нелогичности" шелла (не советую запускать на удаленном сервере).

В частности на баше:

:(){ :|:& };:

Говорят, что аналогом под windows является код (для пакетного файла):

%0|%0

но его мне не на чем проверить.