<div dir="ltr"><div>Thanks for the explanations!<br></div><div>Now I understand.<br>I thought it was related to the search results somehow...<br>
 I didn't consider the local argument expansion.

<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-02-08 5:23 GMT+01:00 Robert Thompson <span dir="ltr"><<a href="mailto:robertt.thompson@gmail.com" target="_blank">robertt.thompson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is because the wildcard argument to -iname needs *not* to be<br>
expanded by the shell. It needs to be passed to find as a literal<br>
unexpanded string still containing wildcards. Usually this means<br>
single-quoting.<br>
<br>
for example,<br>
find . -iname '*data'<br>
<br>
<br>
<br>
<br>
The -iname takes a single argument, and if the *shell* expands the<br>
wildcard, the arguments find sees will be out of sync with<br>
expectations, resulting in an unexpected argument, or even unintended<br>
side effects, if the wildcard matched a file named '-delete' or<br>
something...<br>
<br>
<br>
one easy way of debugging this general kind of error is to add echo to<br>
the front of your commandline, so you can see the results.<br>
<br>
find . -iname '*.foo'<br>
<br>
becomes<br>
<br>
echo find . -iname '*.foo'<br>
<br>
if it prints<br>
<br>
find . -iname *.foo<br>
<br>
everything is good. If it prints<br>
<br>
find . -iname a.foo b.foo c.foo<br>
<br>
you have a problem. In most cases double quotes are okay, but single<br>
quotes are safe.<br>
<br>
Imagine someone really hates you and creates a filename that is<br>
literally $( rm -rf ${HOME} ) or something similar. doublequoted, the<br>
shell will still execute the rm so that it can expand the $( )<br>
variable with the stdout of the rm. Singlequoted, no expansion occurs.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 2/7/18, darken <<a href="mailto:darken@darken.eu">darken@darken.eu</a>> wrote:<br>
> I just noticed the following find applet behavior with regards to<br>
> wildcards.<br>
> I don't think it's a bug as it shows in all find applets, but I'm puzzled<br>
> by what is happening.<br>
><br>
> It seems that when using wildcards and the search results contain a<br>
> wildcard match that contains a dash, then find uses the result as argument<br>
> option? Why?<br>
><br>
> ~Matthias<br>
><br>
> ```<br>
> sailfish:/sdcard $ find --version<br>
> toybox 0.7.4-android<br>
> sailfish:/sdcard $ find . -iname *data<br>
> find: bad arg 'sleep-data'<br>
> 1|sailfish:/sdcard $ find . -iname "*data"<br>
> ./Android/data<br>
> ./data<br>
> ./sleep-data<br>
> ./Documents/sleep-data<br>
> sailfish:/storage/emulated/0 # find . -iname *droid<br>
> ./Android<br>
><br>
><br>
> sailfish:/storage/emulated/0 # /data/local/tmp/busybox-armv6l find . -iname<br>
> *data<br>
> find: unrecognized: sleep-data<br>
> BusyBox v1.26.2 (2017-01-11 08:43:16 UTC) multi-call binary.<br>
><br>
><br>
> darken@greendns:~/test$ find --version<br>
> find (GNU findutils) 4.7.0-git<br>
> darken@greendns:~/test$ mkdir -p Android/data<br>
> darken@greendns:~/test$ mkdir data<br>
> darken@greendns:~/test$ mkdir sleep-data<br>
> darken@greendns:~/test$ mkdir -p Documents/sleep-data<br>
> darken@greendns:~/test$ find . -iname *data<br>
> find: paths must precede expression: sleep-data<br>
> ```<br>
><br>
</div></div></blockquote></div><br></div>