As OP:
that was only simplification, to make example clear enough.
In my usage scenario, I need to match whole file path.
I will probably have to switch to C locale and recode "find" output .
But I still think "find" needs that enhancement.
At least clear and loud warning in man page ...
Regards
Bernhard Voelker writes:
> As the OPs case just needs matches for the suffix of the basename,
> I'd personally always go with good old -name:
>
> find htdocs -type f -name '*.exe'
Yes. I would use -iname, because I'm unsure of what rules Windows uses
to decree a file as executable.
Dale
On 12/21/2017 01:12 PM, Dale R. Worley wrote:
Yes, this is one of those situations where you have to define very
exactly what it is that you're trying to do. In the case of the OP, the
question is really whether the final four octets of the file name are
'.exe' regardless of what the preceding o
Eric Blake writes:
> POSIX says that regex only has to match characters (in particular, the
> glob '.' matches characters, not encoding errors). If you pick a locale
> with multibyte characters that are subject to encoding errors when
> processing random bytes (as is the case when using a UTF-
I think, PCRE does not have this problem.
What about implementing '-regextype pcre' ?
Dou You think it's a good idea?
Regards,
2017-12-19 23:01 GMT+01:00 Piotr Gackiewicz :
> So, if it's by-design, users should be explicitly warned in man page:
>
> Do not rely on -regex, you could miss some badl
On 12/19/2017 03:31 PM, Bernhard Voelker wrote:
The test case in your attachment is a bit different, but also shows
the problem. It seems that gnulib's regex does not find a match for
the pattern '.*\.exe$' for the files in the following directory:
$ LC_ALL=C /usr/bin/ls -log htdocs
...
On 12/18/2017 04:06 PM, Piotr Gackiewicz wrote:
Hello,
I have spotted bizarre bug in gnu find.
In some circumstances, find result on '-regex' search is very dependendant
on locale settings.
I have attached a zip file, with example file tree. There are two
directories in it, one's name encoded w
I have missed info on versions.
I have tested in on:
find 4.7.0-git, libc6-2.23-0ubuntu9 (Ubuntu 16.04, x86_64)
find 4.4.2, glibc-2.12-1.209.el6_9.2.x86_64 (CentOS 6, x86_64)
Same results.
Regards,
2017-12-18 16:06 GMT+01:00 Piotr Gackiewicz :
>
> Hello,
>
> I have spotted bizarre bug in gnu
