newcomb@cory.Berkeley.EDU (Tom Newcomb) (06/26/88)
After reading all the flap about /dev/stdin (and its omission from BSD UNIX), I thought a while about the problem. First, is /dev/stdin supposed to be just a link of sorts to one's TTY input? I can't think of anything else it should reference, except perhaps fd0 in a shell script (and here, admittedly, my case is worthless). If you want to do something like: egrep 'Lo\! The Hounds of Hell eat Puppy Chow\!' `cat files /dev/stdin`' then would not /dev/stdin be referring to TTY input? I should think that it would always be used on command lines where stdin is not being redirected; I don't know of too many programs that let you get away with something like this: cat /dev/stdin < whangdoodle ; Send stdin and 'whangdoodle' to stdout (Would /dev/stdin in this case be referring to 'whangdoodle', since it's now standard input...?) So, if all you want is the TTY input, why not use /dev/tty? It's worked beautifully in all the cases I've tried. So, what am I missing? Can anybody come up with a case where /dev/stdin would NOT be /dev/tty, besides shell scripts? (I already know this won't work for scripts run from a shell whose input has been redirected.) In a C program, also, you can just do an fdopen(3) on descriptor 0 (and that ALWAYS works). PLEASE send comments through E-MAIL!!!! I promise I'll summarize in a week or so. Many thanks. Tom Newcomb | WEST, v. West is what wabbits do when they newcomb@cory.Berkeley.EDU | get tired of wunning awound.
denbeste@bgsuvax.UUCP (William C. DenBesten) (06/27/88)
From article <4096@pasteur.Berkeley.Edu>, by newcomb@cory.Berkeley.EDU (Tom Newcomb): > So, if all you want is the TTY input, why not use /dev/tty? It's worked > beautifully in all the cases I've tried. So, what am I missing? Can anybody > come up with a case where /dev/stdin would NOT be /dev/tty, besides shell > scripts? sure. ls -1 | sort -r - The dash at the end indicates to sort that it should do a fdopen(0). The problem is that this causes ugly special case code within sort. If I instead said: ls -1 | sort -r /dev/stdin the OS would deal with the fact that I want stdin. This would clean up code, since the file opening code can be located in just one place. In addition, you could then pipe input into programs that were not designed to use standard input. -- William C. DenBesten denbeste@bgsu.edu
rbj@cmr.icst.nbs.gov (Root Boy Jim) (06/28/88)
? From: Tom Newcomb <newcomb@cory.berkeley.edu> ? So, if all you want is the TTY input, why not use /dev/tty? It's worked ? beautifully in all the cases I've tried. So, what am I missing? Can anybody ? come up with a case where /dev/stdin would NOT be /dev/tty, besides shell ? scripts? (I already know this won't work for scripts run from a shell whose ? input has been redirected.) In a C program, also, you can just do an ? fdopen(3) on descriptor 0 (and that ALWAYS works). The point is that stdin is not always /dev/tty. And not all commands support the (considered by some) ugly kluge of `-' == stdin. One guy wanted to print a file, even lines in the first column, odd lines in the second column; he tried "cat file | pr -2 - -". Unfortunately, pr does not support `-' as a synonym for stdin. Replacing `-' by `/dev/stdin' should produce the desired results. Another (mis?)use is to compile programs from stdin. First, we do `ln -s /dev/stdin x.c', then `cc -c x.c'. I'm sure one can find really useful uses for stdin being a real file, but personally, I have never felt enough need to install it. I'm sure the authors have better arguments. ? Tom Newcomb | WEST, v. West is what wabbits do when they ? newcomb@cory.Berkeley.EDU | get tired of wunning awound. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
allbery@ncoast.UUCP (Brandon S. Allbery) (07/06/88)
As quoted from <16305@brl-adm.ARPA> by rbj@cmr.icst.nbs.gov (Root Boy Jim): +--------------- | Another (mis?)use is to compile programs from stdin. First, we do | `ln -s /dev/stdin x.c', then `cc -c x.c'. I'm sure one can find really +--------------- Would this work? I was under the impression that the C compiler made multiple passes over the source -- not useful if you build a pipe with ln -s /dev/stdin x.c; (CProgramGenerator | cc -c x.c); rm x.c ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
chris@mimsy.UUCP (Chris Torek) (07/06/88)
>In article <16305@brl-adm.ARPA> rbj@cmr.icst.nbs.gov (Root Boy Jim) suggests: >>Another (mis?)use is to compile programs from stdin. First, we do >>`ln -s /dev/stdin x.c', then `cc -c x.c'. ... In article <8220@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >Would this work? I was under the impression that the C compiler made >multiple passes over the source .... Some do; but the first will be /lib/cpp, with output sent to a temp file, in this case. I suppose someone might run the preprocessor twice. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
rbj@nav.icst.nbs.gov (Root Boy Jim) (07/13/88)
From: "Brandon S. Allbery" <allbery@ncoast.uucp> Date: 5 Jul 88 17:47:29 GMT Followup-To: comp.unix.wizards As quoted from <16305@brl-adm.ARPA> by rbj@cmr.icst.nbs.gov (Root Boy Jim): +--------------- | Another (mis?)use is to compile programs from stdin. First, we do | `ln -s /dev/stdin x.c', then `cc -c x.c'. I'm sure one can find really +--------------- Would this work? I was under the impression that the C compiler made multiple passes over the source -- not useful if you build a pipe with Multiple passes? rm /bin/cc /lib/cpp x.c | /lib/ccom | /lib/c2 | /bin/as -o x.o Multiple passes, yes, but not over the original source. ln -s /dev/stdin x.c; (CProgramGenerator | cc -c x.c); rm x.c ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
allbery@ncoast.UUCP (Brandon S. Allbery) (07/14/88)
As quoted from <12327@mimsy.UUCP> by chris@mimsy.UUCP (Chris Torek): +--------------- | >In article <16305@brl-adm.ARPA> rbj@cmr.icst.nbs.gov (Root Boy Jim) suggests: | >>Another (mis?)use is to compile programs from stdin. First, we do | >>`ln -s /dev/stdin x.c', then `cc -c x.c'. ... | | In article <8220@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: | >Would this work? I was under the impression that the C compiler made | >multiple passes over the source .... | | Some do; but the first will be /lib/cpp, with output sent to a temp | file, in this case. I suppose someone might run the preprocessor | twice. . . . +--------------- May I remind everyone that nowhere does it state that Unix cc *must* have a separate /lib/cpp? Xenix System V/386 has /lib/cpp, but Microsoft cc *does* *not* *use* *it* -- for proof, try your favorite Reiserisms under Xenix. Or *any* #define'd macro which depends on /lib/cpp outputting text instead of tokens. (Microsoft may have plans to change this, or may have already done so in recent versions of SCO Xenix. But the point still remains that there's no law requiring /lib/cpp to be separate from the actual compiler.) -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
chris@mimsy.UUCP (Chris Torek) (07/14/88)
>In artcile <12327@mimsy.UUCP> I wrote (re multiple compiler passes) >>... the first will be /lib/cpp, without output sent to a temp file ... In article <8241@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >May I remind everyone that nowhere does it state that Unix cc *must* have a >separate /lib/cpp? Okay: `the first will be the preprocessor, with output sent to a temp file'. Happy? ( :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
haugj@pigs.UUCP (Joe Bob Willie) (07/19/88)
In article <12472@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |>In artcile <12327@mimsy.UUCP> Chris also wrote (re multiple compiler passes) |>>... the first will be /lib/cpp, without output sent to a temp file ... | |In article <8241@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: |>May I remind everyone that nowhere does it state that Unix cc *must* have a |>separate /lib/cpp? | |Okay: `the first will be the preprocessor, with output sent to a temp file'. | |Happy? | |( :-) ) nope, still not happy. the compiler doesn't even have to have a separate pass which includes a preprocessor. assuming the compiler itself can parse the C source in one pass, the ``output'' of the preprocessor need never be saved to a file. as an example, the input function could return characters from a preprocessorified buffer for such things as macro expansions, or straight from the file, which might be either the normal input (c.c), or from an include file. any compiler which makes more than one pass over the source code should be shot out of a cannon, so cc -c /dev/stdin.c should still work. for all reasonable values of cc. ;-) - john. -- John "Evil USENET User" F. Haugh II HECI Exploration Co, Inc., Dallas UUCP: ...!killer!rpp386!jfh jfh@rpp386.UUCP :DOMAIN **** Trivia question of the day: VYARZERZIMANIMORORSEZASSEZANSERAREORSES? **** "You are in a twisty little maze of UUCP connections, all alike" -- fortune