Date: Fri, 18 Oct 2002 05:00:11 -0700 (PDT) From: abc@anchorageinternet.org To: freebsd-bugs@FreeBSD.org Subject: Re: misc/44195: globbing/argument limits Message-ID: <200210181200.g9IC0Biw038561@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/44195; it has been noted by GNATS.
From: abc@anchorageinternet.org
To: Peter Pentchev <roam@ringlet.net>
Cc:
Subject: Re: misc/44195: globbing/argument limits
Date: Fri, 18 Oct 2002 11:57:36 GMT
> > >Number: 44195
> > >Category: misc
> > >Synopsis: globbing/argument limits
> > >Originator: Joe Public
> > >Release: i386 FreeBSD 4.7-RELEASE
> > >Organization:
> > no org
> > >Environment:
> > ^^^^^^^^^^^^^^^^^^^^^^^^
> > >Description:
> > argument limits painful to users in days of 100GB drives.
> > >How-To-Repeat:
> > try a command and give it a few thousand arguments,
>
> It is not a matter of how many arguments you give to a command, it is
> simply a matter of how *long* the command line becomes. Lugging around
> a multimegabyte command line buffer through shells, execv() system calls
> and such would be a *major* strain on your system.
i would've assumed the command line stays in place in memory,
and only a pointer is passed around - and checking the exec(3)
manpage seems to show this is the case in fact.
> > like in file modifying command a folder with 6000 files.
> > find(1) is too slow, and combining it with xargs is a kludge.
>
> If you mean that 'find -exec' is too slow, then I would argue that using
> -exec is the kludge, when xargs(1) is available. I am pretty sure that
> the find(1) and xargs(1) utilities were actually developed together,
> with a common goal in mind, that goal being *exactly* processing of
> multiple files in one go.
ok - interesting - i appreciate you explaining this.
it should be in a the FAQ or something.
> The -exec primary to find(1) is extremely inefficient when dealing with
> many files - it spawns a new process for each file it finds, which, as
> you note, is too slow. The xargs utility will do a much better job; I
> would be very interested in what exactly do you consider to be a kludge
> about it.
i consider it to be a kludge when you have to:
find -s "$I" ! -type d | xargs tar rvf "$I.tar" && \
&& gzip -f9 "$I.tar" && mv "$I.tar.gz" "$I.tgz"
just to create a sorted tar/gzip archive
of a directory tree. hehe - as i look at
it - i say to myself "this is bullshit" :).
i mean - UNIX hackers have got to be smarter
than to demand all that from a user just to
accomplish such a minor ordinary task.
also, when you do something like:
find / \! \( -path \*/bin/\* -or -path \*/lib/\* \
-or -path \*/libexec/\* -or -path /usr/games/\* \
-or -path \*/sbin/\* -or -path /boot/\* \
-or -path /dev/\* -or -path /modules/\* \
-or -path /proc/\* -or -path /root/\* \) \
-type f -exec chown root:wheel {} \;\
-exec chmod 0644 {} \;
ie, something a find(1) with 2 -exec's, xargs fails,
and you are forced to double or triple (or more) the code
it takes - according to the number of -exec's you need to
perform - i consider this to be a kludge as well.
> > there has to be a better solution than imposing these
> > arbitrary limits on arguments. user limits in /etc/login.conf,
> > or something like that, should be used to limit use of
> > utilities, not compiled-in defines.
>
> As explained above, the limits are not arbitrary, but governed by strict
> common sense when it comes to passing buffers both between userland
> utilities and through multiple crossings of the userland/kernel boundary
> in system calls.
i am not much of a C hacker these days, so i will respect what
you say, but i don't see why you say we are passing
'megabytes of buffers' around. the 7000 fonts i got are
only 150k of command line for example - and as i said,
upon reading exec(3), it appears pointers are passed, not buffers.
> G'luck,
> Peter
>
> PS. This will very probably be my last post on this subject, and nobody
> should be surprised if this PR is closed very soon; what with the recent
> mailing list "activity", it scores big on my troll indicator. I could
> be wrong, of course, but I'm just stating my opinion here.
ok - well - no trolling - just installed 4.7, and hit
a point of frustration with things that have been
bugging me over the years - that don't see to
get fixed or improve.
i truly value the effort you made to try to explain,
though as stated, i still don't see the problem
in fixing things.
thank you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210181200.g9IC0Biw038561>