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 match FIGNORE/GLOBIGNORE) 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 bug1234) 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 there" 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). -- Stephane
