home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / std / unix / 378 < prev    next >
Encoding:
Text File  |  1992-08-13  |  3.0 KB  |  99 lines
  1. Path: sparky!uunet!uunet!not-for-mail
  2. From: davidf@mks.com ("David J. Fiander")
  3. Newsgroups: comp.std.unix
  4. Subject: Embedded data in shell scripts?
  5. Date: 14 Aug 1992 13:22:59 -0700
  6. Organization: Mortice Kern Systems Inc., Waterloo, Ontario, CANADA
  7. Lines: 85
  8. Sender: sef@ftp.UU.NET
  9. Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
  10. Message-ID: <16h4n3INNk80@ftp.UU.NET>
  11. NNTP-Posting-Host: ftp.uu.net
  12. X-Submissions: std-unix@uunet.uu.net
  13.  
  14. Submitted-by: davidf@mks.com ("David J. Fiander")
  15.  
  16. All references are to POSIX 1003.2 D11.2, unless stated
  17. otherwise.
  18.  
  19. The standard says (lines 11645--11651)
  20.  
  21.     When the shell is using standard input and it invokes a
  22.     command that also uses standard input, the shell shall
  23.     ensure that the standard input file pointer points
  24.     directly after the command it has read when the command
  25.     begins execution.  It shall not read ahead in such a
  26.     manner that any characters intended to be read by the
  27.     invoked command are consumed by the shell (whether
  28.     interpreted by the shell or not) or that characters
  29.     that are not read by the invoked command are not seen
  30.     by the shell.
  31.  
  32.  
  33. This seems to be attempting to ensure that a script like this
  34.  
  35.     foo=`sed 1q`
  36.     hi there
  37.     echo $foo
  38.     echo Done
  39.  
  40. When fed to the shell on standard input will generate the output
  41.  
  42.     hi there
  43.     Done
  44.  
  45. But the standard also says that (lines 5467--5471)
  46.  
  47.     When a standard utility reads a seekable input file and
  48.     terminates without an error before it reaches
  49.     end-of-file, the utility shall ensure that the file
  50.     offset in the open file description is properly
  51.     positioned just past the last byte processed by the
  52.     utility.  For files that are not seekable, the state of
  53.     the file offset in the open file description for that
  54.     file is unspecified.
  55.  
  56. This means that the above script is _only_ guaranteed to work
  57. in the case of
  58.  
  59.     sh <script
  60.  
  61. since sed is required to ensure that the file offset of the
  62. seekable file script is properly positioned when it exits.
  63.  
  64.     cat script | sh
  65.  
  66. does _not_ have to work, according to the standard.  Yes, the
  67. standard ensures that sed will read the right data, but the
  68. shell may miss a large chunk out of the middle of the script
  69. because sed is permitted to perform a buffered read, and not
  70. reset the file offset pointer.
  71.  
  72. In fact, the only case in which both 'sh < script' and
  73. 'cat script | sh' will give the same answer on all systems is
  74. that case in which the embedded data is all at the end of the
  75. file, and that _all_ of that data will be consumed by the last
  76. command executed by the shell.  That is:
  77.  
  78.     .
  79.     .
  80.     .
  81.     filter -args
  82.     data
  83.     data
  84.  
  85. Where filter will use all of the data.
  86.  
  87. What is most unfortunate is that in order to support this one
  88. case, there will have to be a lot of code in the shell which,
  89. when the script is be read from standard input and standard
  90. input is not a seekable file, reads the script unbuffered, a
  91. single byte at a time, in order to ensure that the last command
  92. in the file get the data it is expecting.
  93.  
  94. Is it really worth it?
  95.  
  96.  
  97.  
  98. Volume-Number: Volume 28, Number 93
  99.