Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A common mistake involving wildcards and the find command

blog.robertelder.org

Post reply on HN
Print view View original

61–70 of 148 posts

Re: A common mistake involving wildcards and the find command

#61

Post by weberc2 »

svnpenn wrote: post #16

As another user mentioned, many POSIX and/or GNU utilities havent aged well. I respect trying to stay portable, but peoples needs change over time and these tools simply havent kept up. Like the other user, I use Fd now instead: https://github.com/sharkdp/fd As well as Silver Searcher: https://github.com/ggreer/the_silver_searcher while Grep performance is pretty good, its also gotten pretty stale with regard to its…

In this case the shell hasn’t aged well. Besides the globing feature, the bash language is arcane and few can actually reliably write correct bash despite it being ubiquitous. Personally I would like to see a completely reimagined take on the shell.

Re: A common mistake involving wildcards and the find command

#62

Post by eikenberry »

anonsivalley652 wrote: post #57
svnpenn wrote: post #16

As another user mentioned, many POSIX and/or GNU utilities havent aged well. I respect trying to stay portable, but peoples needs change over time and these tools simply havent kept up. Like the other user, I use Fd now instead: https://github.com/sharkdp/fd As well as Silver Searcher: https://github.com/ggreer/the_silver_searcher while Grep performance is pretty good, its also gotten pretty stale with regard to its…

For grepping, rg is faster and saner. https://github.com/BurntSushi/ripgrep On end-user systems with fast I/O, it is usually a better use of resources to have a battery-/suspend-/reboot-aware indexing system that has path/extension white/blacklists and prioritizes file monitored changes. This way, searching can happen against an optimized text search DBMS much faster than waiting for zillions of IOPS that are basical…

Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? 25 years of habit is a lot of reinforcement to overcome and I'd love to just be able to take advantage of these tools with an alias.

As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well.

Re: A common mistake involving wildcards and the find command

#63

Post by chubot »

twic wrote: post #10

I often set the nullglob option in scripts, because it makes the handling of globs which don't match anything a bit more predictable: http://bash.cumulonim.biz/NullGlob.html There's a note at the end about how with nullglob set, ls on a glob with no matches does something surprising. This is a great illustration of how an empty list and the absence of a list are different. Sadly it's rather hard to make that distinct…

Yes, Oil (https://oilshell.org/) now has nullglob on when you run bin/oil instead of bin/osh.

So you get this:

    oil$ find . -name *.jpg
    find: missing argument to `-name'

    oil$ find . -name '*.jpg'
    (works)
Details: I had it on when you set 'shopt -s strict:all', but I neglected to turn it on for 'oil:basic' and 'oil:all'. Those are oil-specific option groups so you don't have to remember all the option names.

But I just fixed that and it will be out with the next Oil release.

https://github.com/oilshell/oil/commit/ddac119254f9a7045dca7...

If anyone wants to add more strictness options to Oil to avoid these types of mistakes, let us know! (e.g. on https://github.com/oilshell/oil, or there's more contact info on the home page).

Re: A common mistake involving wildcards and the find command

#64

Post by anonsivalley652 »

eikenberry wrote: post #62
anonsivalley652 wrote: post #57

Earlier quoted context omitted.

For grepping, rg is faster and saner. https://github.com/BurntSushi/ripgrep On end-user systems with fast I/O, it is usually a better use of resources to have a battery-/suspend-/reboot-aware indexing system that has path/extension white/blacklists and prioritizes file monitored changes. This way, searching can happen against an optimized text search DBMS much faster than waiting for zillions of IOPS that are basical…

Do either of these tools have a "grep" mode, so that I can alias grep to it and get similar, but improved, behavior? 25 years of habit is a lot of reinforcement to overcome and I'd love to just be able to take advantage of these tools with an alias. As is I just have a grep wrapping shell script to give it some sane defaults which works fairly well.

No, you're asking oranges to be bananas. Read the man page or user guide. It's not grep, it's better and already has saner defaults. https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md

Re: A common mistake involving wildcards and the find command

#65

Post by Izkata »

detaro wrote: post #55
derekp7 wrote: post #50

Earlier quoted context omitted.

xargs is also more efficient than -exec, as it stuffs multiple files to the target command. Esp. for rm, instead of executing a copy for each file.

doesn't -exec {} \+ do that too? (and we're back at the "remembering specific syntax" point: knowing xargs helps you everywhere)

Both of these are valid:

  -exec   {} +
  -exec   {}  \;
(The backslash is unnecessary for +)

The first one, the one used here, acts like xargs. The second one executes individually for each file found. Because the "+" version continually adds files to it, it must be last, but the "\;" version doesn't have that restriction since it's a single substitution. Just to be clear with an example:

  $ ls
  one  three  two
  $ find . -exec echo 11 {} 22 \;
  11 . 22
  11 ./two 22
  11 ./three 22
  11 ./one 22
  $ find . -exec echo 11 {} 22 +
  find: missing argument to `-exec'
  $ find . -exec echo 11 {} +
  11 . ./two ./three ./one
Most people seem to only learn one of them, even getting them mixed up. For example, I had learned the "\;" one and for years thought they both acted like that, with "+" simply being an alternate end-of-command identifier to avoid needing to escape the semicolon.

Re: A common mistake involving wildcards and the find command

#66

Post by eru »

weberc2 wrote: post #61
svnpenn wrote: post #16

As another user mentioned, many POSIX and/or GNU utilities havent aged well. I respect trying to stay portable, but peoples needs change over time and these tools simply havent kept up. Like the other user, I use Fd now instead: https://github.com/sharkdp/fd As well as Silver Searcher: https://github.com/ggreer/the_silver_searcher while Grep performance is pretty good, its also gotten pretty stale with regard to its…

In this case the shell hasn’t aged well. Besides the globing feature, the bash language is arcane and few can actually reliably write correct bash despite it being ubiquitous. Personally I would like to see a completely reimagined take on the shell.

Have you looked at powershell, scsh or fish?

Re: A common mistake involving wildcards and the find command

#67

Post by iudqnolq »

emmelaich wrote: post #48

Quiz; in any directory, full or empty I can run this command $ * and get * What allows me to do this? (the $ is the prompt, not what I typed)

You can't, at least on bash version 5.0.3(1)-release with the default config Ubuntu packages it with. After a lag I get the error `$folder_name$: command not found`

Re: A common mistake involving wildcards and the find command

#69

Post by [deleted] »

shmageggy wrote: post #33
joana035 wrote: post #28

The title seems a bit off since shell expansions and arguments has nothing to do with the find command. Both features are also often covered in entry level material for introduction to shell.

Well it seems the root of the problem is > * Most importantly, the 'find' command uses a different algorithm than shell globbing does when matching wildcard characters. More specifically, the find command will apply the search pattern against the base of the file name with all leading directories removed. This is contrasted from shell globbing which will expand the wildcard between each path component separately. Whe…

[deleted]

Re: A common mistake involving wildcards and the find command

#70

Post by Izkata »

shmageggy wrote: post #33
joana035 wrote: post #28

The title seems a bit off since shell expansions and arguments has nothing to do with the find command. Both features are also often covered in entry level material for introduction to shell.

Well it seems the root of the problem is > * Most importantly, the 'find' command uses a different algorithm than shell globbing does when matching wildcard characters. More specifically, the find command will apply the search pattern against the base of the file name with all leading directories removed. This is contrasted from shell globbing which will expand the wildcard between each path component separately. Whe…

That's just ignorance about find. The globbing works fine, they're just not doing the search they think they are - they seem to think "-name" acts like "-path":

  $ ls Foobar/
  one  three  two
  $ find . -path '*bar/t*'
  ./Foobar/two
  ./Foobar/three
Post reply on HN