Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #180644 > unrolled thread

Using -prune option of find to ignore hidden directories

Back to article view | Back to linux.debian.user

Contents

  Using -prune option of find to ignore hidden directories Richard Owlett <rowlett@cloud85.net> - 2017-05-03 17:00 +0200
    Re: Using -prune option of find to ignore hidden directories "Thomas Schmitt" <scdbackup@gmx.net> - 2017-05-03 17:20 +0200
    Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-03 17:20 +0200
      Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-03 17:50 +0200
        Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-03 18:10 +0200
          Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-03 18:20 +0200
            Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-03 18:30 +0200
              Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-03 19:40 +0200
        Re: Using -prune option of find to ignore hidden directories <tomas@tuxteam.de> - 2017-05-03 22:30 +0200
          Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-03 22:40 +0200
            Re: Using -prune option of find to ignore hidden directories <tomas@tuxteam.de> - 2017-05-03 23:20 +0200
          Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-04 04:30 +0200
            Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-04 04:50 +0200
              Re: Using -prune option of find to ignore hidden directories Bob McGowan <ramjr0915@gmail.com> - 2017-05-04 08:00 +0200
                Re: Using -prune option of find to ignore hidden directories <tomas@tuxteam.de> - 2017-05-04 09:30 +0200
                  Re: Using -prune option of find to ignore hidden directories Nicolas George <george@nsup.org> - 2017-05-04 09:40 +0200
                    Re: Using -prune option of find to ignore hidden directories tomas@tuxteam.de - 2017-05-04 10:00 +0200
                    Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-04 14:10 +0200
                      Re: Using -prune option of find to ignore hidden directories Nicolas George <george@nsup.org> - 2017-05-04 14:30 +0200
                        Re: Using -prune option of find to ignore hidden directories Greg Wooledge <wooledg@eeg.ccf.org> - 2017-05-04 14:40 +0200
                Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-04 13:40 +0200
      Re: Using -prune option of find to ignore hidden directories Richard Owlett <rowlett@cloud85.net> - 2017-05-03 19:40 +0200
        Addendum Re: Using -prune option of find to ignore hidden directories Richard Owlett <rowlett@cloud85.net> - 2017-05-03 20:00 +0200
        Re: Using -prune option of find to ignore hidden directories rhkramer@gmail.com - 2017-05-04 04:20 +0200
      Re: Using -prune option of find to ignore hidden directories David <bouncingcats@gmail.com> - 2017-05-04 02:00 +0200
        Re: Using -prune option of find to ignore hidden directories David <bouncingcats@gmail.com> - 2017-05-04 02:10 +0200

Page 1 of 2  [1] 2  Next page →

#180644 — Using -prune option of find to ignore hidden directories

The man page for find confuses me.
Looking for explanatory material I found and tried to follow examples in 
http://mywiki.wooledge.org/UsingFind#A-prune .

I tried
   find /home/richard \( -type d -name .* -prune \) -o -atime -42 -print
and
   find /home/richard \( -type d -name .* -prune \) -atime -42 -print
unsuccessfully.

Each got an "find: paths must precede expression: .." error

HOW?
TIA

[toc] | [next] | [standalone]

#180645

Hi,

Richard Owlett wrote:
> I tried
>   find /home/richard \( -type d -name .* -prune \) -o -atime -42 -print
> and
>   find /home/richard \( -type d -name .* -prune \) -atime -42 -print
> ...
> Each got an "find: paths must precede expression: .." error

You need to hide the .* word from the shell parser. I assume the parser
produces more than one word when looking for matching files.
Try:

  find /home/richard \( -type d -name '.*' -prune \) -o -atime -42 -print


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#180646

On Wednesday, May 03, 2017 10:57:09 AM Richard Owlett wrote:
> The man page for find confuses me.
> Looking for explanatory material I found and tried to follow examples in
> http://mywiki.wooledge.org/UsingFind#A-prune .
> 
> I tried
>    find /home/richard \( -type d -name .* -prune \) -o -atime -42 -print
> and
>    find /home/richard \( -type d -name .* -prune \) -atime -42 -print
> unsuccessfully.
> 
> Each got an "find: paths must precede expression: .." error
> 
> HOW?

Can't answer your question off the top of my head, but, when I run into 
problems like this, I try to run subsets of the command to try to narrow down 
the problem.  For example, I might first try find /home/richard--see if it works 
(provides any output) and what that output looks like, then try adding 
switches or other parts of the command one at a time.

Maybe next I'd try:

find /home/richard -type d -name .* (without the escaped parens), then maybe 
add the parens (I've never tried parens in a command like that, so am not sure 
they work, and then continue adding switches (or whatever) pretty much one at 
a time.

If I have to ask for help on the mailing list, I'd try to provide the command 
that I think I want to run (but didn't) (as you did), but also one or more of 
the commands I tried and did work.

[toc] | [prev] | [next] | [standalone]

#180647

On Wed, May 03, 2017 at 11:13:46AM -0400, rhkramer@gmail.com wrote:
> On Wednesday, May 03, 2017 10:57:09 AM Richard Owlett wrote:
> >    find /home/richard \( -type d -name .* -prune \) -o -atime -42 -print

> Maybe next I'd try:
> 
> find /home/richard -type d -name .* (without the escaped parens)

No, the problem is the unquoted .* glob.  That will expand to an
indeterminate number of filename arguments, and almost certainly will
not do what he wants.

Always quote glob patterns unless you actually want the shell to expand
them.  In this case, he wants find to receive it without expansion.

[toc] | [prev] | [next] | [standalone]

#180650

On Wednesday, May 03, 2017 11:44:31 AM Greg Wooledge wrote:
> On Wed, May 03, 2017 at 11:13:46AM -0400, rhkramer@gmail.com wrote:
> > On Wednesday, May 03, 2017 10:57:09 AM Richard Owlett wrote:
> > >    find /home/richard \( -type d -name .* -prune \) -o -atime -42
> > >    -print
> > 
> > Maybe next I'd try:
> > 
> > find /home/richard -type d -name .* (without the escaped parens)
> 
> No, the problem is the unquoted .* glob.  That will expand to an
> indeterminate number of filename arguments, and almost certainly will
> not do what he wants.
> 
> Always quote glob patterns unless you actually want the shell to expand
> them.  In this case, he wants find to receive it without expansion.

Not the OP (just one of the responders), but thanks, I hope I can let that 
sink into my subconscious (or somewhere ;-) and remember that in the future.

Oh, but in case it wasn't very clear, my intension wasn't so much a specific 
recommendation of what might work, but instead, a recommendation on a 
methodology to find the problem one's self.

[toc] | [prev] | [next] | [standalone]

#180651

On Wed, May 03, 2017 at 12:01:21PM -0400, rhkramer@gmail.com wrote:
> Oh, but in case it wasn't very clear, my intension wasn't so much a specific 
> recommendation of what might work, but instead, a recommendation on a 
> methodology to find the problem one's self.

Unfortunately, "remove random parts of the syntax and see what happens"
tends to be a poor approach, especially with find(1).  There may be
some other kinds of problems where that works well, but it wouldn't be
my recommendation in general practice.

[toc] | [prev] | [next] | [standalone]

#180654

On Wednesday, May 03, 2017 12:09:59 PM Greg Wooledge wrote:
> On Wed, May 03, 2017 at 12:01:21PM -0400, rhkramer@gmail.com wrote:
> > Oh, but in case it wasn't very clear, my intension wasn't so much a
> > specific recommendation of what might work, but instead, a
> > recommendation on a methodology to find the problem one's self.
> 
> Unfortunately, "remove random parts of the syntax and see what happens"
> tends to be a poor approach, especially with find(1).  There may be
> some other kinds of problems where that works well, but it wouldn't be
> my recommendation in general practice.

Ok.  It does seem to work for me fairly often.  I wouldn't call it random 
(although some might, and it might seem / be fairly random)--my goal is to find 
even a tiny subset of a command that works and then try building from there.

(And, as you noted, the methodoloy is not aimed only at find, and may be 
particularly bad for find (I've had a hate / hate relationship with find ever 
since I started using Linux ;-)


Do you have a better approach?

[toc] | [prev] | [next] | [standalone]

#180660

On Wed, May 03, 2017 at 12:23:26PM -0400, rhkramer@gmail.com wrote:
> On Wednesday, May 03, 2017 12:09:59 PM Greg Wooledge wrote:
> > Unfortunately, "remove random parts of the syntax and see what happens"
> > tends to be a poor approach, especially with find(1).  There may be
> > some other kinds of problems where that works well, but it wouldn't be
> > my recommendation in general practice.
> 
> Ok.  It does seem to work for me fairly often.  I wouldn't call it random 
> (although some might, and it might seem / be fairly random)--my goal is to find 
> even a tiny subset of a command that works and then try building from there.
> 
> (And, as you noted, the methodoloy is not aimed only at find, and may be 
> particularly bad for find (I've had a hate / hate relationship with find ever 
> since I started using Linux ;-)
> 
> 
> Do you have a better approach?

Starting with a small, known-to-work example and building on it is great.

Starting with a non-working example and removing pieces... not so great.

It can be extremely difficult to diagnose a non-working program,
especially if someone else wrote it.  This is why debugging takes a
really long time.  There are no simple platitudes that can guide you
toward finding the mistakes, let alone fixing them.  There are
heuristics and tricks that you can pick up with experience.

In the case of a longer program (e.g. a shell script with multiple
commands), commenting out chunks of code (whole commands) that you
suspect are not related to the problem, in order to whittle the
script down to the smallest subset of itself that still demonstrates
the problem, is a valid technique.  This helps you isolate where the
problem is occurring.

The same technique doesn't typically work with single commands, though.
The pieces have to fit together coherently, and you can't just remove
some of them without changing the meaning of all the other pieces.
Stupid example:

ls -l .* | grep foobar

That's a horrible command, broken in multiple ways, but maybe you think
you can fix it.  So you try removing the pipeline.  Now the grep isn't
even a command any more; it's a filename argument to ls.  You've just
made it worse.

The only way to fix that is to rewind back to the beginning, get a
statement of the intended GOAL from whoever wrote the command (it may
not be what you guessed initially!), and then rewrite a whole new
command that will achieve the goal.

[toc] | [prev] | [next] | [standalone]

#180663

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 03, 2017 at 11:44:31AM -0400, Greg Wooledge wrote:
> On Wed, May 03, 2017 at 11:13:46AM -0400, rhkramer@gmail.com wrote:
> > On Wednesday, May 03, 2017 10:57:09 AM Richard Owlett wrote:
> > >    find /home/richard \( -type d -name .* -prune \) -o -atime -42 -print
> 
> > Maybe next I'd try:
> > 
> > find /home/richard -type d -name .* (without the escaped parens)
> 
> No, the problem is the unquoted .* glob.  That will expand to an
> indeterminate number of filename arguments, and almost certainly will
> not do what he wants.

Bullseye :-)

FWIW, a trick to see what's really going on is to prepend an echo
before all that:

  echo find /home/richard -type d -name .*

(for the example above). Of course you won't think of that if you
are't suspecting shell expansion in the first place, but I find
it very instructive to see what the shell is "seeing". That'll
help memory for the next time (it does for me, at least).

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkKPCEACgkQBcgs9XrR2kZkygCeK51tKEF+OPTXJ137Eqb5W5W+
DhYAnRi0DMNAw5HxyTjDShuxzX0yrDAP
=mZEs
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180664

On Wed, May 03, 2017 at 10:22:57PM +0200, tomas@tuxteam.de wrote:
> FWIW, a trick to see what's really going on is to prepend an echo
> before all that:
> 
>   echo find /home/richard -type d -name .*
> 
> (for the example above). Of course you won't think of that if you
> are't suspecting shell expansion in the first place, but I find
> it very instructive to see what the shell is "seeing". That'll
> help memory for the next time (it does for me, at least).

Yeah, that's a good start.  I actually have a little script I wrote,
called "args":

wooledg:~$ cat bin/args
#!/bin/sh
printf "%d args:" "$#"
printf " <%s>" "$@"
echo

It's similar to echo, but gives a bit more feedback.

wooledg:~$ args echo *.txt
6 args: <echo> <equipment.txt> <gistfile1.txt> <items.txt> <rename.pl.txt> <TWL06.txt>

wooledg:~$ args "" '' '{}' '"' "'"
5 args: <> <> <{}> <"> <'>

Yet another basic tool you can use for certain kinds of analysis.
Like, when you're learning just how bad ssh is at certain things like
preserving arguments:

wooledg:~$ ssh localhost bin/args echo "a quoted string with spaces"
wooledg@localhost's password: 
6 args: <echo> <a> <quoted> <string> <with> <spaces>

"Oh, so THAT'S why it's breaking!"
(cf. http://mywiki.wooledge.org/BashFAQ/096)

[toc] | [prev] | [next] | [standalone]

#180665

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 03, 2017 at 04:38:15PM -0400, Greg Wooledge wrote:
> On Wed, May 03, 2017 at 10:22:57PM +0200, tomas@tuxteam.de wrote:
> > FWIW, a trick to see what's really going on is to prepend an echo
> > before all that:
> > 
> >   echo find /home/richard -type d -name .*
> > 
> > (for the example above). Of course you won't think of that if you
> > are't suspecting shell expansion in the first place, but I find
> > it very instructive to see what the shell is "seeing". That'll
> > help memory for the next time (it does for me, at least).
> 
> Yeah, that's a good start.  I actually have a little script I wrote,
> called "args":
> 
> wooledg:~$ cat bin/args
> #!/bin/sh
> printf "%d args:" "$#"
> printf " <%s>" "$@"
> echo

[...]

Nifty!

At the same time it shows the power of the shell's text substitution
model, which at the same time is its weakness. Shell is a very
interesting language model, somewhat dual to the languages in
fashion these days. Tread carefully :-)

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkKSOcACgkQBcgs9XrR2ka6+gCcCKKVWMTqnZQYzriaOsT7YMyW
7jEAn3IEVFDBC4cvrhBQGxRnNmYWkrWL
=KUWv
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180674

On Wednesday, May 03, 2017 04:22:57 PM tomas@tuxteam.de wrote:
> FWIW, a trick to see what's really going on is to prepend an echo
> before all that:
> 
>   echo find /home/richard -type d -name .*

That seems like a helpful trick, but I'm not sure what I should see.

On my (Wheezy) system, I tried that, i.e.:


echo find /home/<my_username> -type d -name .*

and 

echo find /home/<my_username> -type d -name '.*'

and, in both cases, I got the same result:

find /home/<my_username> -type d -name .*

From what you wrote (below) I expected to see something different, maybe more 
like the following, at least for the case with the .* not within single 
quotes:

find /home/<my_username> -type d -name <dir1> <dir2> ...

I presume you see the same thing on your system, so I'm missing something (and 
not ready to try a lot of experiments atm (near bedtime).

Any clarification will be welcomed!



> 
> (for the example above). Of course you won't think of that if you
> are't suspecting shell expansion in the first place, but I find
> it very instructive to see what the shell is "seeing". That'll
> help memory for the next time (it does for me, at least).
> 
> cheers
> -- t

[toc] | [prev] | [next] | [standalone]

#180675

Hmm, maybe I don't need a response to this--I think if I read Greg Wooledge's 
post (next in the thread) and experiment (tomorrow or later ;-) with his 
script, I'll get the idea...

On Wednesday, May 03, 2017 10:29:08 PM rhkramer@gmail.com wrote:
> On Wednesday, May 03, 2017 04:22:57 PM tomas@tuxteam.de wrote:
> > FWIW, a trick to see what's really going on is to prepend an echo
> > 
> > before all that:
> >   echo find /home/richard -type d -name .*
> 
> That seems like a helpful trick, but I'm not sure what I should see.
> 
> On my (Wheezy) system, I tried that, i.e.:
> 
> 
> echo find /home/<my_username> -type d -name .*
> 
> and
> 
> echo find /home/<my_username> -type d -name '.*'
> 
> and, in both cases, I got the same result:
> 
> find /home/<my_username> -type d -name .*
> 
> From what you wrote (below) I expected to see something different, maybe
> more like the following, at least for the case with the .* not within
> single quotes:
> 
> find /home/<my_username> -type d -name <dir1> <dir2> ...
> 
> I presume you see the same thing on your system, so I'm missing something
> (and not ready to try a lot of experiments atm (near bedtime).
> 
> Any clarification will be welcomed!
> 
> > (for the example above). Of course you won't think of that if you
> > are't suspecting shell expansion in the first place, but I find
> > it very instructive to see what the shell is "seeing". That'll
> > help memory for the next time (it does for me, at least).
> > 
> > cheers
> > -- t

[toc] | [prev] | [next] | [standalone]

#180680

On 05/03/2017 07:44 PM, rhkramer@gmail.com wrote:
> Hmm, maybe I don't need a response to this--I think if I read Greg Wooledge's 
> post (next in the thread) and experiment (tomorrow or later ;-) with his 
> script, I'll get the idea...
>
> On Wednesday, May 03, 2017 10:29:08 PM rhkramer@gmail.com wrote:
>> On Wednesday, May 03, 2017 04:22:57 PM tomas@tuxteam.de wrote:
>>> FWIW, a trick to see what's really going on is to prepend an echo
>>>
>>> before all that:
>>>   echo find /home/richard -type d -name .*
>> That seems like a helpful trick, but I'm not sure what I should see.
>>
>> On my (Wheezy) system, I tried that, i.e.:
>>
>>
>> echo find /home/<my_username> -type d -name .*
>>
>> and
>>
>> echo find /home/<my_username> -type d -name '.*'
>>
>> and, in both cases, I got the same result:
>>
>> find /home/<my_username> -type d -name .*
>>
>> From what you wrote (below) I expected to see something different, maybe
>> more like the following, at least for the case with the .* not within
>> single quotes:
>>
>> find /home/<my_username> -type d -name <dir1> <dir2> ...
>>
>> I presume you see the same thing on your system, so I'm missing something
>> (and not ready to try a lot of experiments atm (near bedtime).
>>
>> Any clarification will be welcomed!
>>
>>> (for the example above). Of course you won't think of that if you
>>> are't suspecting shell expansion in the first place, but I find
>>> it very instructive to see what the shell is "seeing". That'll
>>> help memory for the next time (it does for me, at least).
>>>
>>> cheers
>>> -- t

What directory were you in when you ran the command?  If you were in
your home directory, the .* should have expanded into ". .. <and every
.file and .directory>", if you were in some other directory you might
only see the ". .." (dot dotdot).

When I ran it in my home directory, I saw everything from .ICEauthority
to .xsession-errors.

Bob

[toc] | [prev] | [next] | [standalone]

#180681

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, May 03, 2017 at 10:45:30PM -0700, Bob McGowan wrote:

[...]

> >>> before all that:
> >>>   echo find /home/richard -type d -name .*
> >> That seems like a helpful trick, but I'm not sure what I should see.
> >>
> >> On my (Wheezy) system, I tried that, i.e.:
> >>
> >>
> >> echo find /home/<my_username> -type d -name .*
> >>
> >> and
> >>
> >> echo find /home/<my_username> -type d -name '.*'
> >>
> >> and, in both cases, I got the same result:
> >>
> >> find /home/<my_username> -type d -name .*

[...]

> What directory were you in when you ran the command?  If you were in
> your home directory, the .* should have expanded into ". .. <and every
> .file and .directory>", if you were in some other directory you might
> only see the ". .." (dot dotdot).
> 
> When I ran it in my home directory, I saw everything from .ICEauthority
> to .xsession-errors.

Exactly. Try again in a directory with something in it, and you'll
appreciate the whole power/curse of the thing :-)

The shell takes a lot from the "ambient" (current directory, shell
variables inherited through the dynamic path, etc.) and this makes
for an incredibly concise language, but is an opportunity for incredibly
clever bugs.

Learning shell means developing some feeling for this ambient.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkK13oACgkQBcgs9XrR2kaAIACcCB+8K4hlMWKVA9IMJ0kgCXuI
Dy4An2r9ZyvnBw1mPjdter4PHdBMMS/w
=DvIH
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180682

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 15 floréal, an CCXXV, tomas@tuxteam.de a écrit :
> Exactly. Try again in a directory with something in it, and you'll
> appreciate the whole power/curse of the thing :-)
> 
> The shell takes a lot from the "ambient" (current directory, shell
> variables inherited through the dynamic path, etc.) and this makes
> for an incredibly concise language, but is an opportunity for incredibly
> clever bugs.

Note that it is a severe misfeature of the shell to have a very
different behaviour when a glob matches than when a glob does not match.

I have seen make commands fail because they contained unquoted "[a]"
arguments and someone just created a temporary file named a.

Fortunately, zsh fixes that: a glob that does not match either produce
an error or expand to an empty list.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#180684

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, May 04, 2017 at 09:36:11AM +0200, Nicolas George wrote:
> Le quintidi 15 floréal, an CCXXV, tomas@tuxteam.de a écrit :
> > Exactly. Try again in a directory with something in it, and you'll
> > appreciate the whole power/curse of the thing :-)
> > 
> > The shell takes a lot from the "ambient" (current directory, shell
> > variables inherited through the dynamic path, etc.) and this makes
> > for an incredibly concise language, but is an opportunity for incredibly
> > clever bugs.
> 
> Note that it is a severe misfeature of the shell to have a very
> different behaviour when a glob matches than when a glob does not match.

I stopped for a long time judging such things. There are languages I like
and those I don't. There are things I don't like in languages I generally
like. And so on.

> I have seen make commands fail because they contained unquoted "[a]"
> arguments and someone just created a temporary file named a.
> 
> Fortunately, zsh fixes that: a glob that does not match either produce
> an error or expand to an empty list.

One might argue that it's a misfeature of shells in general that there
are so many different implementations (giving birth to that "portable
shell" abomination which haunts Autotools to this day). But then, one
might argue that this is a strength, allowing different approaches to
be explored (which is fun, and as Alan Perlis once said, programming
*should* be about fun).

Case in point: I never used zsh, my comfort zone is smack within bash
(while avoiding a bit the most outrageous "specialties", or at least
using them with caution); still I'm really happy zsh exists, and I
enjoy tidbits as the one you gave above -- just as I enjoy listening
to different dialects of (human) languages.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlkK3jYACgkQBcgs9XrR2kZXgQCeLKfAcAhl1KJy7dD3BTki1dQR
kjwAnAtkBlDMgrN3cGZ1n9AGMPcShY0W
=5InS
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#180687

On Thu, May 04, 2017 at 09:36:11AM +0200, Nicolas George wrote:
> Note that it is a severe misfeature of the shell to have a very
> different behaviour when a glob matches than when a glob does not match.
> 
> I have seen make commands fail because they contained unquoted "[a]"
> arguments and someone just created a temporary file named a.
> 
> Fortunately, zsh fixes that: a glob that does not match either produce
> an error or expand to an empty list.

Bash has an option for this behavior (nullglob).  It's off by default
because it produces extremely surprising results in interactive use.
Most of the traditional Unix commands are designed around the standard
shell behavior of expanding a glob if possible, but leaving it untouched
if it matches nothing.

For example, rm(1):

$ rm *.txy
rm: cannot remove '*.txy': No such file or directory

rm expects an expanded list of pathnames, and tries to remove each of
them.  If one of them can't be removed, then it writes the argument
as part of the error message, so you know which one it couldn't remove.
With an unmatched glob, the glob itself is passed as the argument, so
rm can include it in the error message.

If you turn on nullglob, the unmatched *.txy glob simply vanishes,
and you end up executing rm with no arguments at all:

$ shopt -s nullglob
$ rm *.txy
rm: missing operand
Try 'rm --help' for more information.

This is slightly confusing, but you might think "Hey, I can live with
that."

But then there is ls(1).

If ls is invoked with no arguments, it lists the entire current working
directory.

$ shopt -u nullglob
$ ls *.txy
ls: cannot access '*.txy': No such file or directory
$ shopt -s nullglob
$ ls *.txy
0400_0001.pdf
1
11412687.html
11412687.pdf
[...]

So, I really would not endorse the use of nullglob in interactive shells.
Even in a script, you must use it with caution.

[toc] | [prev] | [next] | [standalone]

#180688

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 15 floréal, an CCXXV, Greg Wooledge a écrit :
> Bash has an option for this behavior (nullglob).  It's off by default
> because it produces extremely surprising results in interactive use.

For interactive use, the other other behaviour is obviously the best
one:

~ $ ls *.c
zsh: no matches found: *.c
zsh: exit 1     ls --color=tty -FT0 *.c

Notice how zsh is reporting the error, not ls?

> Most of the traditional Unix commands are designed around the standard
> shell behavior of expanding a glob if possible, but leaving it untouched
> if it matches nothing.

This is completely untrue, fortunately.

> For example, rm(1):
> 
> $ rm *.txy
> rm: cannot remove '*.txy': No such file or directory
> 
> rm expects an expanded list of pathnames, and tries to remove each of
> them.  If one of them can't be removed, then it writes the argument
> as part of the error message, so you know which one it couldn't remove.

Case in point: rm does nothing special with globs.

[toc] | [prev] | [next] | [standalone]

#180689

On Thu, May 04, 2017 at 02:22:38PM +0200, Nicolas George wrote:
> For interactive use, the other other behaviour is obviously the best
> one:
> 
> ~ $ ls *.c
> zsh: no matches found: *.c
> zsh: exit 1     ls --color=tty -FT0 *.c
> 
> Notice how zsh is reporting the error, not ls?

Oh, bash calls that one "failglob".

wooledg:~$ shopt -s failglob
wooledg:~$ ls *.txy
bash: no match: *.txy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web