> On Oct 14, 2017, at 4:02 PM, Abel Abraham Camarillo Ojeda
> wrote:
>
> find . | grep something | more filters | perl -ne 'chomp; print
> "$_\0"' | xargs -0 ...
Nice! *Now* can we stop talking about it?
On Sat, Oct 14, 2017 at 12:02 PM, Raul Miller wrote:
> On Sat, Oct 14, 2017 at 10:26 AM, Marc Espie wrote:
>> the find -print0 / xargs -0 couple was designed to solve that problem
>> a long time ago in one specific case.
>
> I suppose the other angle to take would be the addition of a null
> deli
On Sat, Oct 14, 2017 at 10:26 AM, Marc Espie wrote:
> the find -print0 / xargs -0 couple was designed to solve that problem
> a long time ago in one specific case.
I suppose the other angle to take would be the addition of a null
delimiter option for other command line utilities.
Put differently
As Theo said already, the main issue there is that it's totally
non-standard, so you end up writing scripts that won't work
anywhere but on OpenBSD.
The problem you're trying to solve is quoting in shell.
It's basically broken by design. There will always be fun patterns
in names that do various f
"Andreas Kusalananda Kähäri" write:
>
> Another thing to avoid is having too exotic filenames.
Or always passing file names through vis(3) before writing them.
Though that's probably not as simple as it sounds.
--schaafuit.
On Sat, Oct 14, 2017 at 08:44:08AM +, Raul Miller wrote:
> On Sat, Oct 14, 2017 at 3:08 AM, Andreas Kusalananda Kähäri
> wrote:
> > find . -type f -mtime -1 \
> > -exec grep -q -E 'pattern1' {} ';' \
> > -exec shasum {} +
>
> That's cute, but it winds up spinning up a process for ever
On Sat, Oct 14, 2017 at 3:08 AM, Andreas Kusalananda Kähäri
wrote:
> find . -type f -mtime -1 \
> -exec grep -q -E 'pattern1' {} ';' \
> -exec shasum {} +
That's cute, but it winds up spinning up a process for every file
(actually, in your example, two processes for every file). I general
On Sat, Oct 14, 2017 at 1:08 AM, Philip Guenther wrote:
> You want a version of xargs that, instead of requiring special handling for
> 5 characters legal in filenames (quote, double-quote, backslash, space, tab,
> newline), will be completely unable to handle exactly one of those
> characters (ne
"Raul Miller" wrote:
>
> And if I search, I can find a tremendous variety of other elaborate
> approaches, including replacements for xargs. So it's not like this is
> not a real issue, nor is it like this isn't something that grows new
> handlings on an ongoing basis.
Unfortunately, especially i
On Fri, Oct 13, 2017 at 11:52:11PM +, Raul Miller wrote:
> On Fri, Oct 13, 2017 at 7:37 PM, edgar wrote:
> > Perhaps a real life example of what you have been doing with xargs before
> > and after your change would be helpful.
>
> That's tough, since when I was working on this issue I didn't
On Fri, Oct 13, 2017 at 5:14 PM, Raul Miller wrote:
> On Fri, Oct 13, 2017 at 6:14 PM, Theo de Raadt
> wrote:
> > If you want to add things to standardized utilities you need to
> > convince a large volume of people in the greater community
> >
> > Not me.
>
> Ok,
>
> Would you be open to a re-i
I think the "an exact problem" thing tends to be misleading for open
ended issues like this.
The while loop works (and I have used it), but can be tremendously
slow, depending on the command in question (and if you need xargs to
break up the command line, there tends to be a lot of work that needs
On Fri, 13 Oct 2017 18:03:59 -0400
Raul Miller wrote:
> "Because then you don't need xargs, normal tooling seperates each line
> into a seperate argv entry regardless of other spacing."
>
> If there's some existing way (portable or not) to build this kind of
> argv in a shell script - using newl
On Fri, Oct 13, 2017 at 6:14 PM, Theo de Raadt wrote:
> If you want to add things to standardized utilities you need to
> convince a large volume of people in the greater community
>
> Not me.
Ok,
Would you be open to a re-implementation of the gnu xargs -d option?
Quoting
https://www.gnu.org/
On Fri, Oct 13, 2017 at 7:37 PM, edgar wrote:
> Perhaps a real life example of what you have been doing with xargs before
> and after your change would be helpful.
That's tough, since when I was working on this issue I didn't have
time to think about xargs and now that I have time to think about
Perhaps a real life example of what you have been doing with xargs before and
after your change would be helpful.
>
> On Oct 13, 2017 at 5:03 PM,wrote:
>
>
> Portability? It does seem to me that the implementation should be portable.
> Then if someone needs it else
> It does seem to me that the implementation should be portable.
Wow, you don't get it.
You want to add a feature.
The someone will use the feature.
In a script intended to be portable.
But other systems won't have this feature
Therefore the script won't work.
That sucks.
If you want to add
Portability?
It does seem to me that the implementation should be portable. Then if
someone needs it elsewhere they can have it elsewhere. But I think
that that's more about pledge than anything else (strnsubst and
strtonum maybe deserving honorable mention).
Meanwhile, I guess this would also ne
> Ok, I am curious - what new problems would this create?
I explained in the first mail.
I do use xargs -0 almost habitually. That handles quoting issues and
space issues, but:
xargs -0 fails when I want to pipe the result of xargs through a
filter on the way to another xargs.
Meanwhile, tr fails when I do not know the relevant set of unused
characters (when just looking for them tak
Raul Miller writes:
> The problem here is that you currently can't get xargs to use newline
> as a separator without also getting spaces as a separator. This
> creates a variety of problems.
I see. I've always used -0 in this case, can't recall any times where
this didn't solve the problem. You
Er... aside from the broken patch problems, I mean.
:(
Once again, sorry about that.
--
Raul
--- xargs.c.orig2017-10-13 14:13:16.0 -0400
+++ xargs.c2017-10-13 15:16:16.0 -0400
@@ -65,7 +65,7 @@
static char **av, **bxp, **ep, **endxp, **xp;
static char *argp, *
Ok, I am curious - what new problems would this create?
Thanks,
--
Raul
On Fri, Oct 13, 2017 at 2:52 PM, Theo de Raadt wrote:
>> The problem here is that you currently can't get xargs to use newline
>> as a separator without also getting spaces as a separator. This
>> creates a variety of pro
That deals with some but not all problems.
It does deal with the spaces in file names problem.
Thanks,
--
Raul
On Fri, Oct 13, 2017 at 2:57 PM, Stefan Johnson
wrote:
> I'm at work at the moment, so I can't test this on my OpenBSD machine at
> home. However, have you tried setting IFS to a n
I'm at work at the moment, so I can't test this on my OpenBSD machine at
home. However, have you tried setting IFS to a new line prior to feeding
newline separated output to xargs?
IFS="
"
some_command_that_generates_multiple_lines | xargs -n 1 some_other_command
Understand that "xargs -0" from l
> The problem here is that you currently can't get xargs to use newline
> as a separator without also getting spaces as a separator. This
> creates a variety of problems.
But it creates lots of other problems when you propose an extension to
only one operating system's version of a utility.
I thi
The problem here is that you currently can't get xargs to use newline
as a separator without also getting spaces as a separator. This
creates a variety of problems.
Thanks,
--
Raul
On Fri, Oct 13, 2017 at 2:40 PM, Allan Streib wrote:
> Raul Miller writes:
>
>> Can someone explain to me why x
When our interpretation of the specification creates orders of
magnitude more problems than it solves, yes.
This should not in any way be construed as meaning that anything goes.
Thanks,
--
Raul
On Fri, Oct 13, 2017 at 2:45 PM, Theo de Raadt wrote:
>> (2) Given that POSIX is an incomplete s
> (2) Given that POSIX is an incomplete specification, why is POSIX the
> issue here?
What does 'incomplete specification' mean.
You mean incompatible extensions should be added, quite similar to the
damage bash creates in the ecosystem with it's incompatible extensions?
Raul Miller writes:
> Can someone explain to me why xargs(1) does not support using newline
> as a separators, when that is one of the most common unix separators?
Which xargs(1) are you talking about? From my 6.1 machine, man xargs
says:
The xargs utility reads space, tab, newline, and en
Ok, first off, I appreciate your having taken time to respond.
Especially given the bug I had in my suggested patch.
That said... two things I am missing here:
(1) How do I get access to that normal tooling from the shell command
line without xargs?
(2) Given that POSIX is an incomplete specific
Actually, that had a bug, which is maybe why I should have waited
before posting that question
if (zflag || (lflag && '\n'==ch))
The && bit should not be there. Probably best to go if (zflag ||
lflag) though changing == to != would guard against the possibility
that isblank would recognize line
> Can someone explain to me why xargs(1) does not support using newline
> as a separators, when that is one of the most common unix separators?
Because then you don't need xargs, normal tooling seperates each line
into a seperate argv entry regardless of other spacing.
You are proposing an incomp
Can someone explain to me why xargs(1) does not support using newline
as a separators, when that is one of the most common unix separators?
I'm pasting one potential approach to the end of this message. There's
a few issues that might be stalling points:
(*) which command line option to be used (
34 matches
Mail list logo
