Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!ames!hc!beta!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: /dev/stdin for 4.3? Message-ID: <7619@brl-adm.ARPA> Date: Mon, 1-Jun-87 09:14:58 EDT Article-I.D.: brl-adm.7619 Posted: Mon Jun 1 09:14:58 1987 Date-Received: Wed, 3-Jun-87 00:52:50 EDT Sender: news@brl-adm.ARPA Lines: 50 From: Doug Gwyn In article <684@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: -I see a potential problem here. Programs that won't let you read from -standard input will frequently attempt to do seeks within the input -file. So to anybody planning to implement /dev/stdin, I suggest adding -a buffering facility that allows seeks to within the buffered area. -Make the buffer size configurable at boot time if possible or better -still, let it be configurable for individual users when they log in. -(Can UNIX devices use non-kernel buffers dynamically? I have no idea.) - -In fact, pipes ought really to be extended to do dynamic buffering. I have to strongly disagree with this. If you can't make a data object that is inherently sequential act completely as a random-access object (as you in fact can't in general), then there is no point in implementing half-measures that add complexity and have dubious utility. I have to be strongly ambivalent here. While I with Doug that half-baked implementations that add little value are to be avoided, conceptually the sequence "a | b" is equivalent to "a > file ; b < file", and I have always thought that you should be able to seek relatively forward on pipes or sequential devices as well. Of course, in the first case, you can always use the temporary file if you need to. In the second, separate code would have to be written. However, I feel that Rahul has raised a valid point: a program might have problems with the difference between "... | prog" versus "prog /dev/stdin" or between "... | prog file1 - file2" versus "... | prog file1 /dev/stdin file2". In the former cases, prog knows to it is reading its stdin simply by its argv geometry. In the latter, it must either pattern match the name "/dev/std{in,out,err}" or "/dev/fd[0-9]*" (think regex, not glob), possibly without the "/dev/" if /dev is the current directory, which is all more complex than "-"; or stat the file, which is probably the best thing to do in the first place. But that adds another level of complexity to programs who care whether a given file is seekable or not. Of course *any* given filename could be unseekable, so we're no worse off than when we started. It is conceivable that the difference might matter to some convolutedly plumbed program (for example, doesn't csh save its std{in,out,err} in fd's 17,18, & 19?), but I can't think of anything obvious. Like Doug said, why do you think they call them sequential? (Root Boy) Jim Cottrell National Bureau of Standards Flamer's Hotline: (301) 975-5688 Yow! Did something bad happen or am I in a drive-in movie??