[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bizzare bug in find, potential security implications
From: |
Piotr Gackiewicz |
Subject: |
Re: Bizzare bug in find, potential security implications |
Date: |
Fri, 22 Dec 2017 16:10:41 +0100 |
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,
2017-12-21 16:22 GMT+01:00 Bernhard Voelker <address@hidden>:
> 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 octets are. In that case, you
>> want LC_ALL=C to prevent the software from trying to be clever about
>> character strings:
>>
>> $ LC_ALL=C find htdocs -type f -iregex '.*\.exe$'
>>
>
> 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'
>
> Have a nice day,
> Berny
>
--
Piotr Gackiewicz
- Bizzare bug in find, potential security implications, Piotr Gackiewicz, 2017/12/18
- Re: Bizzare bug in find, potential security implications, Piotr Gackiewicz, 2017/12/18
- Re: Bizzare bug in find, potential security implications, Bernhard Voelker, 2017/12/19
- Re: Bizzare bug in find, potential security implications, Dale R. Worley, 2017/12/21
- Re: Bizzare bug in find, potential security implications, Bernhard Voelker, 2017/12/21
- Re: Bizzare bug in find, potential security implications, Dale R. Worley, 2017/12/22
- Re: Bizzare bug in find, potential security implications,
Piotr Gackiewicz <=