A wildcard (...)

[James]

Instead of
ls path/*/*.txt
ls path/*/*/*.txt

wouldn't it be nice if a shell has "..." as a wildcard? For example,

ls path/....txt

(... includes slashes)

(similar to perforce filespec)

Or does shell already have similar wildcards?

TIA
James

[hymie!]

In our last episode, the evil Dr. Lacto had captured our hero,

James <hsle...@yahoo.com>, who said:
> Instead of
> ls path/*/*.txt
> ls path/*/*/*.txt
>
> wouldn't it be nice if a shell has "..." as a wildcard? For example,
> ls path/....txt
> (... includes slashes)

zsh has this.

herman:/herman/cd/songs$ ls **/*famous*
billy.joel/12.river.of.dreams/10.famous.last.words.mp3

I don't think it has been back-ported into standard bash, but I don't
know for sure.

--hymie! http://lactose.homelinux.net/~hymie hy...@lactose.homelinux.net
My fitbit says I've walked 2609 steps today (as of 12:38).

[Janis Papanagnou]

Standard shell does not support such functionality, but you can find the
feature in zsh or ksh (for example). In ksh you have to activate it with

set -o globstar

then use ** instead of * for hierarchies of directories, as in

ls Downloads/**/COPYING.*


Janis

>
> TIA
> James
>

[Janis Papanagnou]

I just inspected the bash man page, and I see that bash supports it as well.

> Janis
>
>>
>> TIA
>> James
>>
>

[hymie!]

In our last episode, the evil Dr. Lacto had captured our hero,

hymie! <hy...@lactose.homelinux.net>, who said:
> In our last episode, the evil Dr. Lacto had captured our hero,
> James <hsle...@yahoo.com>, who said:
>> Instead of
>> ls path/*/*.txt
>> ls path/*/*/*.txt
>>
>> wouldn't it be nice if a shell has "..." as a wildcard? For example,
>> ls path/....txt
>> (... includes slashes)

Janis was right. Bash has this option, if you turn it on.

$ ls **/*famous*
ls: cannot access **/*famous*: No such file or directory
$ shopt -s globstar
$ ls **/*famous*
billy.joel/12.river.of.dreams/10.famous.last.words.mp3
$

--hymie! http://lactose.homelinux.net/~hymie hy...@lactose.homelinux.net

[lawren...@gmail.com]

On Friday, July 15, 2016 at 4:35:56 AM UTC+12, James wrote:
> Instead of
> ls path/*/*.txt
> ls path/*/*/*.txt
>
> wouldn't it be nice if a shell has "..." as a wildcard?

Why would you need it?

ls $(find path -name \*.txt)

find(1) <http://man7.org/linux/man-pages/man1/find.1.html> can do everything that you might want, and more.

[Janis Papanagnou]

On 15.07.2016 03:25, lawren...@gmail.com wrote:
> On Friday, July 15, 2016 at 4:35:56 AM UTC+12, James wrote:
>> Instead of
>> ls path/*/*.txt
>> ls path/*/*/*.txt
>>
>> wouldn't it be nice if a shell has "..." as a wildcard?
>
> Why would you need it?

One reason is that it's terse and a straightforward formalism for the
intended task. It also does not require external commands. And, compared
to find, it just has a different semantic.

>
> ls $(find path -name \*.txt)
>
> find(1) <http://man7.org/linux/man-pages/man1/find.1.html> can do everything that you might want, and more.

The find command can do a lot other things, yes, but it seems not the same
as recursive globbing patterns. How would you implement path/**/test/*.txt
using find? (And this is just a simple example.)

Janis

[lawren...@gmail.com]

On Friday, July 15, 2016 at 2:03:18 PM UTC+12, Janis Papanagnou wrote:
> How would you implement path/**/test/*.txt
> using find? (And this is just a simple example.)

find path -regex '.*\/test\/[^\/]*\.txt'

[Janis Papanagnou]

And why do you think that it's better to use this complex and non-standard
find(1) expression than using the much simpler (also non-standard) globbing
expression?

Janis

[lawren...@gmail.com]

On Friday, July 15, 2016 at 3:01:34 PM UTC+12, Janis Papanagnou wrote:

>
> On 15.07.2016 04:28, Lawrence D’Oliveiro wrote:
>>
>> On Friday, July 15, 2016 at 2:03:18 PM UTC+12, Janis Papanagnou wrote:
>>>
>>> How would you implement path/**/test/*.txt
>>> using find? (And this is just a simple example.)
>>
>> find path -regex '.*\/test\/[^\/]*\.txt'
>>
>
> And why do you think that it's better to use this complex and non-standard
> find(1) expression than using the much simpler (also non-standard) globbing
> expression?

You asked a question, I gave you an answer. Don’t like it? You know what you can do.

[Chris F.A. Johnson]

On 2016-07-15, lawren...@gmail.com wrote:
> On Friday, July 15, 2016 at 4:35:56 AM UTC+12, James wrote:
>> Instead of
>> ls path/*/*.txt
>> ls path/*/*/*.txt
>>
>> wouldn't it be nice if a shell has "..." as a wildcard?
>
> Why would you need it?
>
> ls $(find path -name \*.txt)

AAARRRGGGHHHH!!!!!!

That will break if any filenames contain whitespace or other
pathological characters.

Why not just:

find path -name \*.txt

If you want a long listing:

find path -name \*.txt -ls


--
Chris F.A. Johnson

[lawren...@gmail.com]

On Friday, July 15, 2016 at 4:08:05 PM UTC+12, Chris F.A. Johnson wrote:

>> ls $(find path -name \*.txt)
>
> AAARRRGGGHHHH!!!!!!
>
> That will break if any filenames contain whitespace or other
> pathological characters.

Don’t you know how to fix that? Exercise left for the reader. :)

[Janis Papanagnou]

Yes, I don't like it because it seems to be inferiour for the severaly
reasons I gave upthread, but nevermind; I just tried to understand why
in your initial reply you asked "Why would you need it [the recursive
globbing]?". One possible reason to use find(1) in such contexts would
be if its use would have some advantage, for example if you would have
had a standard solution [with find].

Janis

[Ben Bacarisse]

That doesn't do the same thing as the ls command (dot files spring to
mind) but I suppose it's arguable if it is even worth trying to come up
with an exact equivalent. If your shell does not have the ** syntax you
might well be happy with a close alternative.

--
Ben.

[Chris F.A. Johnson]

On 2016-07-15, lawren...@gmail.com wrote:
> On Friday, July 15, 2016 at 4:08:05 PM UTC+12, Chris F.A. Johnson wrote:
>
>>> ls $(find path -name \*.txt)
>>
>> AAARRRGGGHHHH!!!!!!
>>
>> That will break if any filenames contain whitespace or other
>> pathological characters.
>

> Don???t you know how to fix that? Exercise left for the reader. :)

"That" is something that only someone who has failed Shell Scripting
101 would write.

Anyone else would do it correctly right off the bat.

--
Chris F.A. Johnson

[lawren...@gmail.com]

On Saturday, July 16, 2016 at 7:08:06 AM UTC+12, Chris F.A. Johnson wrote:

>
> On 2016-07-15, Lawrence D’Oliveiro wrote:
>>
>> On Friday, July 15, 2016 at 4:08:05 PM UTC+12, Chris F.A. Johnson wrote:
>>
>>>> ls $(find path -name \*.txt)
>>>
>>> AAARRRGGGHHHH!!!!!!
>>>
>>> That will break if any filenames contain whitespace or other
>>> pathological characters.
>>

>> Don’t you know how to fix that? Exercise left for the reader. :)

>
> "That" is something that only someone who has failed Shell Scripting
> 101 would write.
>
> Anyone else would do it correctly right off the bat.

In that case, blame the OP for posting an example prone to the same problem.

[Kaz Kylheku]

Nonsense; globbing has no such problem. Given something like

ls **/*.txt

regardless of what characters the matching paths contain, they will be
correctly turned into the "char **argv" vector of null-terminated
strings passed to the ls program. (There is another problem here, which
is that the expansion could overwhelm the arg/env passing limit.)

The problem above is caused purely by ambiguities in the text processing
performed by the $(...) construct: taking the output of a program as a
big string which is then broken into words.

[lawren...@gmail.com]

On Saturday, July 16, 2016 at 1:20:02 PM UTC+12, Kaz Kylheku wrote:
> On 2016-07-15, Lawrence D’Oliveiro wrote:
>> On Saturday, July 16, 2016 at 7:08:06 AM UTC+12, Chris F.A. Johnson wrote:
>>>
>>> On 2016-07-15, Lawrence D’Oliveiro wrote:
>>>>
>>>> On Friday, July 15, 2016 at 4:08:05 PM UTC+12, Chris F.A. Johnson wrote:
>>>>
>>>>>> ls $(find path -name \*.txt)
>>>>>
>>>>> AAARRRGGGHHHH!!!!!!
>>>>>
>>>>> That will break if any filenames contain whitespace or other
>>>>> pathological characters.
>>>>
>>>> Don’t you know how to fix that? Exercise left for the reader. :)
>>>
>>> "That" is something that only someone who has failed Shell Scripting
>>> 101 would write.
>>>
>>> Anyone else would do it correctly right off the bat.
>>
>> In that case, blame the OP for posting an example prone to the same
>> problem.
>
> Nonsense; globbing has no such problem.

Up to a point. And the GNU versions of find and xargs have an extension to allow coping with any possible pathname. But sooner or later you are going to run into trouble at some point in your processing anyway.

Shell scripts are for solving quick-and-dirty problems. For anything beyond this, you should use a proper programming language like Python or Perl or such.

[Kaz Kylheku]

On 2016-07-16, lawren...@gmail.com <lawren...@gmail.com> wrote:
> On Saturday, July 16, 2016 at 1:20:02 PM UTC+12, Kaz Kylheku wrote:
>> On 2016-07-15, Lawrence D’Oliveiro wrote:
>>> On Saturday, July 16, 2016 at 7:08:06 AM UTC+12, Chris F.A. Johnson wrote:
>>>>
>>>> On 2016-07-15, Lawrence D’Oliveiro wrote:
>>>>>
>>>>> On Friday, July 15, 2016 at 4:08:05 PM UTC+12, Chris F.A. Johnson wrote:
>>>>>
>>>>>>> ls $(find path -name \*.txt)
>>>>>>
>>>>>> AAARRRGGGHHHH!!!!!!
>>>>>>
>>>>>> That will break if any filenames contain whitespace or other
>>>>>> pathological characters.
>>>>>
>>>>> Don’t you know how to fix that? Exercise left for the reader. :)
>>>>
>>>> "That" is something that only someone who has failed Shell Scripting
>>>> 101 would write.
>>>>
>>>> Anyone else would do it correctly right off the bat.
>>>
>>> In that case, blame the OP for posting an example prone to the same
>>> problem.
>>
>> Nonsense; globbing has no such problem.
>
> Up to a point.

What point?

> And the GNU versions of find and xargs ...

are not "globbing", thanks for playing.