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: Nora Platiel
Subject: Re: !(.pattern) can match . and .. if dotglob is enabled
Date: Thu, 17 Jun 2021 21:53:32 +0200

On 2021-06-15 10:19 Chet Ramey wrote:
> > Or rather,
> > to never generate . or .. as a pathname component via globbing.
>
> I don't think it's useful -- and it's certainly incompatible -- to make
> an explicit pattern like `.?' ignore `..'.

I think it would be most useful. A better design.

Of course this is just for the sake of argument, because I always assumed that 
changing the behavior of patterns like `.?' is out of the question on the 
grounds of compatibility and standard compliance (as it should be! I'm not 
proposing to take any action here).

In 20 years, every single time one of my glob patterns expanded to `.' or `..', 
it was either an error or I would discard them later.
I challenge anyone to show me a piece of code where it is useful for a 
non-literal path component to expand to `.' or `..'.

If you get `.' or `..' by accident you can mess up things. They are special 
names with a special meaning; if you need one of them you don't "search" for 
it, you name it (or you can use brace expansion to add it to other results).

> > Personally, I'd just want an option to always make . and .. hidden from
> > globs.
>
> You can use GLOBIGNORE for this, but you have to do a little more work.
[...]
> Yes, that's the `more work' part. You have to tune it to your needs.

But this `more work' part has to take place on a pattern by pattern basis, 
because there is no value of GLOBIGNORE that you can just set-and-forget.
For example a value of `./*:../*' is appropriate for the pattern `.*/foo.txt', 
but surely not for the pattern `./foo*.txt'.

If each pattern requires its own "mask", then it would defeat the intended 
purpose of the OP's desired option, which is to make patterns simpler and less 
error prone.
What we had in mind is some kind of on/off option that we could just keep 
turned on and it would always prevent non-literal path components to expand to 
`.' or `..'.

As I said, I can live without such option, because I can reliably hide `.' and 
`..' by protecting any leading dot with brackets (e.g. `[.]*/foo.txt') as long 
as dotglob is set.

Regards,
NP



reply via email to

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