[comp.unix.wizards] Why is 'more' giving the 'next file' prompt?

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.)