🚀 go-pugleaf

Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)

>The standard says (lines 11645--11651)
>
>	When the shell is using standard input and it invokes a
>	command that also uses standard input, the shell shall
>	ensure that the standard input file pointer points
>	directly after the command it has read when the command
>	begins execution.  ...

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

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.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl

Volume-Number: Volume 29, Number 4