From ilug-admin@linux.ie  Mon Jul 22 19:49:23 2002
Return-Path: <ilug-admin@linux.ie>
Delivered-To: yyyy@localhost.netnoteinc.com
Received: from localhost (localhost [127.0.0.1])
	by phobos.labs.netnoteinc.com (Postfix) with ESMTP id 3726B440C8
	for <jm@localhost>; Mon, 22 Jul 2002 14:49:21 -0400 (EDT)
Received: from dogma.slashnull.org [212.17.35.15]
	by localhost with IMAP (fetchmail-5.9.0)
	for jm@localhost (single-drop); Mon, 22 Jul 2002 19:49:21 +0100 (IST)
Received: from webnote.net (mail.webnote.net [193.120.211.219]) by
    dogma.slashnull.org (8.11.6/8.11.6) with ESMTP id g6MG1DY16485 for
    <jm-ilug@jmason.org>; Mon, 22 Jul 2002 17:01:13 +0100
Received: from lugh.tuatha.org (root@lugh.tuatha.org [194.125.145.45]) by
    webnote.net (8.9.3/8.9.3) with ESMTP id LAA27022 for <jm-ilug@jmason.org>;
    Sun, 21 Jul 2002 11:01:08 +0100
Received: from lugh (root@localhost [127.0.0.1]) by lugh.tuatha.org
    (8.9.3/8.9.3) with ESMTP id LAA03542; Sun, 21 Jul 2002 11:00:17 +0100
Received: from linux.local ([195.218.108.167]) by lugh.tuatha.org
    (8.9.3/8.9.3) with ESMTP id KAA03495 for <ilug@linux.ie>; Sun,
    21 Jul 2002 10:59:40 +0100
X-Authentication-Warning: lugh.tuatha.org: Host [195.218.108.167] claimed
    to be linux.local
Received: from linux.local (localhost [127.0.0.1]) by linux.local
    (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g6L121X21767 for
    <ilug@linux.ie>; Sun, 21 Jul 2002 02:02:01 +0100
Message-Id: <200207210102.g6L121X21767@linux.local>
To: Irish Linux Users Group <ilug@linux.ie>
Reply-To: Irish Linux Users Group <ilug@linux.ie>
Subject: Re: [ILUG] vanquishing the daemons of shell scripting
In-Reply-To: Message from Stephen Shirley <diamond@skynet.ie> of
    "Sat, 20 Jul 2002 10:47:36 BST."
    <20020720094736.GA16224@skynet.ie>
X-Mailer: [nmh-1.0.4] MH.6.8, SuSE Linux 7.3
X-Url: http://www.blf.utvinternet.ie
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Id: <21764.1027213321.1@linux.local>
Date: Sun, 21 Jul 2002 02:02:01 +0100
From: Brian Foster <blf@utvinternet.ie>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lugh.tuatha.org id
    KAA03495
Sender: ilug-admin@linux.ie
Errors-To: ilug-admin@linux.ie
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: Irish Linux Users' Group <ilug.linux.ie>
X-Beenthere: ilug@linux.ie

  | Date: Sat, 20 Jul 2002 10:47:36 +0100
  | From: Stephen Shirley <diamond@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@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...

-- 
Irish Linux Users' Group: ilug@linux.ie
http://www.linux.ie/mailman/listinfo/ilug for (un)subscription information.
List maintainer: listmaster@linux.ie


