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).