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

Стандартные потоки ввода/вывода в UNIX/Linux, opennews (??), 14-Июл-09, (0) [смотреть все] То, что доктор прописал, хорошая статья, Аноним (-), 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) 1,2,3,5,25,33

Сообщения

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

	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ообщить модератору

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

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