bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: !(.pattern) can match . and .. if dotglob is enabled


From: Ilkka Virta
Subject: Re: !(.pattern) can match . and .. if dotglob is enabled
Date: Sun, 6 Jun 2021 13:31:00 +0300

> Can you write a set of rules that encapsulates what you would like to see?
> Or can the group?
>

I think it's a bit weird that !(.foo) can match . and .. when * doesn't.

The other means roughly "anything here", and the other means "anything but
.foo here",
so having the latter match things the former doesn't is surprising.

Personally, I'd just want an option to always make . and .. hidden from
globs. Or rather,
to never generate . or .. as a pathname component via globbing. But without
affecting
other behaviour, like dotglob, and without precluding the use of . or .. as
static parts of the
path.

As in:
$ touch .dot normal
$ echo .*
.dot
$ echo ./.*
./.dot

And depending on dotglob,  echo *  should give either  .dot normal  or
just  normal .

So, somewhat similarly to how globbing hides pathname components starting
with a
dot when dotglob is unset, just with another option to hide . and .. in
particular.

Frankly, I don't care if that would also mean that ./@(.|..)/ would match
nothing. I don't
see much use for globbing . and .. in any situation, the dangers of
accidentally climbing up
one level in the tree by a stray .* are much worse. Someone else might
disagree, of course,
but if one really wants to include those two, brace expansion should work
since the two
names are always known to exist anyway. And of course if it's an option,
one doesn't need
to use it if they don't like it.

For what it's worth, Zsh, mksh and fish seem to always hide . and .. , and
at least Zsh does
that even with (.|..) or @(.|..) .


I tried to achieve that via GLOBIGNORE=.:.. , but that has the problem that
it forces dotglob
on, and looks at the whole resulting path, so ./.* still gives ./. and ./..
. Unless you use
GLOBIGNORE=.:..:*/.:*/.. etc., but repeating the same for all different
path lengths gets a bit
awkward.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]