[bug #44221] Spurious warning about non-option arguments is spurious

Follow-up Comment #5, bug #44221 (project findutils): My expectation is that the warning's purpose is to make the user aware that there are some things that look like tests but are in fact options, and the user has most likely gotten that wrong. If the user writes "find -type f -mindepth 4 ...",

[bug #44221] Spurious warning about non-option arguments is spurious

Follow-up Comment #7, bug #44221 (project findutils): Given the existence of -o and !, it is not true that "everything after a dash is a filter that narrows down the scope of what find finds". That is the fundamental reason users have to be made aware of the proper use of options -- they don't wo

[bug #44078] Find fails if executed from a directory on which the user has no list permissions and exec is an option used

Follow-up Comment #5, bug #44078 (project findutils): If I follow this formula, I get the expected results in both instances. This is with version 4.5.11 on Fedora 19. $ mkdir /tmp/bug $ chmod a-r /tmp/bug $ cd /tmp/bug $ find /tmp $ find /tmp -exec echo '{}' ';' Can you try this method, so as

[bug #46815] problem when testing file size

Follow-up Comment #3, bug #46815 (project findutils): I have a very strong suspicion that the current code behaves "correctly", that is, in the way that "find" has always worked. The original -size meaning "Does the file occupy N (512-byte) disk blocks?". (Of course, usually people would use "-s

[bug #47261] find produces two different results for the same command

Follow-up Comment #6, bug #47261 (project findutils): You can strip the memory addresses from the traces (which vary) by doing: f1 f2 Then you can compare the traces directly with "diff -u f1 f2". Looking at the results of that, I see that the major difference is that find2 has a huge

[bug #47261] find produces two different results for the same command

Follow-up Comment #7, bug #47261 (project findutils): I wrote a script to determine what all the stat() calls are looking at, and it turns out my guess was wrong. There are a lot of files that find doesn't find, and I doubt it's because they're not in the filesystem. E.g., all of /etc is missing

[bug #46815] problem when testing file size

Follow-up Comment #6, bug #46815 (project findutils): There's no strong reason to add -filesize N because -size Nc has the same effect. The major reason would be if -size Nc is just too complicated for an ordinary user to figure out. ___

[bug #49640] Refer to numeric arguments as n|-n|+n or [-+]n instead of n in the manpages

Follow-up Comment #1, bug #49640 (project findutils): I heartily agree with this. The Gnu man pages are generally extremely accurate, and this change (especially if it includes the text change) is a significant improvement. ___ Reply to t

[bug #50058] [wishlist] -prune a subdir(tree) when a file therein matches criteria

Follow-up Comment #1, bug #50058 (project findutils): First, I think you need to define carefully the semantics of your proposal and consider its implications. As I read what you wrote, which files/directories are examined by find would depend on the order in which directories were examined. The

[bug #50058] [wishlist] -prune a subdir(tree) when a file therein matches criteria

Follow-up Comment #3, bug #50058 (project findutils): True, -depth causes the elements of a directory to be processed before the directory itself. But there's no specified way to affect the order in which the items in a directory are processed. I suspect this comes from the semantics of opendir/

[bug #42318] find with xdev traverses other filesystem when mountpiont is subdirectory

Follow-up Comment #3, bug #42318 (project findutils): My reading of the phrase "descend past" is that find will examine the directory itself but will not proceed "past" it. This depends on the detailed connotations of the word "past". And similarly I think the documentation in comment #1 has the

[bug #42318] find with xdev traverses other filesystem when mountpiont is subdirectory

Follow-up Comment #5, bug #42318 (project findutils): How does the (much simpler) # find /mnt -xdev -type d behave? ___ Reply to this item at: ___ Me

[bug #50606] Garbage printed with "no such file or directory"

Follow-up Comment #2, bug #50606 (project findutils): To be more exact, the two garbage sequences result from 'find' printing the Unicode characters "LEFT SINGLE QUOTATION MARK" (hex 2018) and "LEFT SINGLE QUOTATION MARK" (hex 2019) (see http://www.unicode.org/charts/PDF/U2000.pdf) by outputting t

[bug #42318] find with xdev traverses other filesystem when mountpiont is subdirectory

Follow-up Comment #8, bug #42318 (project findutils): I ran into this link to the Solaris man page for find, and it's clear that it's built on a different code base, because the description of -xdev is different: http://docs.oracle.com/cd/E19253-01/816-5165/6mbb0m9ft/index.html -xdev Same a

[bug #42318] find with xdev traverses other filesystem when mountpiont is subdirectory

Follow-up Comment #10, bug #42318 (project findutils): I wonder if the useful solution would be to define "-mount" to give the Solaris behavior, and "-xdev" to give the current behavior. ___ Reply to this item at:

[bug #50606] Garbage printed with "no such file or directory"

Follow-up Comment #4, bug #50606 (project findutils): As an aside, when garbage characters show up where text is expected, and especially if ordinary ASCII characters seem to be coming through OK, it's often worth checking whether you're seeing non-ASCII characters encoded with UTF-8. I wind up d

[bug #51151] [wishlist] xargs -o support for interactive commands

Follow-up Comment #3, bug #51151 (project findutils): I suggest this form as a workaround, particularly because it causes Emacs to see as stdin whatever the stdin in effect in the environment. I'm not sure there's a way that we could package that into an option for xargs, though. exec 3<&0 find

[bug #51151] [wishlist] xargs -o support for interactive commands

Follow-up Comment #4, bug #51151 (project findutils): I suppose we could define -Rn, --redirect-from=n Redirect stdin for each executed command from fd n. We could also do redirection from a file, and the user could use /dev/fd/n, etc. _

[bug #51220] [wishlist] Using -I with -n

Follow-up Comment #1, bug #51220 (project findutils): It would help if you simplified the example. In this case, make the variable substitutions. And instead of using "cp" as the command which is executed, thus showing us only the error message "cp" reports and leaving us to guess what the comma

[bug #51220] [wishlist] Using -I with -n

Follow-up Comment #2, bug #51220 (project findutils): The example doesn't seem to show that -I is incompatible with -n. Indeed 'one two three four' isn't split into four arguments, but the documentation for -I says that it won't: -I replace-str Replace occurrences of replace-str in the in

[bug #51345] find shows different results despite using same command

Follow-up Comment #6, bug #51345 (project findutils): I don't want to sound like a crank, but are you verifying that the files in question actually exist before you run find? I mean, before you run find the first time, are you doing "ls /lib/systemd" to verify that the directory is accessible whe

[bug #51711] non-helping error output with find

Follow-up Comment #1, bug #51711 (project findutils): Certainly the problem is real, but it's even more complicated. As far as I can tell, the error message means, "Syntactically, this is a situation where a predicate must occur, but this argument is not a predicate. It looks like what would hap

[bug #51926] -xtype l fails on symbolic links that have a loop

Follow-up Comment #3, bug #51926 (project findutils): The complexity is that "-xtype" isn't really defined for a looping link, because xtype is a test of *the thing at the end of the chain of links* (which doesn't exist). Actually, there's a similar problem with an ordinary broken link (which doe

[bug #51926] -xtype l fails on symbolic links that have a loop

Follow-up Comment #6, bug #51926 (project findutils): Re: "In fact the error can occur even when you wouldn't expect it due to find's arm-swapping optimizations:" That's actually a flat-out error; you shouldn't do optimizations that cause additional exceptions. _

[bug #52409] `find -print0 -name ...` ignores `-name ...`

Follow-up Comment #1, bug #52409 (project findutils): Actually, this is a usage error: -print is an action as well as a predicate. In particular, it takes effect when it is executed *in order* among the predicates. So if you execute find . -name '*.c' -print find will, for each file name, fir

[bug #52558] find does not print symlink object in case of follow symbolic links

Follow-up Comment #4, bug #52558 (project findutils): This is an odd case. But find . -type l -printf '%p -- %l\n' and find . -type l -printf '%p -- %l\n' -follow should always produce the same results, since -follow only affects things after it on the command line. But (with find 4.5.11), i

[bug #53075] FR: command line switch to make -ls print file names as-is

Follow-up Comment #2, bug #53075 (project findutils): I would never have expected that -ls automatically represents non-ASCII bytes as \nnn, because "ls" doesn't do that normally. If you want to reveal non-graphic characters, you have to use "ls -b". Though it's not clear to me that there's any

[bug #55443] False Info

Follow-up Comment #1, bug #55443 (project findutils): It's probably best to say "may need to be quoted". In fact, whether it needs to be quoted depends on the shell in question. And there are multiple shells. ___ Reply to this item at: