rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Stefan Dalibor <Stefan.Dalibor@informatik.uni-erlangen.de>
To: rc-owner
Subject: Some questions ref. process substitution
Date: Mon, 11 Apr 1994 13:15:55 -0400	[thread overview]
Message-ID: <199404111715.AA04911@faui30.informatik.uni-erlangen.de> (raw)


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


                 reply	other threads:[~1994-04-11 17:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199404111715.AA04911@faui30.informatik.uni-erlangen.de \
    --to=stefan.dalibor@informatik.uni-erlangen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).