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

91–100 of 148 posts

Re: A common mistake involving wildcards and the find command

#91

Post by siddharthgoel88 »

It is just awesome that I stumbled upon this post. I remember previously I had faced similar issue while running a command like

  find . -name *.gradle | blah blah
Instead of finding the root cause, I by-passed it by

  find . | grep "\.gradle" | blah blah
It just feels great to now connect the dot and know the real reason for the issue.

Re: A common mistake involving wildcards and the find command

#92

Post by emmelaich »

iudqnolq wrote: post #67
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`

I promise you you can, with a previous particular incantation.

Answer to come.

PS. the response is not important.

Re: A common mistake involving wildcards and the find command

#93

Post by ulrikrasmussen »

I believe that programming languages should never make the meaning of a program depend on the context in which it is executed. So many obscure bugs are directly caused by such behaviors. There should be exactly one possible interpretation for a given statement, and if that cannot be executed, then the program should abort. In this case, the glob should never have been passed on to find. It should either have expanded to the empty array, or failed.

Re: A common mistake involving wildcards and the find command

#94

Post by josteink »

mikenew wrote: post #73
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.

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

Re: A common mistake involving wildcards and the find command

#95

Post by sengstrom »

shmerl wrote: post #84

TL;DR: globbing kicks in before other things unless you turn it off like with single quotes: https://www.tldp.org/LDP/abs/html/globbingref.html Don't forget about globbing when making Bash scripts.

points for spelling globbing correctly :)

Re: A common mistake involving wildcards and the find command

#96

Post by tzs »

jolmg wrote: post #86
tzs wrote: post #83

Earlier quoted context omitted.

> Different shells have different globbing mechanisms. Why should all programs tie themselves to the mechanisms of any one particular shell? I don't think my proposal would do that. First, a clarification. When I said "For those from wildcard expansion, it would tell the program what the wildcard was" I meant the shell tells the program the full argument containing the wildcard, not just the wildcard part. E.g., if t…

Right now, programs receive a list of strings as their arguments. What would be a concrete proposal for this X-Y mapping, taking into account that a single Y results in multiple Xes? The calls of executables is done via this system call: int execve(const char * path, char * const argv[], char * const envp[]); How would you modify that system call signature to be able to carry that information? And what about how prog…

> What would be a concrete proposal for this X-Y mapping, taking into account that a single Y results in multiple Xes?

Two arrays:

1. An array of all the Ys.

2. An array with one entry for each X. If X came from shell wildcard expansion, this entry is the index into the first array of the Y whose expansion resulted in X. If X did not come from wildcard expansion, this entry is some magic value that cannot be mistaken for an index into the first array.

Pass these arrays in the environment. No need for any kernel or standard library or language runtime modification to support it.

Re: A common mistake involving wildcards and the find command

#97

Post by [deleted] »

tzs wrote: post #96
jolmg wrote: post #86

Earlier quoted context omitted.

Right now, programs receive a list of strings as their arguments. What would be a concrete proposal for this X-Y mapping, taking into account that a single Y results in multiple Xes? The calls of executables is done via this system call: int execve(const char * path, char * const argv[], char * const envp[]); How would you modify that system call signature to be able to carry that information? And what about how prog…

> What would be a concrete proposal for this X-Y mapping, taking into account that a single Y results in multiple Xes? Two arrays: 1. An array of all the Ys. 2. An array with one entry for each X. If X came from shell wildcard expansion, this entry is the index into the first array of the Y whose expansion resulted in X. If X did not come from wildcard expansion, this entry is some magic value that cannot be mistaken…

[deleted]

Re: A common mistake involving wildcards and the find command

#100

Post by DavidSJ »

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

The current behavior is not simple and consistent. If it were, then *.jpg would “expand” to the empty list of arguments, rather than remain unchanged, in the degenerate case of no match.
Post reply on HN