Live data from Hacker News

A common mistake involving wildcards and the find command

blog.robertelder.org

111–120 of 148 posts

Re: A common mistake involving wildcards and the find command

#111
Apparently, the OP read the man page of "glob" but couldn't spend a single minute reading the man page of FIND.

  -name pattern

    ... Don't forget to enclose the pattern in quotes in order to protect it from expansion by the shell.
So, a lengthy article on an already documented feature of find.

Re: A common mistake involving wildcards and the find command

#113
post #73

Earlier quoted context omitted.

> Smart case: the search is case-insensitive by default. It switches to case-sensitive if the pattern contains an uppercase character*. This is what I want as a default for pretty much any text search.

Emacs have had this since forever. It’s pretty neat.

Vim also provides it if you use:

  :set smartcase

Re: A common mistake involving wildcards and the find command

#116

My instant reaction to the example was “that won’t work; you’re shell will say something like ‘no matches’”. Using an unescaped star in a find command never works for me, which is a lot better than it sometimes working and sometimes breaking! Reading the article and the comments, it seems like bash doesn’t do this? I suppose it’s one nice thing about oh-my-zsh, whose default confit I use almost unchanged.

It's a default in zsh, nevermind oh-my-zsh.

Re: A common mistake involving wildcards and the find command

#118
post #75

Earlier quoted context omitted.

I have written hundreds of shell scripts, several which are hundreds of lines long. When I say they havent aged well, Im speaking from experience. When I use something like: find -name *.jpg I know what it actually does. But what it actually doesnt isnt what it should do. The current behavior returns matched files... unless no files match. Then it returns the literal string "*.jpg". That behavior is usually going to…

You completely ignored my point, which is that none of this behaviour should be surprising or unexpected to anyone who has taken the time to think about how it all works together, and that this flexibility is the inherent way in which the UNIX command line is so powerful. it going to fail if the variable has any spaces Quoting and escaping. I mentioned that already, it's a basic part of the understanding and is not s…

I almost never want the split-on-ifs-on-expansion behavior. That's one of the reasons I use zsh. When I want I can either use an array or $=SOMETHING.

The default split behavior basically forces you to always quote expansions which is tiresome. It also is confusing because almost no other programming language works like that.

And when you assigned SOMETHING you did wrote SOMETHING="foo bar" (with quotes) so it sorta makes sense visually also.

Re: A common mistake involving wildcards and the find command

#119

Tangential: another safeguard you can adopt is avoiding "hard delete" commands like rm and find -delete. Untrain yourself from these commands by never using them. On Mac systems, the "trash" program (brew install trash) sends files to your system trash. You can use `trash [file]` and `find .. -print0 | xargs -0 trash --`. rm is a dangerous command you should only very rarely be using. I fish something out of the tras…

No need for python, this works just as good:

    printf ":%s:" *foo

Re: A common mistake involving wildcards and the find command

#120
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…

As another user mentioned, many POSIX and/or GNU utilities havent aged well What do you mean by that? Users have gotten more stupid and uneducated over time? I've seen "when in doubt, escape it" in several books about UNIX and shell, and escapes and wildcard expansion are one of the most beginner lessons in a lot of other materials. However, the Internet has let everyone have a voice, for better or worse, and as a re…

I don't understand escaping properly.

Why, on some machines (all varying distros of Ubuntu) does

    find -name *.xml
return nothing and I have to use

    find -name '*.xml'
whilst on other machines the first command returns results? The shell is always bash, it's a stock install - so why the variation?

I get that it should always be quoted, but not why it sometimes works when unquoted and other times doesn't.

Post reply on HN