Re: no match should be no string ?

[Marc Chantreux <mc@xxxxxxxxxx>]

hello,

> Hi, yes, this is expected, this is standard POSIX sh behaviour and
> implemented by all POSIX sh-compatible shells. It should even be what zsh
> does when running in POSIX mode, but I do not have it installed right now to
> check.

You're right!

emulate sh
set *no_way_this_glob_matches*
echo $@

outputs *no_way_this_glob_matches*

> In bash, it is optional, you get the glob itself by default, but there is a
> "nullglob" shell option you can set to get what you are asking for.

emulate zsh
set *no_way_this_glob_matches*
echo $@
ERR: zsh: no matches found: *no_way_this_glob_matches*

emulate zsh
set -- *no_way_this_glob_matches*(N)
echo $#
OUT: 0

> In ksh, it is optional, you get the glob itself by default, but there is a
> special thing where you can start a glob with ~(N) to change only that glob
> only to expand to nothing if there is no match.

ok so (N) is a ksh inspired! thanks for the fish.

> I personally suspect dash will not want to implement either extension until
> POSIX decides which extension, if either/any, to standardise at some point.

which is understandable but not usable because of

* the ambiguity when $# is 1: there is no way to know if i have no match
  or if a very bad person named its file \*no_way_this_glob_matches\*.
* i can't trust a loop like
    for it in \*no_way_this_glob_matches\*; do gzip "$it"; done

fortunately, this POSIX problem will not affect my daily life as

* i use zsh when i want a QND script or need an interactive shell
* for anything else, i use find . -name \*no_way_this_glob_matches\* -maxdepth 1 -print0

thank you so much for your help.

-- 
Marc Chantreux
Direction du numérique de l'Université de Strasbourg
Pôle de Calcul et Services Avancés à la Recherche (CESAR)
http://annuaire.unistra.fr/p/20200