[ILUG] vanquishing the daemons of shell scripting

[Brian Foster]

  | Date: Sat, 20 Jul 2002 10:47:36 +0100
  | From: Stephen Shirley <diamond at skynet.ie>
  |[ ... ]
  | It's very easy to get one program to act on the output of a second
  | program: cmd1 | cmd2. But, what if you want cmd1 to act on the output
  | of cmd2 as well? Hmm. Eventually, I came up with this solution:
  | 
  |    mkfifo io
  |    cmd1 <io | cmd2 > io
  | 
  | and bingo, all was well with the world. Now, I have (and had) a sneaking
  | suspcion that it might be possible to do this without using a fifo, and
  | can be done using something like:
  | 
 1|    exec 3>&1
 2|    cmd1 <&3 | cmd2 >&3
 3|    exec 3>&-
  | 
  | but that doesn't work in that form, and i couldn't work out an
  | incantation that would. Anyone got any suggestions?  [ ... ]

 the above, or something close to it, would work if, when the
 1st line is executed, file descriptor (fdesc) 1 is open for both
 read and write (R/W) to a suitable entity (e.g., a pipe/FIFO; I
 imagine a socket or something of that ilk could be made to work
 but have no idea why you'd want to go to the trouble.... ).

 but in any case, all that is unlikely to be the case:
  · most probably, fdesc 1 is yer tty (e.g. screen + keyboard);
 and
  · quite possibly is open only for write (being stdout).

 you need it open for R/W because all dup2(2) --- which is all
 `n>&m' means -- does is replicate the fdesc handle.  it does not
 change the access mode; e.g., if the original fdesc (m) was only
 open for writing (W), that's all the new fdesc (n) is open for.
 yet in the 2nd line, it's needed for both R (cmd1) and W (cmd2).

 whilst it's impossible to say for certain from this excerpt, it
 seems a reasonable guess that fdesc 1 when the 1st line executes
 is the stdout of the script itself, which is most probably yer
 tty.  that means, if it does happen to be open for R/W (which is
 the case on some systems), `cmd2' would be writing to the screen
 whilst `cmd1' is reading from the keyboard --- i.e., the poor
 confused human luser is "clearly" expected to manually echo back
 to the computer what it prints.

 good luck!  ;-)

 upshot:  the FIFO is needed.  and this isn't a shell scripting
          problem per se.

 the FIFO solution is fine.  I've used variations (plural) on
 this approach to extend the Korn (ksh(1)) shell language, by
 providing a co-processing interpreter --- `ksh' sends certain
 predefined commands to the co-process, handling control over
 to the co-process until it indicates processing is complete
 and `ksh' can resume normal processing.  with some thought and
 care to insure signals do something rational, works great for
 adding a scripting language (which is the purpose) cheaply to
 script-less programs (useful when you can't modify the, IMHO,
 buggy program to use, e.g., TCL).

cheers!
	-blf-
--
 Innovative, very experienced, Unix and      | Brian Foster    Dublin, Ireland
 Chorus (embedded RTOS) kernel internals     | e-mail: blf at utvinternet.ie
 expert looking for a new position ...       | mobile: (+353 or 0)86 854 9268
  For a résumé, contact me, or see my website  http://www.blf.utvinternet.ie

    Stop E$$o (ExxonMobile):  «Whatever you do, don't buy Esso --- they
     don't give a damn about global warming.»    http://www.stopesso.com
     Supported by Greenpeace, Friends of the Earth, and numerous others...