From owner-freebsd-bugs Fri Oct 18 5: 0:16 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B5937B401 for ; Fri, 18 Oct 2002 05:00:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AF6E43E65 for ; Fri, 18 Oct 2002 05:00:12 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id g9IC0Bx3038562 for ; Fri, 18 Oct 2002 05:00:11 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id g9IC0Biw038561; Fri, 18 Oct 2002 05:00:11 -0700 (PDT) Date: Fri, 18 Oct 2002 05:00:11 -0700 (PDT) Message-Id: <200210181200.g9IC0Biw038561@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: abc@anchorageinternet.org Subject: Re: misc/44195: globbing/argument limits Reply-To: abc@anchorageinternet.org Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR misc/44195; it has been noted by GNATS. From: abc@anchorageinternet.org To: Peter Pentchev 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