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
tag 29568 notabug
close 29568
thanks
On 12/04/2017 10:34 PM, f0rhum wrote:
> Hi
> find -version
> find (GNU findutils) 4.4.2
First of all, find(1) belongs to the "GNU findutils" rather than "GNU
coreutils".
==> CCing bug-findutils@gnu.org
> I issued this command to remove all files "*_original"
One way to phrase it is "Do you know how quoting works?"
If the shell sees an argument like "*.zip*" (the quotes are mine, not
part of the argument), then:
1) If expanding *.zip* finds one or more files, the shell changes the
argument into a series of arguments which are the names of the files.
There is kind of an error: The message "paths must precede
expression" does not really make sense. What is meant is "One of the
arguments that is part of the expression does not start with '-' like
it should. Perhaps it is the name of a path to search, but the paths
have to be before the express
On 10/24/2014 12:57 PM, Jan Meyer wrote:
> */xxx $ find /media/jm/Windows -name *.rar*find: paths must precede
> expression: logport.rar
Not a bug in find, but in your usage pattern. Try this in each
directory where you see different behavior:
echo find /media/jm/Windows -name *.rar
*find* is a Very mature utility, so finding a bug is VERY unlikely, then
again, I can't explain this behaviour:
*jm@amira ~/Desktop*
*/xxx $ find /media/jm/Windows -name *.zip*/media/jm/Windows/Program
Files/Arduino/drivers/Old_Arduino_Drivers.zip
/media/jm/Windows/Program Files/Arduino/java/lib/d
On Fri, Apr 9, 2010 at 11:19 AM, rre...@iol.it wrote:
> Hi,
>
> there seems to be a bug in the function parse_samefile() in find/parser.c...
> if I am not mistaken, after the call to collect_arg_stat_info(),
> argv[*arg_ptr] becomes NULL. I enclose a little patch to fix this problem.
>
Thanks
Hi,
there seems to be a bug in the function parse_samefile() in find/parser.c... if
I am not mistaken, after the call to collect_arg_stat_info(), argv[*arg_ptr]
becomes NULL. I enclose a little patch to fix this problem.
Roberto Reale
rre...@iol.it
--- findutils/find/parser.c 2010-04-05 13:18:
On 4/11/06, James Youngman <[EMAIL PROTECTED]> wrote:
On 3/31/06, James Youngman <[EMAIL PROTECTED]> wrote:
> On 3/28/06, James Youngman <[EMAIL PROTECTED]> wrote:
> > On 3/26/06, D Antryg M Revok <[EMAIL PROTECTED]> wrote:
> > > you /probably/ don't care, since it's been "good enough" for the GN
On 3/31/06, James Youngman <[EMAIL PROTECTED]> wrote:
> On 3/28/06, James Youngman <[EMAIL PROTECTED]> wrote:
> > On 3/26/06, D Antryg M Revok <[EMAIL PROTECTED]> wrote:
> > > you /probably/ don't care, since it's been "good enough" for the GNU
> > > tradition ( to be arbitrary and broken ) for yea
On 3/28/06, James Youngman <[EMAIL PROTECTED]> wrote:
> On 3/26/06, D Antryg M Revok <[EMAIL PROTECTED]> wrote:
> > you /probably/ don't care, since it's been "good enough" for the GNU
> > tradition ( to be arbitrary and broken ) for years, but incompetence is
> > incompentence.
> >
> > If I rig my
James Youngman wrote:
> Bob Proulx <[EMAIL PROTECTED]> wrote:
> > Subject: bug in FIND: argument list too damn long using -exec chmod 440
> > {} +
> >
> > But that should not suffer from an argument list too long problem.
> > The command is being execute
On 3/26/06, D Antryg M Revok <[EMAIL PROTECTED]> wrote:
> you /probably/ don't care, since it's been "good enough" for the GNU
> tradition ( to be arbitrary and broken ) for years, but incompetence is
> incompentence.
>
> If I rig my work to abuse all into obedience, everyone has the right to
> cal
On 3/28/06, Bob Proulx <[EMAIL PROTECTED]> wrote:
> Subject: bug in FIND: argument list too damn long using -exec chmod 440 {} +
>
> But that should not suffer from an argument list too long problem.
> The command is being executed one at a time for every matching file.
No, th
coreutils/faq/
Perhaps you should consider using a kernel without an ARG_MAX
limitation. If I recall correctly Hurd, the GNU kernel, does not
suffer from an arbitrary ARG_MAX limitation.
Third, is there a bug report in your message? I read the subject of
your message:
Subject: bug in FIND: argume
you /probably/ don't care, since it's been "good enough" for the GNU
tradition ( to be arbitrary and broken ) for years, but incompetence is
incompentence.
If I rig my work to abuse all into obedience, everyone has the right to
call-me on it, and some programmers have similar integrity-values.
On Wed, Feb 23, 2005 at 03:58:21AM +0100, Mave wrote:
> Hello,
>
> i have a problem (it seems to be a bug) by using GNU find
> version 4.1.7 on a Debian 3 Woody with Pinning (Unstable/Testing)
Please note that the current stable release of findutils is 4.2.18.
> I want to find files named *.cfg
Hello,
i have a problem (it seems to be a bug) by using GNU find
version 4.1.7 on a Debian 3 Woody with Pinning (Unstable/Testing)
I want to find files named *.cfg or *.ini. The documentation
(man find) shows me to use the syntax below
find . -name '*.cfg' -or -name '*.ini'
this works fine
25 matches
Mail list logo
