From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from localhost by hawkwind.utcs.toronto.edu with SMTP id <24211>; Mon, 11 Apr 1994 13:39:31 -0400
Return-Path: immd3.informatik.uni-erlangen.de!dalibor
Received: from faui45.informatik.uni-erlangen.de ([131.188.2.45]) by hawkwind.utcs.toronto.edu with SMTP id <24211>; Mon, 11 Apr 1994 13:17:02 -0400
Received: from faui30.informatik.uni-erlangen.de by uni-erlangen.de with SMTP;
	id AA18714 (5.65c-6/7.3v-FAU); Mon, 11 Apr 1994 19:15:55 +0200
Received: from faui30c.informatik.uni-erlangen.de by immd3.informatik.uni-erlangen.de with SMTP;
	id AA04911 (5.65c-5/7.3v-FAU); Mon, 11 Apr 1994 19:15:53 +0200
From:	Stefan Dalibor <Stefan.Dalibor@informatik.uni-erlangen.de>
Message-Id: <199404111715.AA04911@faui30.informatik.uni-erlangen.de>
Date:	Mon, 11 Apr 1994 13:15:55 -0400
To:	rc-owner
Subject: Some questions ref. process substitution
Reply-To: Stefan.Dalibor@informatik.uni-erlangen.de
Resent-To: rc
Resent-Date: Mon, 11 Apr 1994 13:39:29 -0400
Resent-From: Chris Siebenmann <cks>
Resent-Message-Id: <94Apr11.133931edt.24211@hawkwind.utcs.toronto.edu>


Hi,

lately I played around a bit with rc's process substitution facility
(which I think is a very nice feature - thanks, Byron!); this unvealed
one buglette and a few questions when executing:

; exec echo<{echo XXX}

1. Purify says that the memory allocated for the eFd/eFifo exception
   stack entry in mkcmdarg() is leaking. I patched this by freeing the
   memory in except.c, but it makes the code IMHO look a bit fuzzy.
   Is there any objection against allocating the stack entry in
   mkcmdarg() with nnew() instead of enew() ? 

2. The exec is simply ignored - as far as I understand, this is
   necessary if process substitution is implemented with FIFOS to get
   rid of the FIFO file in TMPDIR, but couldn't rc just execve the
   command for those lucky enough to have /dev/fd?
   BTW, just in case I'm not the last one to notice: The /dev/fd patch
   available from emx.cc.utexas.edu mentioned in the FAQ works fine
   with 4.1.3(_U1, too) and also with minimal changes for the sun4m archi-
   tecture.
   Another question is wether the parent rc should exit after deleting
   the FIFO files to maintain manual-compatibility as far as possible
   (`Replaces rc with the given command.')...

3. I have sigexit set up to do some cleanup; to get this done if the
   exec builtin is called, I redefined exec to explicitly call
   sigexit - but this provokes an error message `sigexit not found'
   with the command above because the function's definition is deleted
   in setsigdefaults(). Is it really necessary to delete the signal
   handling functions - wouldn't it be enough to deinstall them as
   handlers so they could be called just as ordinary, but unexportable
   functions)? 

Bye,
Stefan