From: Peter Stephenson <pws@csr.com>
To: Zsh hackers list <zsh-workers@sunsite.dk>
Subject: Re: [half-patch][feedback?] exec compatibility
Date: Mon, 30 Apr 2007 10:39:46 +0100 [thread overview]
Message-ID: <20070430103946.7f48b9e0.pws@csr.com> (raw)
In-Reply-To: <20070430052931.GA75651@redoubt.spodhuis.org>
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> - exec [ -c ] [ -a name ] [ arg ... ]
>
> Bash implements this, and the -l option too.
>...
> I've started implementing the compatibility; I've documented all
> three, implemented -l and -a. I'd like feedback before continuing:
>
> (1) is this worth doing at all, or should I stop?
Yes, it's probably a good thing to have. If bash is treating exec in
that fashion there's little gain in sticking strictly to the "precommand
modifiers don't have options" rule.
> (2) to implement -c, is it best to change the interface to execute()?
> Are there any compability issues with modules if I do that? I
> was thinking of changing the second parameter from "dash" to
> "flags" and using the same BINF_ option-space, but with a
> BINF_CLEARENV flag added; just clear the env _after_ checking for
> ARGV0 and it looks valid to me.
Should be fine... I think there's just the one call to execute(),
and in the current set up it could be static. You could change it
to that just to be sure.
> (3) am I going about all this the wrong way?
Ideally munging of options should be done by the builtin handler, with
the options defined by the entry in builtins[] in builtin.c. For normal
builtins that's in execbuiltin(). However, it's not currently
implemented for precommand modifiers. One reason for that is probably
that usually the word following is to be treated like a command even if
it looks like an option. Still, it would be neater to have a general
option parser of some sort in this case. However, it may be overkill
just for this one use.
Send me a Sourceforge user name if you want commit access.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
To access the latest news from CSR copy this link into a web browser: http://www.csr.com/email_sig.php
To get further information regarding CSR, please visit our Investor Relations page at http://ir.csr.com/csr/about/overview
next prev parent reply other threads:[~2007-04-30 9:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-30 5:29 Phil Pennock
2007-04-30 9:39 ` Peter Stephenson [this message]
2007-04-30 21:00 ` Phil Pennock
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=20070430103946.7f48b9e0.pws@csr.com \
--to=pws@csr.com \
--cc=zsh-workers@sunsite.dk \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
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).