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? ;-)
>
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
> increase
> 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
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)
> 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
>
> > > 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-portabl
> 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
> > >
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
a
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 sy
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
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
> > > > techn
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
> 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.
>
> 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 se
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 '[]' :-).
> 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 diff
> 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 München
> Any opinions expr
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 e
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
> 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 change
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 xarg
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
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 does
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/des
> 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 t
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 z
> 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 still waiting to see those well known techniques.
> --
> 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 trie
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 *sh
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 tw
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
> 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 butti
On Sat, 21 Apr 2001 10:52:05 -0400, Alexander Kabaev wrote:
> > for i in `find /path/to/source -type f`; do
> > cp $i /path/to/dest/
> > done
> >
> > What's all the fuss about?
>
> It looks like above construct will fail horribly if any of the files in /topdir
> have names with spaces i
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. What's being proposed is a non-standard
exten
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
>
> W
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/
> don
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
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:
> > 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 an
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 dest
> 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
> 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 simp
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
>
> 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 th
[ 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
>
> Or even
>
> echo destdir >>bigfilelist
> xargs cp < bigfilelist
>
> should do the trick.
No, it won't
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.
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 Schwei
< 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 implementation may add any options
it wishes, provided that those opt
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 charac
> 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 o
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, no
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
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 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 improvem
55 matches
Mail list logo
