zsh-workers
 help / color / mirror / code / Atom feed
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


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