NOMATCH errors

NOMATCH errors

[Anthony Heading]

Hi,

I was dusting off an old script which, admittedly inelegantly, did
  PYTHON==python 2>/dev/null
with NOMATCH set, which in the zsh 5 era seems to be a fatal error, i.e.
a script

echo hello
echo =hello =hello
echo "is there anybody in there?"

doesn't get past:
hello
hello:2: hello not found

Interestingly the docs perhaps arguably seem to imply differently:
   Fatal errors found in non-interactive shells include:
   [...]
   o    File generation failures where not caused by NO_MATCH or similar
   options


So I was wondering the cleanest way to do this.  `which python` is the
old-school
way, I guess, but the documentation isn't very reassuring about output
format
in case it happens to be an alias or a function or (heaven forfend)
python becomes
a shell builtin. 

I played for a few minutes with a trivial patch at the end of this
email, which
aimed to make ==missing expand to an empty string.   That to me seems a
helpful
behaviour,  enables e.g. ${${:-==python}:-perl},  although it feels very
special
case syntax, maybe something as a variant or modifier on the :c
expansion would be
neater.  But then if the idea is valid, maybe it sense to be able to
soft test tilde dir
expansion too;  I'm not aware a nice way to look up single entries in
the hash tables, so maybe a general syntax for that could be better.

Any thoughts appreciated,  especially if I'm missing a neat way to do
this.

Thanks

Anthony


--- a/Src/subst.c
+++ b/Src/subst.c
@@ -623,13 +623,18 @@ char *
 equalsubstr(char *str, int assign, int nomatch)
 {
     char *pp, *cnam, *cmdstr, *ret;
+    int nullmatch = str[0] == Equals;
 
     for (pp = str; !isend2(*pp); pp++)
        ;
     cmdstr = dupstrpfx(str, pp-str);
     untokenize(cmdstr);
     remnulargs(cmdstr);
+    if (nullmatch)
+       cmdstr++;
     if (!(cnam = findcmd(cmdstr, 1, 0))) {
+       if (nullmatch)
+           return dupstring("");
        if (nomatch)
            zerr("%s not found", cmdstr);
        return NULL;

Re: NOMATCH errors

[Peter Stephenson]

On Thu, 05 Jan 2017 22:35:21 -0500
Anthony Heading <anthony@ajrh.net> wrote:
> I was dusting off an old script which, admittedly inelegantly, did
>   PYTHON==python 2>/dev/null
> with NOMATCH set, which in the zsh 5 era seems to be a fatal error, i.e.
> a script

Well, it's an error if python isn't actually found, in which case you're
setting PYTHON to =python.  That's the sort of thing NOMATCH is designed
to trap.  So it's not clear to me, given you're being careful about
failed matches, why you'd want to allow it to set a duff value in this
case.

You have more clumsy options like

() {
  setopt localoptions nonnomatch
  PYTHON==python
}

The multiple "=" syntax is certainly a possibility, although I'm not
100% convinced nobody's using commands that begin with an "=", which
isn't actually forbidden.  Could alternatively be =~, since ~ needs
quoting anyway if you want to use it literally, so I think it's less
likely to break anything.

pws

Re: NOMATCH errors

[Eric Cook]

On 01/05/2017 10:35 PM, Anthony Heading wrote:
> Hi,
> 
> I was dusting off an old script which, admittedly inelegantly, did
>   PYTHON==python 2>/dev/null
> with NOMATCH set, which in the zsh 5 era seems to be a fatal error, i.e.
> a script

> 
> So I was wondering the cleanest way to do this.  `which python` is the
> old-school
> way, I guess, but the documentation isn't very reassuring about output
> format

> Any thoughts appreciated,  especially if I'm missing a neat way to do
> this.
> 
> Thanks
> 
> Anthony

zsh already hashes commands at startup, you can access that entry
with $commands[python]. Since what =python would resolve
to already hashed, just calling python is fine.

Unless the script installs python or an additional `python',
in the former case zsh will notice python isn't in the command hash
table, add it and run the command, all during the first time the script
calls python. In the latter case, if the additional
`python' binary is early in PATH and you want to use it, running
''rehash python'' would hash it.

If the point of PYTHON==python was just to use $PYTHON in place of
just python under the guise of "always use the absolute paths to
commands to prevent future PATH lookups" advise some people spout, it's
pretty superfluous since zsh already hashed the command and won't do
another PATH lookup unless you use rehash (hash -r) or =python.

Re: NOMATCH errors

[Anthony Heading]

On Fri, Jan 06, 2017 at 11:05:47AM -0500, Eric Cook wrote:
> zsh already hashes commands at startup, you can access that entry
> with $commands[python]. Since what =python would resolve
> to already hashed, just calling python is fine.

Ah, spectacular.  I searched zshparam manual wondering how I'd
missed that,  I forgot totally about zsh modules.  Think this is
perfect.   Many thanks.

Re: NOMATCH errors

[Bart Schaefer]

On Jan 5, 10:35pm, Anthony Heading wrote:
}
} echo hello
} echo =hello =hello
} echo "is there anybody in there?"
} 
} doesn't get past:
} hello
} hello:2: hello not found
} 
} Interestingly the docs perhaps arguably seem to imply differently:
}    Fatal errors found in non-interactive shells include:
}    [...]
}    o    File generation failures where not caused by NO_MATCH or similar
}    options

This particular bit of doc is out of date.  Which is to say, either the
doc should have been changed or a bug was introduced.

This appears to date from workers/30789 which introduced the option
CONTINUE_ON_ERROR.  This changed default startup-script behavior from
blowing right past all sorts of syntax problems, to aborting on those
errors.  Setting the option restores the old behavior.

Unfortunately NO_MATCH errors got swept into the bucket along with all
the other startup-time errors, so there's now no way other than using
an "eval" wrapper or an "always" block to safely skip NO_MATCH errors
without also skipping more serious errors like broken loop control
syntax.

So ... either we need to undo that side-effect of CONTINUE_ON_ERROR or
we need to update the documentation quoted above.