forum.opennet.ru - "Стандартные потоки ввода/вывода в UNIX/Linux" (33)

"Стандартные потоки ввода/вывода в UNIX/Linux"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
Сообщение от opennews (??), 14-Июл-09, 19:07
В заметке (http://xgu.ru/wiki/stdin) подробно рассматривается, что такое стандартные потоки ввода и вывода, и какие вещи с ними можно делать. Рассматриваются как базовые вопросы использования потоков ввода/вывода, так и тонкости и хитрости, например, почему не работает echo text \| read val и ряд других. URL: http://xgu.ru/wiki/stdin Новость: http://www.opennet.me/opennews/art.shtml?num=22596
Ответить \| Правка \| Cообщить модератору

Оглавление

То, что доктор прописал, хорошая статья, Аноним (-), 19:07 , 14-Июл-09, (1) +1

Исчо лучше http gazette linux ru net rus articles abs-guide index htmlhttp g, pavlinux (ok), 05:57 , 15-Июл-09, (20)

я лучше POSIX 1 почитаю В этой статье даже не упоминается простой способ избав, Аноним (-), 19:07 , 14-Июл-09, (2) +1

но как по мне, неправильно использовать - там, где логичнее использовать de, xguru (?), 19:46 , 14-Июл-09, (4) +1

Это уже дело вкуса С одной стороны, зачем писать, если можно не писать Это арг, аноним (?), 19:51 , 14-Июл-09, (6)

Дело не в том даже, а в том, что когда вы используете -, то в общем случае доб, xguru (?), 20:01 , 14-Июл-09, (7)

Нет ls - , аноним (?), 22:35 , 14-Июл-09, (10)

А скажите, пожалуйста, какая ось у вас У меня на GNU Linux ls -ls write err, xguru (?), 22:48 , 14-Июл-09, (13)

на FreeBSD все пучком - нет ошибки ls - Linux у такое поведение с ош, Аноним (-), 00:18 , 15-Июл-09, (14)

кроме того это проблема не bash а, а GNU ls , Аноним (-), 00:23 , 15-Июл-09, (16)

А почему это проблема ls Разве не у каждой программы ДОЛЖНЫ быть открыты дескри, anonymous_peer (ok), 03:04 , 15-Июл-09, (19)

Ну не проблема, а скорее особенность По крайней мере это именно из-за ls ну и д, xguru (?), 10:39 , 15-Июл-09, (21)

Ну, это же хорошо Лишняя проверка не повредит, а вот её отсутсвие 8212 потен, anonymous_peer (ok), 18:49 , 16-Июл-09, (28)

Мне вот интересно,ls и проч вылетает, когда видит, что STDOUT закрыт,или продол, xguru (?), 21:42 , 16-Июл-09, (31)
Во-первых, что значит 171 вылетает 187 Завершается раньше времени но по со, anonymous_peer (ok), 02:21 , 17-Июл-09, (32)

FreeBSD, аноним (?), 02:31 , 15-Июл-09, (18)

bin echo Ага - echo Таки-ага 124 124 echo Не-а bin echo о, Andrey Mitrofanov (?), 12:05 , 15-Июл-09, (23)

И эти люди запрещают мне W Wрассказывают о кроссплатформенности, переносимоти, п, Andrey Mitrofanov (?), 12:28 , 15-Июл-09, (24)

_ОНИ_ это кто Я, наверное, пропустил какую-то жестокую тему, xguru (?), 21:41 , 16-Июл-09, (30)

Сначала подумал, что элементарщина, но узнал для себя что-то новое Спасибо , anonymous_peer (ok), 19:20 , 14-Июл-09, (3) +1
Один написал бред, другой подхватил Указанная конструкция замечателно работает , аноним (?), 19:48 , 14-Июл-09, (5)

У вас какой shell tcsh В sh bash это не работает, проверьте, если не леньТема ск, xguru (?), 20:02 , 14-Июл-09, (8)

gt оверквотинг удален Хотя однако, какой tcsh, там же read нет Так что таки ba, xguru (?), 20:08 , 14-Июл-09, (9)

У меня zsh , аноним (?), 22:36 , 14-Июл-09, (11)

В zsh работает, проверил только что Спасибо за поправку, xguru (?), 22:43 , 14-Июл-09, (12)

в tcsh есть для чтения значения переменной из стандартного ввода blah H, Аноним (-), 00:29 , 15-Июл-09, (17)

Это немножечко не то Нужно же было прочитать строку из вывода другого процесса , xguru (?), 10:44 , 15-Июл-09, (22)

foo echo value 124 head -n 1 , gegMOPO4 (ok), 17:10 , 15-Июл-09, (26)

в случае tcsh скорее, Аноним (-), 20:10 , 15-Июл-09, (27)

Не, ребята, это всё не то нужно чтобы read читал только одну строку,а остальное , xguru (?), 21:39 , 16-Июл-09, (29)

Note that unlike some other shells, sh executes each process in the pipe 8, Аноним (-), 00:22 , 15-Июл-09, (15)

Спасибо, очень полезно Большинство знал, но некоторые моменты облегчат работу в, Блуд (ok), 16:02 , 15-Июл-09, (25)
Merci, очень полезная статья , 42 (?), 11:53 , 20-Ноя-20, (33)

Сообщения [Сортировка по времени | RSS]

1. "Стандартные потоки ввода/вывода в UNIX/Linux" +1 +/–

Сообщение от Аноним (-), 14-Июл-09, 19:07

То, что доктор прописал, хорошая статья

Ответить | Правка | Наверх | Cообщить модератору

20. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от pavlinux (ok), 15-Июл-09, 05:57

Исчо лучше!
http://gazette.linux.ru.net/rus/articles/abs-guide/index.html
http://gazette.linux.ru.net/rus/articles/abs-guide/c11849.html

http://tldp.org/LDP/abs/html/
http://tldp.org/LDP/abs/html/io-redirection.html

Ответить | Правка | Наверх | Cообщить модератору

2. "Стандартные потоки ввода/вывода в UNIX/Linux" +1 +/–

Сообщение от Аноним (-), 14-Июл-09, 19:07

я лучше POSIX[1] почитаю. В этой статье даже не упоминается простой способ избавиться от нежелательного вывода/ввода путем *закрытия* дескриптора. Напр,
    $ ls >&- 2>&-
А также, что `команда >&файл' и `команда1 |& команда2' являются расширением в tcsh, bash, zsh и отсутствует в ash (almquist shell) и posix shell'е.
[1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_...

Ответить | Правка | Наверх | Cообщить модератору

4. "Стандартные потоки ввода/вывода в UNIX/Linux" +1 +/–

Сообщение от xguru (?), 14-Июл-09, 19:46

>я лучше POSIX[1] почитаю. В этой статье даже не упоминается простой способ
>избавиться от нежелательного вывода/ввода путем *закрытия* дескриптора. Напр,
>    $ ls >&- 2>&-
>
>А также, что `команда >&файл' и `команда1 |& команда2' являются расширением в tcsh, bash, zsh и отсутствует в ash (almquist shell) и posix shell'е.
>
>[1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_...
>&- нормальная вещь, спасибо,
но как по мне, неправильно использовать >&- там, где логичнее использовать > /dev/null
Сравните
ls >&-
и
ls > /dev/null

Ответить | Правка | Наверх | Cообщить модератору

6. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от аноним (?), 14-Июл-09, 19:51

Это уже дело вкуса. С одной стороны, зачем писать, если можно не писать? Это аргумент за >&-. Ведь devfs может быть вообще не смонтирован (в chroot/jail например). Кроме того, так короче.
С другой стороны, /dev/null нагляднее и проще понять где /dev/null заменить на не /dev/null.
Я в общем всецело за /dev/null.

Ответить | Правка | Наверх | Cообщить модератору

7. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 14-Июл-09, 20:01

>Это уже дело вкуса. С одной стороны, зачем писать, если можно не писать? Это аргумент за >&-. Ведь devfs может быть вообще не смонтирован (в chroot/jail например). Кроме того, так короче.
>С другой стороны, /dev/null нагляднее и проще понять где /dev/null заменить на
>не /dev/null.
>Я в общем всецело за /dev/null.
Дело не в том даже, а в том, что когда вы используете >&-,
то в общем случае добавляется ещё одна ошибка в поток:
$ ls >&-
ls: write error: Bad file descriptor

Ответить | Правка | Наверх | Cообщить модератору

10. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от аноним (?), 14-Июл-09, 22:35

Нет.
% ls >&-
%

Ответить | Правка | Наверх | Cообщить модератору

13. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 14-Июл-09, 22:48

>Нет.
>
>% ls >&-
>%
А скажите, пожалуйста, какая ось у вас?
У меня на GNU/Linux:
% ls >&-
ls: write error: Bad file descriptor
book% bash
$ ls >&-
ls: write error: Bad file descriptor

Ответить | Правка | Наверх | Cообщить модератору

14. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Аноним (-), 15-Июл-09, 00:18

> $ ls >&-
> ls: write error: Bad file descriptor
на FreeBSD все пучком - нет ошибки.
    $ ls >&-
    $
Linux'у такое поведение с ошибкой можно было б простить, если бы сия функция не была одной из базовых в posix shell'е.

Ответить | Правка | Наверх | Cообщить модератору

16. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Аноним (-), 15-Июл-09, 00:23

>Linux'у такое поведение с ошибкой можно было б простить, если бы сия
>функция не была одной из базовых в posix shell'е.
кроме того это проблема не bash'а, а GNU ls.

Ответить | Правка | Наверх | Cообщить модератору

19. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от anonymous_peer (ok), 15-Июл-09, 03:04

>>Linux'у такое поведение с ошибкой можно было б простить, если бы сия
>>функция не была одной из базовых в posix shell'е.
>
>кроме того это проблема не bash'а, а GNU ls.
А почему это проблема ls? Разве не у каждой программы ДОЛЖНЫ быть открыты дескрипторы 0, 1 и 2 при её запуске?

Ответить | Правка | Наверх | Cообщить модератору

21. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 15-Июл-09, 10:39

Ну не проблема, а скорее особенность.
По крайней мере это именно из-за ls (ну и других прог, потому что не только ls так себя ведёт, а многое гнутое из того, что я проверил).
Проблема ли это или не проблема, сложно сказать.
По крайней мере, он бы мог тупо забивать
и пользователю оставалось бы только догадываться,
закрыт дескриптор или нет.
Вот как здесь:

#include<stdio.h>
main()
{
    printf("opennet rulez\n");
    fprintf(stderr, "opennet rulez (stderr)\n");
}
$ gcc -o /tmp/h h.c
$ /tmp/h
opennet rulez
opennet rulez (stderr)
$ /tmp/h >&-
opennet rulez (stderr)
$
Но он заботится о пользователе
и ставит его в курс дела.

Ответить | Правка | Наверх | Cообщить модератору

28. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от anonymous_peer (ok), 16-Июл-09, 18:49

Ну, это же хорошо! Лишняя проверка не повредит, а вот её отсутсвие — потенциальный баг в программе.

Ответить | Правка | Наверх | Cообщить модератору

31. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 16-Июл-09, 21:42

>Ну, это же хорошо! Лишняя проверка не повредит, а вот её отсутсвие
>— потенциальный баг в программе.
Мне вот интересно,
ls и проч. вылетает,
когда видит, что STDOUT закрыт,
или продолжает работать,
просто ошибку выводит?
Наверное, вылетает

Ответить | Правка | Наверх | Cообщить модератору

32. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от anonymous_peer (ok), 17-Июл-09, 02:21

>Мне вот интересно,
>ls и проч. вылетает,
>когда видит, что STDOUT закрыт,
>или продолжает работать,
>просто ошибку выводит?
>
>Наверное, вылетает
Во-первых, что значит «вылетает»? Завершается раньше времени (но по собственному желанию) или убивается системой (то есть получает сигнал, от которого умирает)?
Да и если ls не убивается, то что ему дальше делать-то? В любом случае завершится.
У меня (GNU) ls >&- возвращает 2, значит, завершается самостоятельно. И, потом, было бы странно сначала проверить stdout на возможность вывода, сообщить о том, что он закрыт, а дальше, несмотря на это, что-то сделать так, чтобы тебя убили.

Ответить | Правка | Наверх | Cообщить модератору

18. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от аноним (?), 15-Июл-09, 02:31

FreeBSD

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

23. "+1 / Если не видно разницы?" +/–

Сообщение от Andrey Mitrofanov (?), 15-Июл-09, 12:05

>Сравните
$ /bin/echo 'Ага.' >&- && echo "Таки-ага." || echo 'Не-а!'
/bin/echo: ошибка записи: Bad file descriptor
Не-а!
$ /bin/echo 'Ага.' > /dev/null && echo "Таки-ага." || echo 'Не-а!'
Таки-ага.
$ _

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

24. "уй-ё... опять _они_" +/–

Сообщение от Andrey Mitrofanov (?), 15-Июл-09, 12:28

И эти люди запрещают мне^W^Wрассказывают о кроссплатформенности, переносимоти, позиксвейности и не-баш-измости... http:/openforum/vsluhforumID3/47017.html#7
И ведь каждый раз одно, блин, и то же: "-Вы в шеле? -Нет, мы в шеле! -А, я думал, вы в шеле..."

Ответить | Правка | Наверх | Cообщить модератору

30. "уй-ё... опять _они_" +/–

Сообщение от xguru (?), 16-Июл-09, 21:41

>И эти люди запрещают мне^W^Wрассказывают о кроссплатформенности, переносимоти, позиксвейности и не-баш-измости... http:/openforum/vsluhforumID3/47017.html#7
>
>
>И ведь каждый раз одно, блин, и то же: "-Вы в шеле?
>-Нет, мы в шеле! -А, я думал, вы в шеле..."
_ОНИ_ это кто?
Я, наверное, пропустил какую-то жестокую тему

Ответить | Правка | Наверх | Cообщить модератору

3. "Стандартные потоки ввода/вывода в UNIX/Linux" +1 +/–

Сообщение от anonymous_peer (ok), 14-Июл-09, 19:20

Сначала подумал, что элементарщина, но узнал для себя что-то новое. Спасибо.

Ответить | Правка | Наверх | Cообщить модератору

5. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от аноним (?), 14-Июл-09, 19:48

> почему не работает echo text | read val и ряд других
Один написал бред, другой подхватил. Указанная конструкция замечателно работает:
% echo text | read var; echo $var
text
вероятно имелось в виду (echo text | read var); echo $var
В общем статья хорошая, но тема скобок совершенно не раскрыта.

Ответить | Правка | Наверх | Cообщить модератору

8. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 14-Июл-09, 20:02

>> почему не работает echo text | read val и ряд других
>
>Один написал бред, другой подхватил. Указанная конструкция замечателно работает:
>
>% echo text | read var; echo $var
>text
>
У вас какой shell?
tcsh?
В sh/bash это не работает, проверьте, если не лень
>вероятно имелось в виду (echo text | read var); echo $var
>
>В общем статья хорошая, но тема скобок совершенно не раскрыта.
Тема скобок это да

Ответить | Правка | Наверх | Cообщить модератору

9. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 14-Июл-09, 20:08

>[оверквотинг удален]
>>Один написал бред, другой подхватил. Указанная конструкция замечателно работает:
>>
>>% echo text | read var; echo $var
>>text
>>
>
>У вас какой shell?
>
>tcsh?
>
Хотя однако, какой tcsh, там же read нет.
Так что таки bash у вас.
Покажите как работает, пожалуйста

Ответить | Правка | Наверх | Cообщить модератору

11. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от аноним (?), 14-Июл-09, 22:36

>Хотя однако, какой tcsh, там же read нет.
>Так что таки bash у вас.
У меня zsh.

Ответить | Правка | Наверх | Cообщить модератору

12. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 14-Июл-09, 22:43

В zsh работает, проверил только что.
Спасибо за поправку

Ответить | Правка | Наверх | Cообщить модератору

17. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Аноним (-), 15-Июл-09, 00:29

> Хотя однако, какой tcsh, там же read нет.
в tcsh есть $< для чтения значения переменной из стандартного ввода
    > set foo=$<
    blah
    > echo Here is my answer: $foo
    Here is my answer: blah

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

22. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 15-Июл-09, 10:44

>> Хотя однако, какой tcsh, там же read нет.
>
>в tcsh есть $< для чтения значения переменной из стандартного ввода
>
>    > set foo=$<
>
>    blah
>    > echo Here is my answer: $foo
>
>    Here is my answer: blah
Это немножечко не то.
Нужно же было прочитать строку из вывода другого процесса.
%> echo value | set foo=$<
%> echo $foo
%>
Не выводит.
Как сделать чтобы работало?
Вариант с командной подстановкой не предлагать,
нужно чтобы читалась одна строка.

Ответить | Правка | Наверх | Cообщить модератору

26. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от gegMOPO4 (ok), 15-Июл-09, 17:10

foo=$(echo value|head -n 1)

Ответить | Правка | Наверх | Cообщить модератору

27. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Аноним (-), 15-Июл-09, 20:10

> foo=$(echo value|head -n 1)
в случае tcsh скорее
    > set foo=`echo value`

Ответить | Правка | Наверх | Cообщить модератору

29. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от xguru (?), 16-Июл-09, 21:39

Не, ребята, это всё не то.
нужно чтобы read читал только одну строку,
а остальное не трогал.
Например, как вы с помощью командной подстановки,
которую вы рекомендуете,
сделаете такое:
|while read line
  do
    ....
  done
Как это сделать в tcsh с помощью той конструкции, которую
вы выше рекомендовали?

Ответить | Правка | Наверх | Cообщить модератору

15. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Аноним (-), 15-Июл-09, 00:22

>> почему не работает echo text | read val и ряд других
>
>Один написал бред, другой подхватил. Указанная конструкция замечателно работает:
     Note that unlike some other shells, sh executes each process in the pipe‐
     line as a child of the sh process.  Shell built‐in commands are the
     exception to this rule.  They are executed in the current shell, although
     they do not affect its environment when used in pipelines.
т.е. команды в конвеере (каналы) не влияют на окружение, в коем они запущены. Кстати, как правильно имплементировать конвееры не оговорено в POSIX. Так что zsh себя тоже правильно ведет.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

25. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от Блуд (ok), 15-Июл-09, 16:02

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

Ответить | Правка | Наверх | Cообщить модератору

33. "Стандартные потоки ввода/вывода в UNIX/Linux" +/–

Сообщение от 42 (?), 20-Ноя-20, 11:53

Merci, очень полезная статья.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Стандартные потоки ввода/вывода в UNIX/Linux"	+1 +/–
Сообщение от Аноним (-), 14-Июл-09, 19:07
То, что доктор прописал, хорошая статья
Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от pavlinux (ok), 15-Июл-09, 05:57
	Исчо лучше! http://gazette.linux.ru.net/rus/articles/abs-guide/index.html http://gazette.linux.ru.net/rus/articles/abs-guide/c11849.html http://tldp.org/LDP/abs/html/ http://tldp.org/LDP/abs/html/io-redirection.html
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Стандартные потоки ввода/вывода в UNIX/Linux"	+1 +/–
Сообщение от Аноним (-), 14-Июл-09, 19:07
я лучше POSIX[1] почитаю. В этой статье даже не упоминается простой способ избавиться от нежелательного вывода/ввода путем закрытия дескриптора. Напр, $ ls >&- 2>&- А также, что `команда >&файл' и `команда1 \|& команда2' являются расширением в tcsh, bash, zsh и отсутствует в ash (almquist shell) и posix shell'е. [1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_...
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Стандартные потоки ввода/вывода в UNIX/Linux"	+1 +/–
	Сообщение от xguru (?), 14-Июл-09, 19:46
	>я лучше POSIX[1] почитаю. В этой статье даже не упоминается простой способ >избавиться от нежелательного вывода/ввода путем закрытия дескриптора. Напр, > $ ls >&- 2>&- > >А также, что `команда >&файл' и `команда1 \|& команда2' являются расширением в tcsh, bash, zsh и отсутствует в ash (almquist shell) и posix shell'е. > >[1] http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_... >&- нормальная вещь, спасибо, но как по мне, неправильно использовать >&- там, где логичнее использовать > /dev/null Сравните ls >&- и ls > /dev/null
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от аноним (?), 14-Июл-09, 19:51
	Это уже дело вкуса. С одной стороны, зачем писать, если можно не писать? Это аргумент за >&-. Ведь devfs может быть вообще не смонтирован (в chroot/jail например). Кроме того, так короче. С другой стороны, /dev/null нагляднее и проще понять где /dev/null заменить на не /dev/null. Я в общем всецело за /dev/null.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 14-Июл-09, 20:01
	>Это уже дело вкуса. С одной стороны, зачем писать, если можно не писать? Это аргумент за >&-. Ведь devfs может быть вообще не смонтирован (в chroot/jail например). Кроме того, так короче. >С другой стороны, /dev/null нагляднее и проще понять где /dev/null заменить на >не /dev/null. >Я в общем всецело за /dev/null. Дело не в том даже, а в том, что когда вы используете >&-, то в общем случае добавляется ещё одна ошибка в поток: $ ls >&- ls: write error: Bad file descriptor
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от аноним (?), 14-Июл-09, 22:35
	Нет. % ls >&- %
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 14-Июл-09, 22:48
	>Нет. > >% ls >&- >% А скажите, пожалуйста, какая ось у вас? У меня на GNU/Linux: % ls >&- ls: write error: Bad file descriptor book% bash $ ls >&- ls: write error: Bad file descriptor
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от Аноним (-), 15-Июл-09, 00:18
	> $ ls >&- > ls: write error: Bad file descriptor на FreeBSD все пучком - нет ошибки. $ ls >&- $ Linux'у такое поведение с ошибкой можно было б простить, если бы сия функция не была одной из базовых в posix shell'е.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от Аноним (-), 15-Июл-09, 00:23
	>Linux'у такое поведение с ошибкой можно было б простить, если бы сия >функция не была одной из базовых в posix shell'е. кроме того это проблема не bash'а, а GNU ls.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от anonymous_peer (ok), 15-Июл-09, 03:04
	>>Linux'у такое поведение с ошибкой можно было б простить, если бы сия >>функция не была одной из базовых в posix shell'е. > >кроме того это проблема не bash'а, а GNU ls. А почему это проблема ls? Разве не у каждой программы ДОЛЖНЫ быть открыты дескрипторы 0, 1 и 2 при её запуске?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 15-Июл-09, 10:39
	Ну не проблема, а скорее особенность. По крайней мере это именно из-за ls (ну и других прог, потому что не только ls так себя ведёт, а многое гнутое из того, что я проверил). Проблема ли это или не проблема, сложно сказать. По крайней мере, он бы мог тупо забивать и пользователю оставалось бы только догадываться, закрыт дескриптор или нет. Вот как здесь: #include<stdio.h> main() { printf("opennet rulez\n"); fprintf(stderr, "opennet rulez (stderr)\n"); } $ gcc -o /tmp/h h.c $ /tmp/h opennet rulez opennet rulez (stderr) $ /tmp/h >&- opennet rulez (stderr) $ Но он заботится о пользователе и ставит его в курс дела.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от anonymous_peer (ok), 16-Июл-09, 18:49
	Ну, это же хорошо! Лишняя проверка не повредит, а вот её отсутсвие — потенциальный баг в программе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 16-Июл-09, 21:42
	>Ну, это же хорошо! Лишняя проверка не повредит, а вот её отсутсвие >— потенциальный баг в программе. Мне вот интересно, ls и проч. вылетает, когда видит, что STDOUT закрыт, или продолжает работать, просто ошибку выводит? Наверное, вылетает
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от anonymous_peer (ok), 17-Июл-09, 02:21
	>Мне вот интересно, >ls и проч. вылетает, >когда видит, что STDOUT закрыт, >или продолжает работать, >просто ошибку выводит? > >Наверное, вылетает Во-первых, что значит «вылетает»? Завершается раньше времени (но по собственному желанию) или убивается системой (то есть получает сигнал, от которого умирает)? Да и если ls не убивается, то что ему дальше делать-то? В любом случае завершится. У меня (GNU) ls >&- возвращает 2, значит, завершается самостоятельно. И, потом, было бы странно сначала проверить stdout на возможность вывода, сообщить о том, что он закрыт, а дальше, несмотря на это, что-то сделать так, чтобы тебя убили.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от аноним (?), 15-Июл-09, 02:31
	FreeBSD
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	23. "+1 / Если не видно разницы?"	+/–
	Сообщение от Andrey Mitrofanov (?), 15-Июл-09, 12:05
	>Сравните $ /bin/echo 'Ага.' >&- && echo "Таки-ага." \|\| echo 'Не-а!' /bin/echo: ошибка записи: Bad file descriptor Не-а! $ /bin/echo 'Ага.' > /dev/null && echo "Таки-ага." \|\| echo 'Не-а!' Таки-ага. $ _
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	24. "уй-ё... опять _они_"	+/–
	Сообщение от Andrey Mitrofanov (?), 15-Июл-09, 12:28
	И эти люди запрещают мне^W^Wрассказывают о кроссплатформенности, переносимоти, позиксвейности и не-баш-измости... http:/openforum/vsluhforumID3/47017.html#7 И ведь каждый раз одно, блин, и то же: "-Вы в шеле? -Нет, мы в шеле! -А, я думал, вы в шеле..."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "уй-ё... опять _они_"	+/–
	Сообщение от xguru (?), 16-Июл-09, 21:41
	>И эти люди запрещают мне^W^Wрассказывают о кроссплатформенности, переносимоти, позиксвейности и не-баш-измости... http:/openforum/vsluhforumID3/47017.html#7 > > >И ведь каждый раз одно, блин, и то же: "-Вы в шеле? >-Нет, мы в шеле! -А, я думал, вы в шеле..." _ОНИ_ это кто? Я, наверное, пропустил какую-то жестокую тему
	Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Стандартные потоки ввода/вывода в UNIX/Linux"	+1 +/–
Сообщение от anonymous_peer (ok), 14-Июл-09, 19:20
Сначала подумал, что элементарщина, но узнал для себя что-то новое. Спасибо.
Ответить \| Правка \| Наверх \| Cообщить модератору

5. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
Сообщение от аноним (?), 14-Июл-09, 19:48
> почему не работает echo text \| read val и ряд других Один написал бред, другой подхватил. Указанная конструкция замечателно работает: % echo text \| read var; echo $var text вероятно имелось в виду (echo text \| read var); echo $var В общем статья хорошая, но тема скобок совершенно не раскрыта.
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 14-Июл-09, 20:02
	>> почему не работает echo text \| read val и ряд других > >Один написал бред, другой подхватил. Указанная конструкция замечателно работает: > >% echo text \| read var; echo $var >text > У вас какой shell? tcsh? В sh/bash это не работает, проверьте, если не лень >вероятно имелось в виду (echo text \| read var); echo $var > >В общем статья хорошая, но тема скобок совершенно не раскрыта. Тема скобок это да
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 14-Июл-09, 20:08
	>[оверквотинг удален] >>Один написал бред, другой подхватил. Указанная конструкция замечателно работает: >> >>% echo text \| read var; echo $var >>text >> > >У вас какой shell? > >tcsh? > Хотя однако, какой tcsh, там же read нет. Так что таки bash у вас. Покажите как работает, пожалуйста
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от аноним (?), 14-Июл-09, 22:36
	>Хотя однако, какой tcsh, там же read нет. >Так что таки bash у вас. У меня zsh.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 14-Июл-09, 22:43
	В zsh работает, проверил только что. Спасибо за поправку
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от Аноним (-), 15-Июл-09, 00:29
	> Хотя однако, какой tcsh, там же read нет. в tcsh есть $< для чтения значения переменной из стандартного ввода > set foo=$< blah > echo Here is my answer: $foo Here is my answer: blah
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	22. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 15-Июл-09, 10:44
	>> Хотя однако, какой tcsh, там же read нет. > >в tcsh есть $< для чтения значения переменной из стандартного ввода > > > set foo=$< > > blah > > echo Here is my answer: $foo > > Here is my answer: blah Это немножечко не то. Нужно же было прочитать строку из вывода другого процесса. %> echo value \| set foo=$< %> echo $foo %> Не выводит. Как сделать чтобы работало? Вариант с командной подстановкой не предлагать, нужно чтобы читалась одна строка.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от gegMOPO4 (ok), 15-Июл-09, 17:10
	foo=$(echo value\|head -n 1)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	27. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от Аноним (-), 15-Июл-09, 20:10
	> foo=$(echo value\|head -n 1) в случае tcsh скорее > set foo=`echo value`
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Стандартные потоки ввода/вывода в UNIX/Linux"	+/–
	Сообщение от xguru (?), 16-Июл-09, 21:39
	Не, ребята, это всё не то. нужно чтобы read читал только одну строку, а остальное не трогал. Например, как вы с помощью командной подстановки, которую вы рекомендуете, сделаете такое: \|while read line do .... done Как это сделать в tcsh с помощью той конструкции, которую вы выше рекомендовали?
	Ответить \| Правка \| Наверх \| Cообщить модератору