Brian Somers [EMAIL PROTECTED] wrote:
If I'm not mistaken, the size of the environment is already
taken into account by the xargs utility (subtracted from
ARG_MAX). So this isn't an issue at all.
Unless xargs runs a command with lots of arguments and that command
increases the
Garance A Drosihn [EMAIL PROTECTED] writes:
At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
Does that mean everyone is blind and missed my arrogant
cross-post of the amazingly short patch to do this, or
are we just interested in discussing it and not testing
the implementation? ;-)
Well,
No rain here, it is ARG_MAX - 2048:
-s size
Set the maximum number of bytes for the command line length pro-
vided to utility. The sum of the length of the utility name and
the arguments passed to utility (including NULL terminators) will
Rodney W. Grimes [EMAIL PROTECTED] wrote:
Before anyone starts writing scripts, consider that {} will be
replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
stuff coming off the pipe. If your combined arguments plus
environment exceeds ARG_MAX execve(2) will give
Rodney W. Grimes [EMAIL PROTECTED] wrote:
Before anyone starts writing scripts, consider that {} will be
replaced by xargs with (roughly) ARG_MAX - 10 characters worth of the
stuff coming off the pipe. If your combined arguments plus
environment exceeds ARG_MAX execve(2) will
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
Sorry for butting in. Adding new non-portable functionality to solve the problem
which could be adequitely taken care of using existing and well known
techniquies is not appropriate, I completely agree with you on that.
And
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
Sorry for butting in. Adding new non-portable functionality to solve the problem
which could be adequitely taken care of using existing and well known
techniquies is not appropriate, I completely agree with you on that.
And I'm
On Sun, 22 Apr 2001 13:16:31 +0100, Brian Somers wrote:
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
Sorry for butting in. Adding new non-portable functionality to solve the
problem
which could be adequitely taken care of using existing and well known
techniquies is not
Brian Somers([EMAIL PROTECTED])@2001.04.20 11:29:15 +:
find something | xargs cp {} target_directory
or
find something | xargs -i '[]' cp '[]' target_directory
or
find something -exec cp {} target_directory \;
from find(1):
-exec utility [argument ...];
True if
rohrbach@WM:datasink[~]68% tar cf /dev/null src/
rohrbach@WM:datasink[~]69% find src|wc -l
2552
rohrbach@WM:datasink[~]70% du -sk src
32258 src
rohrbach@WM:datasink[~]71% mkdir src2
rohrbach@WM:datasink[~]72% time find src -exec cp {} src2 \;
find src -exec cp {} src2 ; 0.31s user 7.55s
At 1:19 PM -0700 4/21/01, Dima Dorfman wrote:
Does that mean everyone is blind and missed my arrogant
cross-post of the amazingly short patch to do this, or
are we just interested in discussing it and not testing
the implementation? ;-)
Well, I'm in the middle of a massive reorganization of
all
On Sun, 22 Apr 2001 13:16:31 +0100, Brian Somers wrote:
On Sat, 21 Apr 2001 20:04:31 +0100, Brian Somers wrote:
Sorry for butting in. Adding new non-portable functionality to solve the
problem
which could be adequitely taken care of using existing and well known
techniquies is
I don't see a problem with adding an option to cp to treat the first
argument as the target instead of the last argument. It's a simple
solution, the code change is simple, and it produces the exact desired
result. What's the problem?
It's yet another non-portable option.
I
On Fri, Apr 20, 2001 at 03:14:10PM -0700, Mike Smith wrote:
#
# Folks,
#
# although there was much rejoicing, I think there's no need for a
# new option to cp. Just use the toolbox, it's not too hard:
#
# (cat bigfilelist; echo destdir) | xargs cp
#
# Or even
#
# echo destdir
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote:
(cat bigfilelist; echo destdir) | xargs cp
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows the unix principle of
using simple tools and glueing them
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
Ciao,
Sheldon.
To Unsubscribe:
Jens Schweikhardt [EMAIL PROTECTED] wrote:
You mean if bigfilelist list exceeds the -n limit of xargs (default 5000)?
Yes, you'll be surprised then. It was a bit of POLA violation for me when I
found xargs would by default use 5000 arg chunks and not all in one go.
I'd rather get rid of
Sheldon Hearn [EMAIL PROTECTED] wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
That can
On 21-Apr-2001 Sheldon Hearn wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the
Your comments have nothing to do with the issue at hand. Just wrap the
first argument to cp in double-quotes, i.e.
cp "$i"
The point is, why bastardize tools to cope with areas beyond their
focus and well within the focus of other tools?
Ciao,
Sheldon.
Sorry for butting in.
Sheldon Hearn [EMAIL PROTECTED] wrote:
On Sat, 21 Apr 2001 16:51:24 +0200, Oliver Fromme wrote:
That can overflow your shell's command line limit (at the
"for" command). True, our /bin/sh doesn't has such a
limit, AFAIK, but there _are_ shells that do).
That's actually my point.
On Sat, 21 Apr 2001 17:27:04 +0200, Oliver Fromme wrote:
Not all users use /bin/sh. Scripts needn't be written
in /bin/sh, and xargs can be used interactively, too (I
use it a lot). Just because _our_ xargs works fine with
_our_ /bin/sh doesn't mean there is no problem.
So we have two
From: Oliver Fromme [EMAIL PROTECTED]
Subject: Re: cp -d dir patch for review (or 'xargs'?)
Date: Sat, 21 Apr 2001 17:27:04 +0200 (CEST)
Not all users use /bin/sh. Scripts needn't be written
in /bin/sh ...
Actually, just to jump in and correct this, scripts *should* be
written in /bin/sh
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
What's all the fuss about?
Have you tried that for
Jordan Hubbard [EMAIL PROTECTED] wrote:
From: Oliver Fromme [EMAIL PROTECTED]
Not all users use /bin/sh. Scripts needn't be written
in /bin/sh ...
Actually, just to jump in and correct this, scripts *should* be
written in /bin/sh.
It depends.
I often happen to write zsh scripts,
And to come back on topic: Portable scripts also should
_not_ assume that there are no limits on the length of
shell commands. On the other hand, portable scripts can
legitimately assume that xargs supports -i and -I, which
ours doesn't.
Agreed on both counts. I guess we should fix that.
On Sat, 21 Apr 2001, Brian Somers wrote:
On Sat, 21 Apr 2001 14:06:04 +0100, Brian Somers wrote:
How do you do this in a script:
cd /topdir; find . -type f | xargs -i {} cp {} /otherdir/.
for i in `find /path/to/source -type f`; do
cp $i /path/to/dest/
done
Jordan Hubbard [EMAIL PROTECTED] writes:
And to come back on topic: Portable scripts also should
_not_ assume that there are no limits on the length of
shell commands. On the other hand, portable scripts can
legitimately assume that xargs supports -i and -I, which
ours doesn't.
On Sat, Apr 21, 2001 at 05:34:31PM +0200, Sheldon Hearn wrote:
So we have two problems:
1) Calling cp(1) repetitively is inefficient.
2) The argument list is too big for cp(1).
Extending cp(1) will not solve (2). Extending xargs(1) will solve both.
So why is an extension to cp(1)
Brian Dean [EMAIL PROTECTED] wrote:
But extending cp does solve the problem.
Only for cp. It wouldn't solve the problem for mv, ln and
a bunch of other tools. Fixing it at _one_ place in xargs
would solve all of that without touching a dozen tools.
[...]
This makes cp work with xargs;
So we have two problems:
1) Calling cp(1) repetitively is inefficient.
2) The argument list is too big for cp(1).
Extending cp(1) will not solve (2). Extending xargs(1) will solve both.
So why is an extension to cp(1) being proposed?
I wasn't proposing that cp should be changed - I
Dima Dorfman [EMAIL PROTECTED] wrote:
I don't have a copy of SuSv2 or anything else that defines -I and -i,
http://www.secnetix.de/~olli/susv2/xcu/xargs.html
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
Not exactly. The difference is that the
I looked at your patches and immediately thought ``these patches
can't be right'' as I was expecting it to deal with things such as
xargs -I [] echo args are [], duplicated are []
I'm also dubious about the patches working for large volumes on
standard input. At this point I scrapped the
Putting that option into cp seems rather GNUish to me, but
not very UNIXish. :-)
Yes. I think most people agree that changing cp is not good.
Just my 2 Euro cents.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH Co KG, Oettingenstr. 2, 80538 Mnchen
Any opinions expressed in
Dima Dorfman [EMAIL PROTECTED] wrote:
I don't have a copy of SuSv2 or anything else that defines -I and -i,
http://www.secnetix.de/~olli/susv2/xcu/xargs.html
but from what I can gather, -i is the same as "-I {}" and -I allows
things like this:
Not exactly. The difference is
Brian Somers [EMAIL PROTECTED] writes:
I looked at your patches and immediately thought ``these patches
can't be right'' as I was expecting it to deal with things such as
xargs -I [] echo args are [], duplicated are []
It deals with it. It conveniently ignores the second '[]' :-).
If you just want an xargs that supports --replstr/-i simply
install:
ftp://ftp.gnu.org/gnu/findutils
or even more easily:
/usr/ports/misc/findutils
two comments:
I don't want to enter a protracted discussion over the
benefits/drawbacks of the current xargs vs an updated
xargs,
Garance A Drosihn [EMAIL PROTECTED] writes:
Or maybe something to indicate where the list of arguments
should go in a command. Hrm. Let's say '-Y replstr' or
'-y[replstr]' (no blank after -y). If no [replstr] is
given on -y, it defaults to the two characters '[]'.
Then one might do:
Dima Dorfman wrote:
Garance A Drosihn [EMAIL PROTECTED] writes:
Or maybe something to indicate where the list of arguments
should go in a command. Hrm. Let's say '-Y replstr' or
'-y[replstr]' (no blank after -y). If no [replstr] is
given on -y, it defaults to the two characters '[]'.
On Fri, 20 Apr 2001 00:57:29 -0400, Garance A Drosihn [EMAIL PROTECTED] said:
'-y[replstr]' (no blank after -y).
Prohibited by POSIX. The `xargs' utility ``shall'' follow the Utility
Syntax Guidelines.
so I don't know how we go about adding options to it.
POSIX is clear on this issue: the
Folks,
although there was much rejoicing, I think there's no need for a
new option to cp. Just use the toolbox, it's not too hard:
(cat bigfilelist; echo destdir) | xargs cp
Or even
echo destdir bigfilelist
xargs cp bigfilelist
should do the trick.
Regards,
Jens
--
Jens
Jens Schweikhardt wrote:
although there was much rejoicing, I think there's no need for a
new option to cp. Just use the toolbox, it's not too hard:
(cat bigfilelist; echo destdir) | xargs cp
Or even
echo destdir bigfilelist
xargs cp bigfilelist
should do the trick.
Err, neither
Folks,
although there was much rejoicing, I think there's no need for a
new option to cp. Just use the toolbox, it's not too hard:
(cat bigfilelist; echo destdir) | xargs cp
Or even
echo destdir bigfilelist
xargs cp bigfilelist
should do the trick.
No, it won't. Consider a
[ attempting to consolidate two identical threads into one ]
Brian Somers [EMAIL PROTECTED] writes:
I agree - the script idea doesn't seem right.
If {} isn't allowed to implicitly mean ``all the arguments that'll
fit'', then I'd vote for using -i (a version that does full grouping)
Folks,
although there was much rejoicing, I think there's no need for a
new option to cp. Just use the toolbox, it's not too hard:
(cat bigfilelist; echo destdir) | xargs cp
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows the unix
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote:
(cat bigfilelist; echo destdir) | xargs cp
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows the unix principle of
using simple tools and glueing them togeather to do
Try:
echo 1 2 3 4 5 6 7 8 9 | xargs -n 4 echo
Now consider what would happen with the above suggested construct with
a very long file list.
I don't see a problem with adding an option to cp to treat the first
argument as the target instead of the last argument. It's a simple
On Fri, Apr 20, 2001 at 07:26:18PM -0700, Rodney W. Grimes wrote:
(cat bigfilelist; echo destdir) | xargs cp
I like this version of the patch!! It's much much cleaner than
hacking up cp or xargs, it even follows the unix principle of
using simple tools and glueing them togeather
Hi,
I have added a -d dir option to cp. This allows the target
directory to be specified at the head of the command line
instead of the tail. This makes cp work much more nicely with
tools like xargs... (allowing for major performance improvements
over inline shell loops).
The patch is
At 3:39 PM -0400 4/19/01, John W. De Boskey wrote:
I have added a -d dir option to cp. This allows the target
directory to be specified at the head of the command line
instead of the tail. This makes cp work much more nicely with
tools like xargs... (allowing for major performance
Garance A Drosihn [EMAIL PROTECTED] writes:
Or maybe something to indicate where the list of arguments
should go in a command. Hrm. Let's say '-Y replstr' or
'-y[replstr]' (no blank after -y). If no [replstr] is
given on -y, it defaults to the two characters '[]'.
Then one might do:
At 10:08 PM -0700 4/19/01, Dima Dorfman wrote:
Garance A Drosihn [EMAIL PROTECTED] writes:
Or maybe something to indicate where the list of arguments
should go in a command. Hrm. Let's say '-Y replstr' or
'-y[replstr]' (no blank after -y). If no [replstr] is
given on -y, it defaults
52 matches
Mail list logo
