2019-09-24 09:46:27 +0100, Geoff Clare: [...] > > Regardless, the above question applies in > > [...] > var='\*' [...] > > printf '%s\n' */$var > > > > Or > > > > printf '%s\n' $var/* > > Those both have a * that will be treated as special, so matching > against existing files is performed. The permission requirements in > these two cases are the same as if you had used var=foo. > > > (where there are variations among the shells that implement that > > second meaning of backslash). > > Do you mean you see variation in those last two cases, or only in > the first case, where bash 4 and earlier do what's specified in the > bug 1234 resolution but in bash 5, printf "%s\n" $var outputs * > when a * file exists? [...]
Sorry for not being clear here. In: */x, the shell only needs search access to all the directories in the current directory (it will typically attempt a lstat(dir/x) for each of them. (And you need search and read access to the current directory) In x/*, you need search access to the current directory but no read access. The shell is not looking for a file matching "x" in all the entries in the current directory, it's directly opening x (and then looping through all its entries to find files matching "*" (for which it needs read but not search permission). (note that it's different when the nocaseglob non-standard option of some shells is used). There's no difference for a litteral */'*' or '*'/* (or */\* and \*/*), but now there's the question of: */$var and $var/* where var='\*'. Several of those shells that implement a \ globbing operator treat it like the other glob operators in that regard and trigger a "look for files matching the pattern in the content of the directory" even if the path component that contains an unquoted \ doesn't contain unquoted unescaped ?*[, so in effect the */$var and $var/* expansion is done the same way as if $var contained [*]. -- Stephane
