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

71–80 of 148 posts

Re: A common mistake involving wildcards and the find command

#71

Post by coolreader18 »

tzs wrote: post #26

For a long time (probably since the first time I forgot to quote something and got burned, so around 40 years), I've thought that there should be some mechanism for the shell to pass in information about how each argument came about. For each argument, it would tell the program if it was supplied directly, or came from wildcard expansion. For those from wildcard expansion, it would tell the program what the wildcard…

I'm not sure why people are saying it would make executables harder to write; it could most easily be done with environment variables as opposed to modifying the signature of `int main()`. Something along the lines of: `GLOBLESS_ARGC=5` means that `GLOBLESS_ARG{0..4}` have the original arguments as supplied by the shell user.

Re: A common mistake involving wildcards and the find command

#72

Post by JulianWasTaken »

icebraining wrote: post #46
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…

Trash is the poor man's backup system.

You use trash and backups.

Rich men can still save a few dollars for pocket change.

Re: A common mistake involving wildcards and the find command

#73

Post by mikenew »

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…

> 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.

Re: A common mistake involving wildcards and the find command

#74

Post by userbinator »

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…

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 result anyone who barely knows something can now write a misguided "tutorial" about it.

In other words: don't blame the tools, nor advocate writing dumbed-down replacements which lack the composability and generality the originals had; blame the proliferation of barely-correct educational material that has spread cancerously over the Internet.

Re: A common mistake involving wildcards and the find command

#75

Post by svnpenn »

userbinator wrote: post #74
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…

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 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 be desired by no one. Same with:

    grep $SOMETHING
it going to fail if the variable has any spaces. Again something most people arent going to want. These both can be worked around with Shell options and "IFS" respectively, but people shouldnt have to do that. The default behavior should be sane, but in many cases the POSIX standard isnt that. For goodness sake, the "venerable" find tool doesnt even have a "maxdepth" option:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/f...

Re: A common mistake involving wildcards and the find command

#76

Post by svnpenn »

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…

Yeah and its also 10 times larger

https://github.com/BurntSushi/ripgrep/issues/1481

Re: A common mistake involving wildcards and the find command

#78

Post by detaro »

svnpenn wrote: post #76
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…

Yeah and its also 10 times larger https://github.com/BurntSushi/ripgrep/issues/1481

the previous issue on the topic has some pointers

Re: A common mistake involving wildcards and the find command

#79

Post by dharmab »

svnpenn wrote: post #76
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…

Yeah and its also 10 times larger https://github.com/BurntSushi/ripgrep/issues/1481

Which is absolutely a good trade-off for a modern desktop system.

Re: A common mistake involving wildcards and the find command

#80

Post by CGamesPlay »

School-Cotton wrote: post #30

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.

Ditto, fish shell also provides this behavior in the default config.
Post reply on HN