home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0008.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.6 KB

  1. From:  Maarten Litmaath <maart@cs.vu.nl>
  2.  
  3. In article <1990May21.160437.21491@usenet.ins.cwru.edu> in the newsgroup
  4. comp.unix.questions, chet@cwns1.CWRU.EDU (Chet Ramey) writes:
  5. )...
  6. )I quote (without comment) from P1003.2, draft 9, section 3.12.0.1:
  7. )
  8. )"It was decided to allow this extension [running the last process in a
  9. ) pipeline in the current environment], but not require it; therefore, a
  10. ) shell programmer should consider a pipeline to be in a subshell environment,
  11. ) but not depend on it."
  12. )
  13. )and from section 3.12:
  14. )
  15. )"Additionally, each command of a multi-column pipeline is in a subshell
  16. ) environment; as an extension, however, any or all commands in a pipeline
  17. ) may be executed in the current environment."
  18. )
  19. )
  20. )It seems they have already considered this proposal (I imagine David Korn
  21. )brought it up).
  22.  
  23. They've considered it indeed, but I don't like the outcome: ambiguity!
  24. If I write a shell script I want to know *exactly* what'll happen on
  25. another POSIX system: that's the whole purpose of P1003.2!
  26. Let's see:
  27.  
  28.     "[...] a shell programmer should consider a pipeline to be in
  29.     a subshell environment, but not depend on it."
  30.  
  31. What does this buy me?  Nothing!  What would you think of the following?
  32.  
  33.     "A shell programmer should consider a string beginning with a
  34.     dollar sign to be a shell variable, but not depend on it."
  35.  
  36. Ridiculous, right?  Right.
  37. My proposal:
  38.  
  39.     If the last command of a pipeline is a (`special') builtin
  40.     command, it must be run in the current environment, else in
  41.     a private environment, just like the other components of the
  42.     pipeline.
  43.  
  44. In fact I would even accept *every* component that's a (`special')
  45. builtin command, to run in the current environment, so the following
  46. would work:
  47.  
  48.     command_1 |
  49.     while read line
  50.     do
  51.         something
  52.         echo "$line"
  53.         last=$line
  54.     done |
  55.     command_2
  56.  
  57.     echo "The last line was: $last"
  58.  
  59. ...but I realize this could be difficult to implement.  On the other hand
  60. the *last* command in a pipeline is a straightforward case.  At that the
  61. next (well-known) example isn't that obscure at all:
  62.  
  63.     some_command | read answer
  64.  
  65. In current implementations this won't work as intended.  The workarounds
  66. are ugly, as workarounds often are.  (Boy, do I hate temp files.)
  67.  
  68. OK, but what if the user *wants* a subshell?!  Easy, he would use
  69. parentheses, just like always:
  70.  
  71.     foo=$orig
  72.     another_command | (
  73.         while read foo
  74.         do
  75.             bar
  76.         done
  77.     )
  78.     echo "foo is $foo and should still be $orig"
  79. --
  80.  Antique fairy tale: Little Red Riding Hood. |Maarten Litmaath @ VU Amsterdam:
  81.  Modern fairy tale: Oswald shot Kennedy. |maart@cs.vu.nl, uunet!cs.vu.nl!maart
  82.  
  83. Volume-Number: Volume 20, Number 9
  84.  
  85.