On 03/06/2019 10:54, Joerg Schilling wrote:
Harald van Dijk <a...@gigawatt.nl> wrote:
(Re-sending from the right e-mail address, apologies if it arrives twice.)
On 30/05/2019 20:44, Nick Stoughton wrote:
During today's teleconference we discussed whether the pathname
expansion ".*" should always include "." and "..". Existing practice is
that if readdir() returns entries for these directories, then they are
always included.
Some shells (mksh, pdksh, posh, zsh) already skip . and .. regardless of
what readdir() returns, even when invoked as sh.
So these shells are not compliant and they will not give the expected result
with:
echo .*/Makefile
which is:
../Makefile ./Makefile
False. Assuming those paths exist and no other paths match, the
currently expected result depends. It can either be what you wrote, or
it can be ".*/Makefile" if readdir() does not return entries for "." and
"..". Even if there were not already shells that skipped "." and ".."
internally, portable shell scripts would still not be able to rely on
".*" or ".*/Makefile" expanding the way you are expecting.
You know this already: you specifically pointed out this problem in your
reply to Stephane Chazelas (despite the immediately following paragraph
that you snipped already addressing that problem). I do not know why you
would claim that ".*/Makefile" has a guaranteed expansion here.
The new shell flag is to allow to select both ways of handling that case.
The whole point of my message was that I would be very surprised if
people are actually looking for both ways of handling that case.
Cheers,
Harald van Dijk
