2019-06-21 23:58:32 +0100, Harald van Dijk:
> In theory, pathname expansion is supposed to be done for every word, no
> matter which characters it contains. Even in something as simple as
>   echo hello
> both words undergo pathname expansion. The first word is supposed to be
> matched against the names in the current directory. If any matches "echo",
> then pathname expansion produces that name. If none matches, then the "echo"
> is used unmodified. Same for the second word.
> Obviously, this means that pathname expansion produces "echo", regardless of
> the contents of the current directory, and shells are allowed to bypass
> reading the current directory as the results do not depend on it. This is
> strictly speaking an optimisation though, and as such the "as the results to
> not depend on it" is a requirement for the optimisation to be valid. If
> shells bypass the reading when the results *do* depend on it, then that is a
> bug in the shells.

That's your way to look at it. Obviously, all the shells that
implement a nullglob, failglob, nomatch, cshnulglob option or
have a FIGNORE/GLOBIGNORE variable (ksh, bash, zsh, yash at
least) don't see it that way, as that would mean that your

  echo hello

would only work when run in a directory that contains both files
(or at least one of them for cshnullglob, or at least if neither

For them, and me, and it seems Eric as well, globbing is an
operator that is invoked whenever a word contains an unquoted
wildcard character (in "list" contexts).

At the time POSIX was written, \ was never a wildcard operator
in any of the shells (only possibly in zsh that didn't have a
"sh" mode at the time). It still isn't in the shell the POSIX
specification is based on (ksh88) and in many other ones
(zsh, bash, ksh93 and some ash-based shells are the only
exceptions that I know).

In those,

a='\x'; case x in $a) echo yes; esac

Doesn't output yes (you'll notice it's the main point of

A few shells have added \ as a wildcard operator as an extension
(and some reading of the standard could be seen as it being a
requirement), but while they could get away with doing it for the
"case" case above (where "case" is a tool for pattern matching),
they couldn't easily do it fully for globbing without severely
breaking Bourne/ksh88 compatibility (as unquoted variables are
often used (most of the time incorrectly) for something else
than a glob pattern), so they either didn't do it (dash/ksh93),
or in limited ways only (zsh/bash4/netbsd8.1-sh)

Today in bash5:

$ shopt -s failglob
$ windows_file='c:\temp'
$ echo $windows_file
bash5: no match: c:\temp

My reaction is "What? no match for what? There's no glob in

And it's worse with nullglob (though you would generally not
have nullglob globally on) where echo $windows_file outputs
an empty line (and of course it would output c:temp if there was
a file called c:temp in the current directory, or c:<tab>emp if
the xpg_echo was enabled which is just as confusing but not the
point I'm making here).


Reply via email to