zargs doesn't work reliably

zargs doesn't work reliably

[Mikael Magnusson]

Usage: zargs [options --] [input-args] [-- command [initial-args]]

% touch -- -- -+
% zargs -- * -- ls -d
(eval):2: command not found: -+
% zargs * -- ls -d
ls: invalid option -- +
Try `ls --help' for more information.
% zargs * ls -d
-+ ls -d

since input-args is the only part you do not control, it should come
last, like so
Usage: zargs [options --] [command [initial-args]] -- [input-args]
A problem is how to give -- as initial-args then, maybe someone less
tired can come up with something?

-- 
Mikael Magnusson

Re: zargs doesn't work reliably

[Nikolai Weibull]

On 8/18/06, Mikael Magnusson <mikachu@gmail.com> wrote:
> Usage: zargs [options --] [input-args] [-- command [initial-args]]
>
> % touch -- -- -+
> % zargs -- * -- ls -d
> (eval):2: command not found: -+
> % zargs * -- ls -d
> ls: invalid option -- +
> Try `ls --help' for more information.
> % zargs * ls -d
> -+ ls -d
>
> since input-args is the only part you do not control, it should come
> last, like so
> Usage: zargs [options --] [command [initial-args]] -- [input-args]
> A problem is how to give -- as initial-args then, maybe someone less
> tired can come up with something?

Well, all you'd need to worry about is whether it's the first, second,
or third -- on the line.  Still, isn't doing something like

  % zargs ./* -- ls -d

easier than changing the semantics of zargs option-parsing?

  nikolai

Re: zargs doesn't work reliably

[Bart Schaefer]

On Aug 17,  3:59pm, Mikael Magnusson wrote:
}
} Usage: zargs [options --] [input-args] [-- command [initial-args]]
} 
} % touch -- -- -+

There are approximately eleventeen zillion unix/linux commands that
break given those file names, including rm, ls, and cp, so I'm not
going to get particularly worked up about zargs behaving similarly.
However, if you'd looked just a little further, you'd find that in
fact zargs already has a solution for this problem.  There is even
an example in the manual:

     In the event that the string `--' is or may be an INPUT, the -e
     option may be used to change the end-of-inputs marker.  Note that
     this does _not_ change the end-of-options marker.  For example, to
     use `..' as the marker:

          zargs -e.. -- **/*(.) .. ls -l

     This is a good choice in that example because no plain file can be
     named `..', but the best end-marker depends on the circumstances.

(End manual page example, begin new one.)  You can even do:

          zargs -e$'\0' -- * $'\0' ls -d

unless you somehow have a file named (the nul byte).

} since input-args is the only part you do not control

The only part who does not control?

} it should come last, like so
} Usage: zargs [options --] [command [initial-args]] -- [input-args]

I think the designers of the xargs command, after which zargs is closely
modeled, would disagree with you.  See "man xargs".

} A problem is how to give -- as initial-args then

Precisely.  Another problem is that the command and initial-args may be
omitted, but the input-args may not be.

Re: zargs doesn't work reliably

[Mikael Magnusson]

On 8/18/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 17,  3:59pm, Mikael Magnusson wrote:
> }
> } Usage: zargs [options --] [input-args] [-- command [initial-args]]
> }
> } % touch -- -- -+
>
> There are approximately eleventeen zillion unix/linux commands that
> break given those file names, including rm, ls, and cp, so I'm not
> going to get particularly worked up about zargs behaving similarly.

% ls -l -- *
-rw-r--r-- 1 mikaelh users 0 2006-08-18 00:55 -+
-rw-r--r-- 1 mikaelh users 0 2006-08-18 00:55 --

> However, if you'd looked just a little further, you'd find that in
> fact zargs already has a solution for this problem.  There is even
> an example in the manual:
>
>      In the event that the string `--' is or may be an INPUT, the -e
>      option may be used to change the end-of-inputs marker.  Note that
>      this does _not_ change the end-of-options marker.  For example, to
>      use `..' as the marker:
>
>           zargs -e.. -- **/*(.) .. ls -l
>
>      This is a good choice in that example because no plain file can be
>      named `..', but the best end-marker depends on the circumstances.
>
> (End manual page example, begin new one.)  You can even do:
>
>           zargs -e$'\0' -- * $'\0' ls -d
>
> unless you somehow have a file named (the nul byte).
>
> } since input-args is the only part you do not control
>
> The only part who does not control?

What i meant was it's the only part of the command that may contain
unplanned -- instances. Unless you also glob somewhere else in the
command... but that seems like a bad idea?

> } it should come last, like so
> } Usage: zargs [options --] [command [initial-args]] -- [input-args]
>
> I think the designers of the xargs command, after which zargs is closely
> modeled, would disagree with you.  See "man xargs".
>
> } A problem is how to give -- as initial-args then

Would this be possible?
zargs '[options]' 'command [initial-args]' [input-args]
ie the ' are literal quotes in the command so zargs knows exactly what
to do with the first two arguments (in which case you'd have to zargs
'' '' * if you wanted to omit them so maybe not aesthetically pleasing
in that regard).

> Precisely.  Another problem is that the command and initial-args may be
> omitted, but the input-args may not be.

Sorry, I should have looked in the manual. In my defense zargs --help
was so helpful that i didn't suspect it left anything useful out and i
did say i was tired :). Thanks for the pointers.

-- 
Mikael Magnusson

Re: zargs doesn't work reliably

[Vincent Lefevre]

On 2006-08-18 05:16:50 +0200, Mikael Magnusson wrote:
> On 8/18/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >(End manual page example, begin new one.)  You can even do:
> >
> >          zargs -e$'\0' -- * $'\0' ls -d
> >
> >unless you somehow have a file named (the nul byte).

AFAIK, a file name can't contain a nul byte (anyway this would break
many things, as the nul byte is the string terminator in C).

[...]
> Would this be possible?
> zargs '[options]' 'command [initial-args]' [input-args]
> ie the ' are literal quotes in the command so zargs knows exactly what
> to do with the first two arguments (in which case you'd have to zargs
> '' '' * if you wanted to omit them so maybe not aesthetically pleasing
> in that regard).

What if you need an initial-arg that contains a space?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: zargs doesn't work reliably

[Mikael Magnusson]

On 8/18/06, Vincent Lefevre <vincent@vinc17.org> wrote:
> On 2006-08-18 05:16:50 +0200, Mikael Magnusson wrote:
[...]
> > Would this be possible?
> > zargs '[options]' 'command [initial-args]' [input-args]
> > ie the ' are literal quotes in the command so zargs knows exactly what
> > to do with the first two arguments (in which case you'd have to zargs
> > '' '' * if you wanted to omit them so maybe not aesthetically pleasing
> > in that regard).
>
> What if you need an initial-arg that contains a space?

I don't quite understand the question... zargs '' 'touch file\ with\
spaces' /tmp/*
or zargs '' 'touch "file with spaces"' /tmp/*

-- 
Mikael Magnusson

Re: zargs doesn't work reliably

[Vincent Lefevre]

On 2006-08-18 15:12:42 +0200, Mikael Magnusson wrote:
> I don't quite understand the question... zargs '' 'touch file\ with\
> spaces' /tmp/*
> or zargs '' 'touch "file with spaces"' /tmp/*

OK, I must have mixed up with bash (where if you do
cmd='touch file\ with\ spaces', then $cmd, you get 3 files
"file\", "with\" and "spaces").

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: zargs doesn't work reliably

[Bart Schaefer]

On Aug 17,  8:17pm, Mikael Magnusson wrote:
}
} > There are approximately eleventeen zillion unix/linux commands that
} > break given those file names, including rm, ls, and cp, so I'm not
} > going to get particularly worked up about zargs behaving similarly.
} 
} % ls -l -- *

Yes, and you used an explicit "--" to tell ls that there might be "--"
in its argument list; it would have failed if you did not.  The same
goes for "zargs -e".

} Would this be possible?
} zargs '[options]' 'command [initial-args]' [input-args]

I'm not going to agree with you about any scheme that breaks congruence
with the way xargs accepts its command and initial-args.  The whole point
of zargs is to mimic xargs as closely as possible.

} Sorry, I should have looked in the manual. In my defense zargs --help
} was so helpful that i didn't suspect it left anything useful out and i
} did say i was tired :). Thanks for the pointers.

Thanks for the compliment about the help.  It does say fairly early:

Options:
--eof[=eof-str], -e[eof-str]
    Change the end-of-input-args string from "--" to eof-str.  If
    given as --eof=, an empty argument is the end; as --eof or -e,
    with no (or an empty) eof-str, all arguments are input-args.

On Aug 18,  6:12am, Mikael Magnusson wrote:
}
} > What if you need an initial-arg that contains a space?
} 
} I don't quite understand the question... zargs '' 'touch file\ with\
} spaces' /tmp/*
} or zargs '' 'touch "file with spaces"' /tmp/*

What if you have one initial-arg with a space, one with a backslash, one
with a single quote, and one with a double-quote?

The input-args already come to you "quoted" via the globbing mechansim.
It's much easier to pick something (including empty string, see the help
snippet above) that won't appear in the input-args than it is to quote
your way around oddities in the initial-args.

Re: zargs doesn't work reliably

[Mikael Magnusson]

On 8/18/06, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 17,  8:17pm, Mikael Magnusson wrote:
> }
> } > There are approximately eleventeen zillion unix/linux commands that
> } > break given those file names, including rm, ls, and cp, so I'm not
> } > going to get particularly worked up about zargs behaving similarly.
> }
> } % ls -l -- *
>
> Yes, and you used an explicit "--" to tell ls that there might be "--"
> in its argument list; it would have failed if you did not.  The same
> goes for "zargs -e".
>
> } Would this be possible?
> } zargs '[options]' 'command [initial-args]' [input-args]
>
> I'm not going to agree with you about any scheme that breaks congruence
> with the way xargs accepts its command and initial-args.  The whole point
> of zargs is to mimic xargs as closely as possible.
>
> } Sorry, I should have looked in the manual. In my defense zargs --help
> } was so helpful that i didn't suspect it left anything useful out and i
> } did say i was tired :). Thanks for the pointers.
>
> Thanks for the compliment about the help.  It does say fairly early:
>
> Options:
> --eof[=eof-str], -e[eof-str]
>     Change the end-of-input-args string from "--" to eof-str.  If
>     given as --eof=, an empty argument is the end; as --eof or -e,
>     with no (or an empty) eof-str, all arguments are input-args.

After reading this a couple of times and trying some different
commands i came up with this working command:
% zargs --eof= -- * '' ls -d --
--  -+

> On Aug 18,  6:12am, Mikael Magnusson wrote:
> }
> } > What if you need an initial-arg that contains a space?
> }
> } I don't quite understand the question... zargs '' 'touch file\ with\
> } spaces' /tmp/*
> } or zargs '' 'touch "file with spaces"' /tmp/*
>
> What if you have one initial-arg with a space, one with a backslash, one
> with a single quote, and one with a double-quote?
>
> The input-args already come to you "quoted" via the globbing mechansim.
> It's much easier to pick something (including empty string, see the help
> snippet above) that won't appear in the input-args than it is to quote
> your way around oddities in the initial-args.

I didn't mean to sound like the current way is wrong and i have all
the answers, although it might have sounded a bit like that; i just
meant to make suggestions or ask if things would work that way.
Thanks again for your helpful help, and in the meantime i have another
question :). (->new thread)

-- 
Mikael Magnusson