чтения -N и IFS

Question

Согласно «читать -n» описание на странице руководства:

-N nchars вернуться только после прочтения именно символы NCHARS, если EOF не встречается или читать раз вне, игнорируя любой разделитель

Однако, в ответ на следующую команду:

$ echo 'a b' | while read -N1 c; do echo ">>>$c<<<"; done 
>>>a<<< 
>>><<< 
>>>b<<< 
>>><<< 

как пространство и символ новой строки были переведены на пустую строку, в то время как в команде:

$ echo 'a b' | while IFS= read -N1 c; do echo ">>>$c<<<"; done 
>>>a<<< 
>>> <<< 
>>>b<<< 
>>> 
<<< 

пространство и новая линия были правильно сохранены в переменной.

Итак, у разделителей все еще есть обработка в команде «читать» или «пока», что я не понимаю.

Мы могли бы сравнить эти результаты с теми, с помощью «чтений -n», что руководство описывается как:

-n nchars вернуться после прочтения символов NCHARS вместо того, чтобы ждать новой строки, но если меньше чтить разделитель чем NCHARS символы читаются перед разделителем

$ echo 'a b' | while read -n1 c; do echo ">>>$c<<<"; done 
>>>a<<< 
>>><<< 
>>>b<<< 
>>><<< 

$ echo 'a b' | while IFS= read -n1 c; do echo ">>>$c<<<"; done 
>>>a<<< 
>>> <<< 
>>>b<<< 
>>><<< 

Answer 1

hexdump Использование позволяет увидеть именно символы, составляющие выходного сигнала, так что это может быть полезно, чтобы немного изменить свои запросы:

(1) При нормальном МФС и с помощью опции -N

$ (echo 'a b' | while read -N1 c; do c="$c<"; echo -n "$c"; done | hexdump -C) 
00000000 61 3c 3c 62 3c 3c         |a<<b<<| 
00000006 

В этом первом случае прочитанное встроенное значение для 0x0a и символ пробела возвращает пустую строку, так как символы находятся в IFS по умолчанию, а символы в IFS игнорируются на выходе по причине, объясненной в ans cdarke WER.

(2) С пустым МФСОМ и опцией -N

$ (IFS=""; echo 'a b' | while read -N1 c; do c="$c<"; echo -n "$c"; done | hexdump -C) 
00000000 61 3c 20 3c 62 3c 0a 3c        |a< <b<.<| 
00000008 

В этом случае чтение встроенное будет соответствовать каждому из четырех символов, что эхо-команда выводит, и оба 0x0a и пространство рассматриваются в едином вывод, потому что с пустым IFS считываемые символы могут быть назначены локальной переменной c.

(3) с нормальным МФСОМ и опцией -n

$ (echo 'a b' | while read -n1 c; do c="$c<"; echo -n "$c"; done | hexdump -C) 
00000000 61 3c 3c 62 3c 3c         |a<<b<<| 
00000006 

Это дает точно такой же результат, как при (1), хотя семантика немного отличается: для чтения и для встроенного 0x0a и пространства символ возвращает пустую строку, так как (i) оба этих символа находятся в IFS по умолчанию, и (ii) опция -n для считывания встроенного языка в любом случае не проходит по символу 0x0a

(4) С пустая опция IFS и -n

$ (IFS=""; echo 'a b' | while read -n1 c; do c="$c<"; echo -n "$c"; done | hexdump -C) 
00000000 61 3c 20 3c 62 3c 3c        |a< <b<<| 
00000007 

Здесь мы наблюдаем разницу между параметрами -n и -N для чтения: с опцией -n, новая строка обрабатывается специально с помощью встроенного чтения и отбрасывается, поэтому исключениеиз IFS не имеет возможность разрешить его передать локальной переменной c.

Answer 2

на мой взгляд, при использовании опции -N поведение read отличается при

• Чтение разделителя в качестве входных данных
• Назначения, что разделитель в переменную

Когда он читает символ, разделитель угощение, как же, как и не-ограничитель и read будет считать их. Но, когда read назначает разделитель, он считает, что если считываемый ввод является разделителем или нет, если он является разделителем, он присваивает нуль соответствующей переменной.

Таким образом, IFS= изменит поведение присвоения пробела переменной и вызовет присвоение пространства c, а не null.

Answer 3

Это POSIX поведение. При назначении переменной символы IFS должны быть удалены: результаты должны быть разделены на поля, как в оболочке, для результатов расширения параметров (конечно, -n и -N не являются POSIX).

Это рождённый из кодовых комментариев read источника:

/* This code implements the Posix.2 spec for splitting the words 
    read and assigning them to variables. */ 
    orig_input_string = input_string; 

    /* Remove IFS white space at the beginning of the input string. If 
    $IFS is null, no field splitting is performed. */ 

Answer 4

read не может решить, если символ является разделителем (игнорировать его) до тех пор, пока уже прочитали характер, и read должен назначить some значение c, даже если это значение является пустой строкой. Когда разделитель считывается и затем отбрасывается, значение c должно быть установлено в чем-то, поэтому ему назначается пустая строка.

Это согласуется с read, используемым без опций -n/-N; разделители отбрасываются только после, они считываются и если нет необходимости устанавливать значение предоставленных параметров. Самый простой случай, когда вы не предоставляют никаких аргументов в read:

$ read <<< " a b c " 
$ echo ">>>$REPLY<<<" 
>>> a b c <<< 

С помощью одного явного аргумента, начальные и конечные разделители раздели:

$ read line <<< " a b c " 
$ echo ">>>$line<<<" 
>>>a b c<<< 

С двух аргументов, первый разделитель игнорируется после его чтения. Второй сохраняется, потому что строка должна быть разбита на два слова, чтобы заполнить предоставленные параметры.

$ read field1 field2 <<< " a b c """ 
$ echo ">>>$field1<<<" 
>>>a<<< 
$ echo ">>>$field2<<<" 
>>>b c<<<