Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: More POSIX developments
- X-seq: zsh-workers 20441
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: More POSIX developments
- Date: Sat, 2 Oct 2004 14:23:54 -0700 (PDT)
- In-reply-to: <200409271104.i8RB4URU009112@xxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <Pine.LNX.4.61.0409241908380.1714@xxxxxxxxxxxxxxxxxx> <200409271104.i8RB4URU009112@xxxxxxxxxxxxxx>
- Reply-to: zsh-workers@xxxxxxxxxx
Finally got a chance to look at this.
On Mon, 27 Sep 2004, Peter Stephenson wrote:
> The following patch, which I won't commit until we've decided which way
> to go, tries to cover the bases by making test work (more) like POSIX
> while leaving [[ ... ]] the way it is. The errors now return status 2
> from evalcond, but for backward compatibility [[ ... ]] turns them into
> shell errors.
I think this would be OK.
> I needed to add an extra warning function to choose between the cases
> where we have a builtin name and where the code is called internally as
> a condition. Does anyone know if there's a reason zwarnnam handles the
> absence of a command name in a strange way?
I paged through a grep of all the calls to zwarnnam(), and there don't
seem to be any that intentionally get passed a NULL first argument, so it
probably is just defensive programming.
> In other words, could I remove zwarnnamopt and make zwarnnam behave like
> that?
I think that'd be safe, but I wouldn't object to a second opinion.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author