home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0005.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.9 KB  |  43 lines
  1. Submitted-by: davidf@mks.uucp (David J. Fiander)
  2.  
  3. According to johnl@iecc.cambridge.ma.us (John R. Levine) (in <16rpiqINNon4@ftp.UU.NET>):
  4. >I don't see how you can have it any other way.  If the shell is reading
  5. >directly or indirectly from a terminal I certainly wouldn't be too pleased
  6. >to have the shell eat arbitrary amounts of text after every command.  And
  7. >I'd be equally unhappy if I saved the input stream into a file and
  8. >couldn't replay it.
  9.  
  10. The problem is that 'cat script | sh' is not going to work,
  11. since the file offset is undefined after the first call to a
  12. standard utility.  So your script will run fine until the first
  13. external command which reads stdin is invoked.
  14.  
  15. >The efficiency argument seems to me to be a red herring.  When you pipe
  16. >large numbers of commands into the shell, if there aren't any loops in the
  17. >command list, the time will most likely be dominated by the time spent
  18. >running the commands.  If there are loops, the looping commands are read
  19. >once and buffered inside the shell anyway.  I agree that the distinctions
  20. >between seekable and non-seekable files are ugly, but it's too late to
  21. >legislate them out of existence.
  22.  
  23. I think that there will be an efficiency hit in the case we are
  24. discussing.  My big complaint is that the text of the standard
  25. looks like somebody was attempting to ensure that their
  26. favorite cute hack would continue to work, but got it a little
  27. bit wrong.  Also, none of the shells to which I have access
  28. right now demonstrate the "standard" behaviour, so what was the
  29. rationale behind this particular bit of text?
  30.  
  31. >Quite a while ago someone (Dennis Ritchie?) suggested that it would have
  32. >been a good idea to provide in Unix a version of read() that would read up
  33. >to but not past a terminator byte, independent of the data source.  That
  34. >would have let programs read a line at a time with reasonable efficiency.
  35.  
  36. Yes, this would be nice.  Too late now, 'though.
  37.  
  38. - David
  39.  
  40.  
  41. Volume-Number: Volume 29, Number 6
  42.  
  43.