Follow-up Comment #4, bug #66568 (group findutils):
Thanks for merging.
I think it would be good if the status of `/` in -execdir could be clarified
before a release is made with my documentation patch, because now we in
principle "promise" that it's the way as documented and people may actually
Follow-up Comment #2, bug #66568 (group findutils):
I'd have attached a patch fir git am, which would add a small sentence for
both, manpage and tex doc (I don't have tex installed, and was too lazy to do
it... so please check whether my markup there is right).
This only documents the behaviour f
ussion Lock: Any
Release: None
Fixed Release: None
___
Follow-up Comments:
---
Date: Tue 17 Dec 2024 01:53:21 AM UTC By: Christoph Anton Mitterer
Hey.
I hop
Hey.
On Fri, 2024-12-13 at 23:05 +0100, Bernhard Voelker wrote:
> I never saw a practical example why it would be dangerous.
Well it seems to me, that in that case even a 1 in Million chance might
have too catastrophic consequences to wait for it happening in the
wild.
Again, consider the find
Hey Bernhard.
An update on this:
POSIX guys pointed me to:
https://austingroupbugs.net/view.php?id=1872#c6956
That will still leave it as "allowed" for an implementation to take a
final non-terminated "line" as input, but still recommends against
doing so and still indicates the future direction
On Mon, 2024-12-09 at 21:00 +0100, Bernhard Voelker wrote:
> The above test case can be simplified to the cases:
>
> $ printf 'hello' | xargs -0 printf "<%s>\n"
>
>
> $ printf 'hello\0' | xargs -0 printf "<%s>\n"
>
>
> $ printf 'hello\0world' | xargs -0 printf "<%s>\n"
>
>
Hey.
Not sure whether this has been brought up before (at least a quick
search didn't reveal anything in the bug tracker or the archive).
xargs -0 still executes the command even when no terminating NUL has
been found in the (last) line.
As shown by e.g. the following script foo.sh:
#!/bin/sh
Follow-up Comment #7, bug #64816 (project findutils):
> well, you were asking for a GNU extension as well ...
Arguably, but at least in the GNU world, there is only one find implementation
used (though there are other program like fd, which do something similar),
while there are many different s
Follow-up Comment #4, bug #64816 (project findutils):
> Actually, NUL-terminated processing is the safest way of
> file name processing with tools in shells
Yes, but most of the POSIX shell and utilities have no support for printing or
reading NUL delimited, it's only GNU extensions (well there
Follow-up Comment #2, bug #64816 (project findutils):
Oh and just for the records:
If I'm not mistaken, bash's implementation of `%q` in its `printf` builtin can
be found at:
https://github.com/bminor/bash/blob/ec8113b9861375e4e17b3307372569d429dec814/builtins/printf.def#L595-L644
with the actua
Follow-up Comment #1, bug #64816 (project findutils):
Maybe it would also make sense to add the same functionality to xargs.
The idea is, that (POSIX compatible) shells don't work very well with NULL
delimited output.
If some program produces such, it's output could be piped into xargs -0 ...
an
n Lock: Any
Fixed Release: None
___
Follow-up Comments:
---
Date: Thu 26 Oct 2023 02:56:27 AM UTC By: Christoph Anton Mitterer
Hey.
The manpage says:
-printf, -fprintf
Hey.
With findutils 4.9.0 the following happened.
I have some directory tree with maps from dives sites looking like:
$ tree -d
…
├── Tauchplätze
│ ├── Bearbeitet
│ ├── Safari2012 - Südtour Beschriftet
x│ └── صور لنشات
…
(I've inserted the x just to prevent some right-to-left-issues. Remov
13 matches
Mail list logo
