quot; == James Youngman writes:
JY> It's in the introduction.
JY> On Fri, Apr 21, 2023 at 12:32 AM Dan Jacobson wrote:
>>
>> No where in (info "(find) Top") is where to report bugs mentioned.
>> Please do like (info "(coreutils) Introduction")
No where in (info "(find) Top") is where to report bugs mentioned.
Please do like (info "(coreutils) Introduction") where they remember to
mention where to report bugs. Yes, it is mentioned on the findutils man
pages, but not findutils INFO.
If we read
(info "(coreutils) cat invocation")
we also get told about
(info "(coreutils) Common options")
But if we read e.g.,
(info "(find) Invoking xargs")
we never know about
(info "(coreutils) Common options")
even though they also apply.
So unlike cat, for xargs, even if the user has exhauste
(info "(find) Directories") says
-- Option: -maxdepth levels
Descend at most LEVELS (a non-negative integer) levels of
directories below the command line arguments. '-maxdepth 0' means
only apply the tests and actions to the command line arguments.
-- Option: -mindepth levels
info xargs says
'--max-chars=MAX-CHARS'
'-s MAX-CHARS'
Use at most MAX-CHARS characters per command line, including the
command, initial arguments and any terminating nulls at the ends of
the argument strings.
Mention that you mean bytes, not characters.
$ echo a 哇|xargs -s 8
xarg
> "BV" == Bernhard Voelker writes:
BV> WDYT?
Great.
On man find, the only line that talks about "symlinks" is
%Y File's type (like %y), plus follow symlinks: `L'=loop,
`N'=nonexistent, `?' for any other error when determining
the type of the symlink target.
All the many rest on that page call them symbo
Well the man page and INFO page say depreciated. So better clean them up.
P.S.,
$ xargs --help
-I R same as --replace=R
-i, --replace[=R]replace R in INITIAL-ARGS with names read
from standard input; if R is unspecified,
assume {}
...
Don't you want to mention one i
Well all I know is the whole idea of xargs is to *separate* the things
coming in into separate arguments.
So when the user uses -I, he expects it to just act the same, with the
extra feature being that he can now also put things into the beginning
or middle of lines, not just the ends.
Never in h
OK. Making it smarter for the special case would make it less efficient
for the general case.
BV> find does not have an idea what rmdir does, and that its logic requires
BV> depth-first search. Use -depth:
All I know is you need to document "in this case, find, for some reason,
needs to needlessly check the directory is still there after the command
it invokes exits, therefore one needs t
Please make this not make error messages.
# mkdir /tmp/nnn
# mkdir /tmp/nnn/ooo
# find /tmp/nnn -type d -ok rmdir {} \;
< rmdir ... /tmp/nnn > ?
< rmdir ... /tmp/nnn/ooo > ? y
find: ‘/tmp/nnn/ooo’: No such file or directory
# find /tmp/nnn -type d
/tmp/nnn
(The user cannot just use "-ok -delete.")
JY> Please feel that you should phrase your suggestion in the form of a patch.
I don't know what to write.
"Warning: whatever you feed in will become one argument glued together."
OK, but
'-I REPLACE-STR'
'--replace[=REPLACE-STR]'
'-i[REPLACE-STR]'
Replace occurrences of REPLACE-STR in the initial arguments with
names read from standard input. Also, unquoted blanks do not
terminate arguments; instead, the input is split at newlines on
Plus I'm not sure that
'-I REPLACE-STR'
'--replace[=REPLACE-STR]'
'-i[REPLACE-STR]'
Replace occurrences of REPLACE-STR in the initial arguments with
names read from standard input. Also, unquoted blanks do not
terminate arguments; instead, the input is
OK.
But I now "demand" that xargs add a --show-quoting or whatever argument,
so that --verbose, and -p, will now show
'xdotool' 'mousemove' '0 0' 'click' '1' 'mousemove' 'restore' ?...
vs.
'xdotool' 'mousemove' '0' '0' 'click' '1' 'mousemove' 'restore' ?...
for people who care about those details,
Proof that xargs prompts with the same string, but executes differently:
$ echo 0 0 | xargs -p -I{} xdotool mousemove {} click 1 mousemove restore
xdotool mousemove 0 0 click 1 mousemove restore ?...y
xdotool: Unknown command: 1
Run 'xdotool help' if you want a command list
$ echo | xargs -p xdoto
Interesting. Once find -ls hits the large file (.rar),
1053966 45284 -r--r--r-- 1 jidanni jidanni 46367774 Jul 12 2015
dongshi/JPGS/63-004-0164.jpg
1053957 55608 -r--r--r-- 1 jidanni jidanni 56940981 Jul 12 2015
dongshi/JPGS/58-055-140.jpg
1053965600 -r--r--r-- 1 jidanni
Looks good and thanks for the hard work.
As far as 60:40, the current behavior is in fact what the user usually
wants, so yes just document it.
> "JY" == James Youngman writes:
JY> Sounds good, please send a patch.
This needs two people, one technical expert to correctly reword it. (not
me). One dimwit (me) to see if what got reworded sounds good over the
phone (the two tin cans and string stretched between my ears :-) )
To increase the accessibility of the find man page and INFO file,
please change lines like
-newer file
File was modified more recently than file. If file is a symbolic
link and the -H option or the -L option is in effect, the modification time of
the file it points to is al
$ man find
-readable
Matches files which are readable. This takes into account access
control lists and other permissions
artefacts which the -perm test ignores. This test makes use of
the access(2) system call, and so can be
fooled by NF
find should have a -limit option:
$ find -limit 50
would be like
$ find | sed 50q
but without hoping that the pipe will stop it. Which is even more
important with -exec...
$ man find
-links n
File has n links.
Say hard links, like the Info page.
> "JY" == James Youngman writes:
JY> What is the use case answered by this command? To retrieve an
JY> arbitrary (though not random) selection of three results?
Just for a more efficient way than find ... | head -n ...
Gentlemen, just like the SQL language has a "LIMIT" operator, so also
does find need a -limit (and xargs a --limit) option.
You might ask can't one just use e.g.,
$ find|sed 3q
$ some_command|sed 3q|xargs ...
and e.g.,
$ find -print0 | perl -0nwe 'print; exit if $. == 3;' | xargs -0 ...
if needin
Thank you all for working on my idea.
As I am kind of busy, I will leave it all up to you to perfect it.
> "DRW" == Dale R Worley writes:
DRW> How about "-quit", which seems to be implemented in find 4.5.11?
OK. But the -exec documentation needs to be updated mentioning how one
could use -exec ... -o -quit to stop everything upon failures.
Gentlemen, wouldn't it be great if instead of
# find /mnt/usb/thumb/backups/ -mtime -4 -type f -exec cp -av {}
/jidanni/backups/ \;
'/mnt/usb/thumb/backups/root_bkp2016-05-10-08-22-18.bz2' -> '/jidanni/backups/'
cp: cannot create regular file '/jidanni/backups/': No such file or directory
'/mnt/u
> "BV" == Bernhard Voelker writes:
BV> Well, there are many possibilities, but there is already a way to
BV> to do it in xargs. So what would you want to achieve by saving a RET?
BV> I don't think it's about the wearing of the ENTER key on your keyboard?
Thank you. If there is a way to do
$
BV> Without RET, this would all be mangled and the commands would be
BV> unreadable on a terminal.
All I know is there could be an additional option added to switch it
into a mutt mail reader like mode just before waiting for each response,
wherein one character is read without waiting for a RET.
> "BV" == Bernhard Voelker writes:
BV> Although you're maybe right from the logical point of view, I'm not
BV> sure if 'xargs -p' is used often enough to warrant adding such an option
BV> to the code. The next user may then come and want to have yet another
BV> option like --interactive-assu
xargs has
-p, --interactive
Prompt the user about whether to run each command line and read
a line from the terminal. Only run the command line if the re-
sponse starts with `y' or `Y'. Implies -t.
But then one needs to enter y RET y RET y RET
OK no need to CC me any more about this. Thanks.
Repeated paragraph spotted:
8.2 Invoking 'locate'
=
locate [OPTION...] PATTERN...
For each PATTERN given 'locate' searches one or more file name
databases returning each match of PATTERN.
For each PATTERN given 'locate' searches one or more file name
databases ret
I don't know... I just thought that maybe it might be more efficient
than |sed NNq in some situations to make it worth it.
Perhaps a -limit option could be added to find.
Would find -limit 22 be much more efficient than find|sed 22q ?
J> find /var/cache/apt -name '*.deb' -cnewer $(find...
erg.. rather long
J> Perhaps something like -eval '[EMAIL PROTECTED] -gt [EMAIL PROTECTED]'
Hmmm,
find -eval '[EMAIL PROTECTED] -gt [EMAIL PROTECTED]' -print
Seems like you are on the right track for an enhancement.
>> One has to do
>> $ find -type f -exec find {} ! -anewer {} \;
J> Unless I am mistaken, "find foo ! -anewer foo" always succeeds unless
J> foo is touched during the execution of find.
-anewer file
File was last accessed more recently than file was modified.
Does find chang
One has to do
$ find -type f -exec find {} ! -anewer {} \;
because you haven't opened up restrictions on the use of {} to non
-exec, -ok usages:
$ find -type f ! -anewer {}
or maybe
$ find -type f ! -anewerself
if there are savings involved. Same for -cnewer.
_
Hurmpf, one must do man xargs to see what the short form of xargs
--interactive etc. is. Just saying xargs --help doesn't reveal the -p
correspondence.
___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findut
Ah, better yet would be xargs to add a flag to:
Wait till receiving an EOF on stdin before executing anything.
$ xargs -n 1
a
a
b
b
c
c
$ xargs -n 1 --wait-for-eof
a
b
c
^D
a
b
c
(I discovered the need when pasting more and more URLs into
$ xargs -n 1 wwwoffle-ls
)
_
One of the most frustrating things about xargs -n 1 was that as I was
adding input, I was getting output, jumbling the screen. I solved it
with e.g.,
$ xargs|xargs -n 1 command
You might want to make a note of it in the docs.
___
Bug-findutils mailing l
Well, I was just miffed that one can do
$ while cp -u ...
which in some situations will never stop.
J> why stop at one second? The MS-DOS FAT filesystem has a two-second
J> granularity
Ah, no wonder. Ok, --granularity=2...
___
Bug-findutils mailing li
Perhaps add a flag to cp, find, etc. to reduce time comparisons to
only one second granularity, as depending on the device mounted, or if
we have since rebooted, times that should be the same can be reported
back differently by the operating system.
Or at least add a warning on man and Info pages.
J> submit a patch to the gnulib maintainers. An additional possible
J> benefit could be that this change would probably also affect coreutils
J> (for example mv -i and cp -i).
My role is "to merely broach the subject". Whether or not and how to
add my creeping featurism to hence formerly trustwo
-ok should take, in addition to y, q: to quit, like ^C, and ?, to list choices.
Maybe even add an n, an alias for "".
___
Bug-findutils mailing list
Bug-findutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-findutils
48 matches
Mail list logo
