exspes@bath.ac.uk (P E Smee) (05/03/90)
Ok, folks, here's one which my boss asked for an answer to the other day, and I don't see the answer. The context is (4 different variants of) 4.3BSD (on 4 different platforms). Make yourself a small text file, say 'fred'. Then try the command line: cat fred | csh -c 'cat >tempxxx ; more tempxxx' Before 'more' puts anything out, it gives the 'Next file (tempxxx):' prompt. Why does it think tempxxx is the second file? What's the first? (This is a test case synthesized from a real -- and useful -- example, found while working with a subsystem which allows you to predefine 'command sets' to pipe stuff through. The first 'cat' is simply imitating this subsystem, i.e. being an stdout producer; so in the real case only the stuff after the '|' is interesting. The purpose of piping through 'cat' into a temp file and then giving that to 'more' as an arg is that in that case 'more' will allow you to move backwards; while if 'more' is processing stdin you can only go frontwards. In the context of the original, the shell invocation is needed in order to allow the (second) 'cat' and the 'more' to be joined with ';' rather than being '|'ed together. Using 'sh' doesn't seem to change things.) -- Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK P.Smee@bristol.ac.uk - ..!uunet!ukc!bsmail!p.smee - Tel +44 272 303132
barmar@think.com (Barry Margolin) (05/04/90)
In article <1990May3.160744.25250@bath.ac.uk> exspes@bath.ac.uk (P E Smee) writes: >Ok, folks, here's one which my boss asked for an answer to the other >day, and I don't see the answer. The context is (4 different variants >of) 4.3BSD (on 4 different platforms). Make yourself a small text >file, say 'fred'. Then try the command line: > > cat fred | csh -c 'cat >tempxxx ; more tempxxx' > >Before 'more' puts anything out, it gives the 'Next file (tempxxx):' >prompt. Why does it think tempxxx is the second file? What's the >first? 'more' is noticing that its standard input isn't a terminal, so it's first displaying the standard input. Here's a way to see this more clearly: create two text files, 'foo' and 'bar', and then do: more foo < bar First it will show you the contents of 'bar', and the second file will be 'foo'. You can fix your problem by making 'more's standard input a terminal, e.g. cat fred | ( cat >tempxxx ; more tempxxx </dev/tty ) > The purpose of >piping through 'cat' into a temp file and then giving that to 'more' as >an arg is that in that case 'more' will allow you to move backwards; >while if 'more' is processing stdin you can only go frontwards. Get 'less'. It allows going backward in any stream. > In the >context of the original, the shell invocation is needed in order to >allow the (second) 'cat' and the 'more' to be joined with ';' rather >than being '|'ed together. You can also use parentheses, as in my example. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
paul@tetrauk.UUCP (Paul Ashton) (05/04/90)
In article <1990May3.160744.25250@bath.ac.uk> exspes@bath.ac.uk (P E Smee) writes: > cat fred | csh -c 'cat >tempxxx ; more tempxxx' > >Before 'more' puts anything out, it gives the 'Next file (tempxxx):' >prompt. Why does it think tempxxx is the second file? What's the >first? > The first file is fred (stdin, which is not a tty so more's in filter mode) cat has read all stdin so more gets nothing and prompts for the next file. So for more not to prompt stdin must me a tty. eg cat fred | csh -c 'cat >tempxxx ; more tempxxx < /dev/tty' pity you haven't got pg -- Paul
richard@aiai.ed.ac.uk (Richard Tobin) (05/04/90)
In article <1990May3.160744.25250@bath.ac.uk> exspes@bath.ac.uk (P E Smee) writes: > cat fred | csh -c 'cat >tempxxx ; more tempxxx' > >Before 'more' puts anything out, it gives the 'Next file (tempxxx):' >prompt. Try these: more /etc/group < /etc/group more /etc/group < /dev/null more /etc/group < /dev/tty It seems that rather than reading its standard input only if no file arguments are given, more read its standard input unless it's a terminal. My Sun manual doesn't document this. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
guy@auspex.auspex.com (Guy Harris) (05/05/90)
>pity you haven't got pg
If he mistakenly referred to his OS as "4.3BSD" when he meant "SunOS"
(they are similar in some ways, but are *not* the same!), he might have
"pg" if his system administrator installed the "System V" optional
software category; look in "/usr/5bin". Similar things may apply to
other OSes that could be confused with 4.3BSD; they may include a bunch
of S5 commands as well.
rick@uunet.UU.NET (Rick Adams) (05/05/90)
> If he mistakenly referred to his OS as "4.3BSD" when he meant "SunOS" > (they are similar in some ways, but are *not* the same!), he might have > "pg" if his system administrator installed the "System V" optional > software category; look in "/usr/5bin". Similar things may apply to > other OSes that could be confused with 4.3BSD; they may include a bunch > of S5 commands as well. Actually, this is also true of OSes that could not possibly be confused with 4.3BSD, such as Dynix which offers pg in /usr/att/usr/bin/pg.
guy@auspex.auspex.com (Guy Harris) (05/06/90)
>Actually, this is also true of OSes that could not possibly be confused with >4.3BSD, such as Dynix which offers pg in /usr/att/usr/bin/pg. Or, slightly more conveniently, as "att pg", right? (Same probably applies to OSx.)