[bug #32976] find has no option to ignore case of starting directories

Follow-up Comment #5, bug #32976 (project findutils): [comment #1 comment #1:] > If I understand what you're asking for, this is what -iname does. > > /tmp$ touch x > /tmp$ find x -iname X > x > > If this isn't what you are interested in, could you be more specific? > I was asking for a case ig

Re: xargs - how to get it to execute input args as "the command"?

James Youngman wrote: You can use the "sh -c" trick to run the first argument as the command. Do you think the above case could be optimized? As I mentioned in my inital query, I wanted to avoid shell overhead on 80 thousand sub-jobs. I.e. is there any reason xargs couldn't run the a

xargs - how to get it to execute input args as "the command"?

I would have thought this to be the easiest case, Instead of reading in a line to use as an argument, or something to merge with a command, how can I get xargs just to execute the line read in as the command? I would have thought giving it -n1 -P12 and nothing else would have executed up to 12 pr

Regression: "find dir/. -type d -empty -delete" claims 'unsuccessful', breaking scripts.

In coreutils 8.21-7.1.3. It has been standard to use "." in a directory to mean it's contents on a recursive or copy (compare cp -al src/. dst/.). However, "find dir/. -type d -empty -delete" works, but exits with a failure code causing scripts to break. Surprisingly, if one could cd to the d

[bug #32976] find has no option to ignore case of starting directories

Follow-up Comment #4, bug #32976 (project findutils): > I don't really see these as being inconsistent; /some/path/some-basename is a > path name, and the named file either exists or it doesn't. It either exists in "some case" or not (on a case sensitive file system). > The test

Re: st_nlink=2 and no subdirs? isn't that normal?

James Youngman wrote: Could you supply a complete set of instructions for reproducing the problem, please? - I just saw this in the change log for 3.9.11 concerning CIFS: commit 44d244a13a27f0eb7b33bb152aa173c0e875df76 Author: Steve French Date: Thu Jul 4 14:38:48 2013 -0500 CIFS us

Re: st_nlink=2 and no subdirs? isn't that normal?

I have a Windows 7 workstation that has it's file system mounted on a gnu-linux based system with the cifs file system. I went to the root of that file system and did a find of some file name, like: find . -iname \*oem\* ... after it had been running for some time, (well over a minute), it d

st_nlink=2 and no subdirs? isn't that normal?

find: WARNING: Hard link count is wrong for `.' (saw only st_nlink=2 but we already saw 0 subdirectories): this may be a bug in your file system driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched. I had

[bug #32976] find has no option to ignore case of starting directories

Follow-up Comment #2, bug #32976 (project findutils): A starting path is one given on the command line telling find where to _start_ the search, i.e: the 'path' in: find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression] Ex: /tmp$ touch a /tmp$ find A find: `A': No such fil

[bug #32977] updatedb has no option to ignore case on filenames

URL: Summary: updatedb has no option to ignore case on filenames Project: findutils Submitted by: law Submitted on: Sat 02 Apr 2011 02:39:12 PM PDT Category: updatedb S

[bug #32976] find has no option to ignore case of starting directories

URL: Summary: find has no option to ignore case of starting directories Project: findutils Submitted by: law Submitted on: Sat 02 Apr 2011 02:25:46 PM PDT Category: find

Problem with using backslash to quote spaces in "--prunpaths"

Backslash doesn't seem to work correctly when quoting a space in the --prunepaths option. Backslash does properly quote a dollar sign, but if you enable the trace in updatedb, you'll see that it does something weird w/space, and instead adds a backslash before a quote, and still splits the f

Re: specifying case-ignore in updatedb & find.

There doesn't seem to be a way to specify paths in 'updatedb' to allow for case-insentive matching. Also, the in order for the problem to be solved completely, find has to be fixed as well. The part that would be, I think, updatedb-specific is the --prunepaths option. There needs to be an -

using updatedb on windows (under cygwin)...

For this to work reliable (ignoring conceptional subjectivity on windows), there really needs to be an option to ignore case for the arguments specified. While I can set something up on one machine that will work, if I move to another machine, the case may not be the same. Even on my own mac

[bug #30504] bug/rfe....the "-P" option seems to be unusable by itself

Follow-up Comment #5, bug #30504 (project findutils): That's the nature of the bug/comment. The -P option by it self is not usable. You don't need to do any work if you don't want to do it. I already have working code as the modification is trivial. I'm simple suggesting that the -P when used

[bug #30504] bug/rfe....the "-P" option seems to be unusable by itself

Follow-up Comment #3, bug #30504 (project findutils): 'if the input is sufficiently large'? In my case it would have to exceed 2MB of characters. In a practical sense that means it would never use more than one. Thus my assertion that the algorithm is flawed. If a user _uses_ -P by itself,

[bug #30504] bug/rfe....the "-P" option seems to be unusable by itself

Follow-up Comment #1, bug #30504 (project findutils): Is a patch needed to move this fix forward? ___ Reply to this item at: ___ Message sent via/by S

[bug #30504] bug/rfe....the "-P" option seems to be unusable by itself

URL: Summary: bug/rfethe "-P" option seems to be unusable by itself Project: findutils Submitted by: law Submitted on: Tue 20 Jul 2010 10:24:20 PM PDT Category: xargs