home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0002.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.5 KB  |  35 lines
  1. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  2.  
  3. >The standard says (lines 11645--11651)
  4. >
  5. >    When the shell is using standard input and it invokes a
  6. >    command that also uses standard input, the shell shall
  7. >    ensure that the standard input file pointer points
  8. >    directly after the command it has read when the command
  9. >    begins execution.  ...
  10.  
  11. I don't see how you can have it any other way.  If the shell is reading
  12. directly or indirectly from a terminal I certainly wouldn't be too pleased
  13. to have the shell eat arbitrary amounts of text after every command.  And
  14. I'd be equally unhappy if I saved the input stream into a file and
  15. couldn't replay it.
  16.  
  17. The efficiency argument seems to me to be a red herring.  When you pipe
  18. large numbers of commands into the shell, if there aren't any loops in the
  19. command list, the time will most likely be dominated by the time spent
  20. running the commands.  If there are loops, the looping commands are read
  21. once and buffered inside the shell anyway.  I agree that the distinctions
  22. between seekable and non-seekable files are ugly, but it's too late to
  23. legislate them out of existence.
  24.  
  25. Quite a while ago someone (Dennis Ritchie?) suggested that it would have
  26. been a good idea to provide in Unix a version of read() that would read up
  27. to but not past a terminator byte, independent of the data source.  That
  28. would have let programs read a line at a time with reasonable efficiency.
  29.  
  30. Regards,
  31. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  32.  
  33. Volume-Number: Volume 29, Number 4
  34.  
  35.