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

121–130 of 148 posts

Re: A common mistake involving wildcards and the find command

#121

Post by heinrichhartman »

tyingq wrote: post #31
seiferteric wrote: post #9

This was obvious to me, but one version of this that surprised me is when using scp. If you glob a remote destination like "scp myserver:*.jpg ./" It will probably work! But how? Because the remote path will likely not match any local files and the path with the asterisk will be passed to scp and scp will do the globbing on the remote side.

I mostly use ssh and tar instead of scp, because I'm usually after more than one file. Like, "ssh remote 'cd /whatever; tar -cf - someglobpattern' | tar -xvf"

even better

    printf "" | ssh bash
or

    cat cmd.sh  | ssh bash
This passes all of stdin to the remote bash, avoiding any expansions happening on the local side entirely.

Re: A common mistake involving wildcards and the find command

#122

Post by pwdisswordfish2 »

wffurr wrote: post #24
kragen wrote: post #18

Earlier quoted context omitted.

Wouldn't you have the same problem with fd if you invoke it on unquoted globs? The problem is the semantics of the shell, not find.

Yes, but fd has implicit pattern matching without requiring the * character: Features: Convenient syntax: fd PATTERN instead of find -iname '*PATTERN*'

Seems a misfeature. Much of the time, I use find to look for files with a specific extension, which makes the trailing asterisk harmful.

Re: A common mistake involving wildcards and the find command

#123

Post by JosefAssad »

Hamuko wrote: post #115
JosefAssad wrote: post #114

Do people really use find like that to clean up source code? git clean -fxdn # review what would be deleted, then git clean -fxd

I do for .pyc files. find . -name "*.pyc" -delete

Is there a reason you prefer that rather than having something like

  *.py[cod]
in your .gitignore?

Re: A common mistake involving wildcards and the find command

#124

Post by fit2rule »

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 me, Silver Searcher often fails to find matches in files that 'grep' will, easily. I've not been able to determine why this is, but it happens often enough that I consider SS to be highly unreliable, even if its fast.

So, it seems that there are still some issues to be sorted here.

Re: A common mistake involving wildcards and the find command

#125

Post by choeger »

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…

I would argue that this case shows that the shell(s) have a problem with a feature being enabled by default. In hindsight it might have been smarter to put globbing expressions in special quotes than the other way round.

Re: A common mistake involving wildcards and the find command

#126

Post by mkl »

rezonant wrote: post #101
nothrabannosir wrote: post #38

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…

> this provides the same functionality as the c program in TFA, without needing gcc. or just using bash: function showargs() { for x in "$@"; do echo "arg: $x"; done }

I like it. I'm using a numbered version:

  function showargs() { i=1; for x in "$@"; do echo "arg $((i++)): $x"; done }

Re: A common mistake involving wildcards and the find command

#127

Post by johnp_ »

pwdisswordfish2 wrote: post #122
wffurr wrote: post #24

Earlier quoted context omitted.

Yes, but fd has implicit pattern matching without requiring the * character: Features: Convenient syntax: fd PATTERN instead of find -iname '*PATTERN*'

Seems a misfeature. Much of the time, I use find to look for files with a specific extension, which makes the trailing asterisk harmful.

    fd -e py
Also neatly bypasses the glob issue.

Re: A common mistake involving wildcards and the find command

#128

Post by mkl »

rootusrootus wrote: post #41

I almost appreciate the idea of writing a C program whose sole purpose is to show you the arguments send to it. That's some serious overkill. But I think echo *.py would not just be easier, but more effective at demonstrating what your find command line will actually look like after shell expansion.

That will be quite misleading when you have filenames with spaces and arguments with quotes.

Re: A common mistake involving wildcards and the find command

#129

Post by mkl »

jasonhansel wrote: post #37

This is the one thing I like about DOS/cmd.exe. In those shells, wildcard expansion is done by applications instead of the shell itself, so there's no need to resort to hacks like this.

That means the expansion is very limited and can be inconsistent. The bash etc. way is much more powerful and convenient.

Re: A common mistake involving wildcards and the find command

#130

Post by acqq »

tyingq wrote: post #22

Globbing is also more complex than it seems on first blush. Alternation is supported in bash. Stuff like "echo ∗.{png,jp{e,}g}" (utf8 asterisk to get around HN, cut/paste won't work). That bsd derived glob is useful for some sometimes useful tricks. Like in Perl: use File::Glob qw/bsd_glob/; my @list = bsd_glob('This {list|stuff} is nested {{very,quite} deeply,deep}');

> "echo ∗.{png,jp{e,}g}" (utf8 asterisk to get around HN, cut/paste won't work)

This works:

    echo *.{png,jp{e,}g}
Note

    ∗ ⟵ U+2217   * ⟵ needed ASCII asterisk
Just put the code examples in the separate lines, prefixed with spaces.
Post reply on HN