home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 392 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  1.9 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: johnl@iecc.cambridge.ma.us (John R. Levine)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Embedded data in shell scripts?
  5. Date: 18 Aug 1992 14:20:26 -0700
  6. Organization: I.E.C.C.
  7. Lines: 33
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16rpiqINNon4@ftp.UU.NET>
  11. References: <16h4n3INNk80@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
  16.  
  17. >The standard says (lines 11645--11651)
  18. >
  19. >    When the shell is using standard input and it invokes a
  20. >    command that also uses standard input, the shell shall
  21. >    ensure that the standard input file pointer points
  22. >    directly after the command it has read when the command
  23. >    begins execution.  ...
  24.  
  25. I don't see how you can have it any other way.  If the shell is reading
  26. directly or indirectly from a terminal I certainly wouldn't be too pleased
  27. to have the shell eat arbitrary amounts of text after every command.  And
  28. I'd be equally unhappy if I saved the input stream into a file and
  29. couldn't replay it.
  30.  
  31. The efficiency argument seems to me to be a red herring.  When you pipe
  32. large numbers of commands into the shell, if there aren't any loops in the
  33. command list, the time will most likely be dominated by the time spent
  34. running the commands.  If there are loops, the looping commands are read
  35. once and buffered inside the shell anyway.  I agree that the distinctions
  36. between seekable and non-seekable files are ugly, but it's too late to
  37. legislate them out of existence.
  38.  
  39. Quite a while ago someone (Dennis Ritchie?) suggested that it would have
  40. been a good idea to provide in Unix a version of read() that would read up
  41. to but not past a terminator byte, independent of the data source.  That
  42. would have let programs read a line at a time with reasonable efficiency.
  43.  
  44. Regards,
  45. John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
  46.  
  47. Volume-Number: Volume 29, Number 4
  48.