home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 394 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.4 KB
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: davidf@mks.uucp (David J. Fiander)
  3. Newsgroups: comp.std.unix
  4. Subject: Re: Embedded data in shell scripts?
  5. Date: 19 Aug 1992 12:58:14 -0700
  6. Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
  7. Lines: 41
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16u94mINNlc9@ftp.UU.NET>
  11. References: <16h4n3INNk80@ftp.UU.NET> <16rpiqINNon4@ftp.UU.NET>
  12. NNTP-Posting-Host: ftp.uu.net
  13. X-Submissions: std-unix@uunet.uu.net
  14.  
  15. Submitted-by: davidf@mks.uucp (David J. Fiander)
  16.  
  17. According to johnl@iecc.cambridge.ma.us (John R. Levine) (in <16rpiqINNon4@ftp.UU.NET>):
  18. >I don't see how you can have it any other way.  If the shell is reading
  19. >directly or indirectly from a terminal I certainly wouldn't be too pleased
  20. >to have the shell eat arbitrary amounts of text after every command.  And
  21. >I'd be equally unhappy if I saved the input stream into a file and
  22. >couldn't replay it.
  23.  
  24. The problem is that 'cat script | sh' is not going to work,
  25. since the file offset is undefined after the first call to a
  26. standard utility.  So your script will run fine until the first
  27. external command which reads stdin is invoked.
  28.  
  29. >The efficiency argument seems to me to be a red herring.  When you pipe
  30. >large numbers of commands into the shell, if there aren't any loops in the
  31. >command list, the time will most likely be dominated by the time spent
  32. >running the commands.  If there are loops, the looping commands are read
  33. >once and buffered inside the shell anyway.  I agree that the distinctions
  34. >between seekable and non-seekable files are ugly, but it's too late to
  35. >legislate them out of existence.
  36.  
  37. I think that there will be an efficiency hit in the case we are
  38. discussing.  My big complaint is that the text of the standard
  39. looks like somebody was attempting to ensure that their
  40. favorite cute hack would continue to work, but got it a little
  41. bit wrong.  Also, none of the shells to which I have access
  42. right now demonstrate the "standard" behaviour, so what was the
  43. rationale behind this particular bit of text?
  44.  
  45. >Quite a while ago someone (Dennis Ritchie?) suggested that it would have
  46. >been a good idea to provide in Unix a version of read() that would read up
  47. >to but not past a terminator byte, independent of the data source.  That
  48. >would have let programs read a line at a time with reasonable efficiency.
  49.  
  50. Yes, this would be nice.  Too late now, 'though.
  51.  
  52. - David
  53.  
  54.  
  55. Volume-Number: Volume 29, Number 6
  56.