🚀 go-pugleaf

Submitted-by: davidf@mks.uucp (David J. Fiander)

According to johnl@iecc.cambridge.ma.us (John R. Levine) (in <16rpiqINNon4@ftp.UU.NET>):
>I don't see how you can have it any other way.  If the shell is reading
>directly or indirectly from a terminal I certainly wouldn't be too pleased
>to have the shell eat arbitrary amounts of text after every command.  And
>I'd be equally unhappy if I saved the input stream into a file and
>couldn't replay it.

The problem is that 'cat script | sh' is not going to work,
since the file offset is undefined after the first call to a
standard utility.  So your script will run fine until the first
external command which reads stdin is invoked.

>The efficiency argument seems to me to be a red herring.  When you pipe
>large numbers of commands into the shell, if there aren't any loops in the
>command list, the time will most likely be dominated by the time spent
>running the commands.  If there are loops, the looping commands are read
>once and buffered inside the shell anyway.  I agree that the distinctions
>between seekable and non-seekable files are ugly, but it's too late to
>legislate them out of existence.

I think that there will be an efficiency hit in the case we are
discussing.  My big complaint is that the text of the standard
looks like somebody was attempting to ensure that their
favorite cute hack would continue to work, but got it a little
bit wrong.  Also, none of the shells to which I have access
right now demonstrate the "standard" behaviour, so what was the
rationale behind this particular bit of text?

>Quite a while ago someone (Dennis Ritchie?) suggested that it would have
>been a good idea to provide in Unix a version of read() that would read up
>to but not past a terminator byte, independent of the data source.  That
>would have let programs read a line at a time with reasonable efficiency.

Yes, this would be nice.  Too late now, 'though.

- David


Volume-Number: Volume 29, Number 6