Re: [CentOS] Re: ls and rm: "argument list too long"
On Fri, Oct 24, 2008 at 3:28 PM, Scott Silva <[EMAIL PROTECTED]> wrote: > > When I learned Fortran IV in 1980 my teacher said that Fortran and Cobol were > the languages of the future! > Sheesh! When I learned Fortran IV in 1974, we had the WatFour and WatFive compilers, and were getting ready to upgrade to Fortran V. Algol 68 was the language of the future. All that changed when I learned Pascal at UCSD in 1978, another "language of the future" that still is Still, we built a whole OS based on UCSD Pascal 2.0 (and then modified it extensively) in 1980, and that was fine until I moved into DYNIX in 1987 - loved it, and C, and stayed there. That's why I love Linux. Sort of. mhr ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Fri, Oct 24, 2008 at 06:15:31PM -0500, Michael Peterson wrote: > I have been learning and using COBOL since the mid 80's. > I use COBOL at the present time for Web Programming also. > The COBOL we use runs on UNIX and Linux. > I use it in addition to PHP/MySQL for Web Programming. > > I have looked at Fortran programs but never had to learn the language. > It is on a PDP 11 that we shutdown in the late 90's. PDP-11... now there was a nice machine! That's where I first learned Assembly language--and I definitely was spoiled by that. Now when I look at assembler for, e.g. 80x86 machines I want to throw up. Nothing has been anything as nice to program in since with the possible exception of the 68000 family which had a lot of similarities. -- Fred Smith -- [EMAIL PROTECTED] - "For him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy--to the only God our Savior be glory, majesty, power and authority, through Jesus Christ our Lord, before all ages, now and forevermore! Amen." - Jude 1:24,25 (niv) - pgpuztAnbYctE.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
Scott Silva wrote: on 10-24-2008 11:19 AM Ed Westphal spake the following: MHR wrote: On Fri, Oct 24, 2008 at 9:31 AM, Bill Campbell <[EMAIL PROTECTED]> wrote: Programming to the lowest common denominator may not feel sexy, but it can prevent many headaches in the future. I spent quite a bit of time many years ago getting a large FORTRAN system working that had been written on a system that use 7 character variable names where standard FORTRAN only permitted 6 (it was amazing how many of the variable names differed only in the 7th character). While this would be relatively easy to deal with today, it was a bitch when all programs were on 80-column punch cards. Okay, now you're officially old. (Like me.) mhr Forgive my senility, but I'm continually amazed how many of us ole fossils are still around, and running Linux! Not to use up too much bandwidth, but the switch from Fortran 2 to 2D, for disk, was a big event way back when. Then Fortran 4 came around! Be still my old heart! ENW When I learned Fortran IV in 1980 my teacher said that Fortran and Cobol were the languages of the future! ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I have been learning and using COBOL since the mid 80's. I use COBOL at the present time for Web Programming also. The COBOL we use runs on UNIX and Linux. I use it in addition to PHP/MySQL for Web Programming. I have looked at Fortran programs but never had to learn the language. It is on a PDP 11 that we shutdown in the late 90's. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Fri, Oct 24, 2008, Scott Silva wrote: ... >When I learned Fortran IV in 1980 my teacher said that Fortran and Cobol were >the languages of the future! In a presentation at the 1985 Usenix conference, Rob Pike made a comment that he didn't know what the language for scientific program of the future would be, but that it would be called FORTRAN. COBOL on Burroughs Medium Systems was an extremely powerful language. I wrote some pretty large commerical systems with it. My main problems with COBOL came when I had to run on a system other than Burroughs where COBOL was not fully recursive, and missing features that I took for granted. My first exposure to computers was in 1966 on a Bendix G-20 and their Mishewaka FORTRAN. This version of FORTRAN was written by engineers, and had features that were well ahead of IBM's FORTRAN: + Everything was done in floating point -- engineers don't grok integers. + ``DO'' loops would of course have floating point variables, and worked as an engineer or mathematician would expect. + ``DO'' loops tested at the top of the loop instead of at the end as they did on IBM FORTRAN. Thus if the starting value was greater than the terminating value nothing in the loop would be executed. + Free form input from cards (e.g. one could have ``PI=3.14159'' and it would do the reasonable thing. + Free form output. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax:(206) 232-9186 I have never been molested by any person but those who represented the state -- Thoreau ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: ls and rm: "argument list too long"
on 10-24-2008 11:19 AM Ed Westphal spake the following: > MHR wrote: >> On Fri, Oct 24, 2008 at 9:31 AM, Bill Campbell >> <[EMAIL PROTECTED]> wrote: >> >>> Programming to the lowest common denominator may not feel sexy, >>> but it can prevent many headaches in the future. I spent quite a >>> bit of time many years ago getting a large FORTRAN system working >>> that had been written on a system that use 7 character variable >>> names where standard FORTRAN only permitted 6 (it was amazing how >>> many of the variable names differed only in the 7th character). >>> While this would be relatively easy to deal with today, it was a >>> bitch when all programs were on 80-column punch cards. >>> >>> >> >> Okay, now you're officially old. >> >> (Like me.) >> >> mhr >> > Forgive my senility, but I'm continually amazed how many of us ole > fossils are still around, and running Linux! Not to use up too much > bandwidth, but the switch from Fortran 2 to 2D, for disk, was a big > event way back when. Then Fortran 4 came around! Be still my old heart! > > ENW When I learned Fortran IV in 1980 my teacher said that Fortran and Cobol were the languages of the future! -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: ls and rm: "argument list too long"
Les Mikesell wrote:
Robert Nichols wrote:
These shouldn't make any difference. The limit is on the size of the
expanded shell command line.
Really?
$ M=0; N=0; for W in `find /usr -xdev 2>/dev/null`; do M=$(($M+1));
N=$(($N+${#W}+1)); done; echo $M $N
156304 7677373
vs.
$ /bin/echo `find /usr -xdev 2>/dev/null`
bash: /bin/echo: Argument list too long
For the first case, the shell never tries to pass the list as command
arguments.
It builds the list internally, limited only by memory size, and
processes the
words one by one.
Is that peculiar to bash? I thought the `command` construct was
expanded by shells into the command line before being evaluated.
I can't answer for how any particular shell allocates its internal memory,
but yes, the shell does read the entire output from `command` before
evaluating it. If this data is simply being used internally it never
gets passed to the kernel as an argument to exec() and thus can never
result in errno==E2BIG (7, "Argument list too long").
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Sat, 2008-10-18 at 06:00 -0400, William L. Maltby wrote:
>
Ok. 3rd cup of coffee has made its way into various of my systems. A
minor correction (but important for us pedantic typers) is below.
> main(argc, *argv[]) /* could be **argv instead */
main(int argc, char *argv[]) /* could be **argv instead */
> {
> /* stuff to do */
> .
> .
> .
> }
>
--
Bill
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Sat, 2008-10-18 at 06:00 -0400, William L. Maltby wrote: > > The longest command line in this case is "find /usr -xdev', 15 > characters. Find "sees" only 10 characters. Uh, +1 for the \0 that terminates each parameter? Need more java here. > -- Bill ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Fri, 2008-10-17 at 23:52 -0500, Les Mikesell wrote:
> Robert Nichols wrote:
> >
> >> These shouldn't make any difference. The limit is on the size of the
> >> expanded shell command line.
> >
> > Really?
> >
> > $ M=0; N=0; for W in `find /usr -xdev 2>/dev/null`; do M=$(($M+1));
> > N=$(($N+${#W}+1)); done; echo $M $N
> > 156304 7677373
> >
> > vs.
> >
> > $ /bin/echo `find /usr -xdev 2>/dev/null`
> > bash: /bin/echo: Argument list too long
> >
> > For the first case, the shell never tries to pass the list as command
> > arguments.
> > It builds the list internally, limited only by memory size, and
> > processes the
> > words one by one.
>
> Is that peculiar to bash? I thought the `command` construct was
> expanded by shells into the command line before being evaluated.
IIRC, none of the above make a "command line". Everything but the
`find /usr -xdev 2>/dev/null`
is a bash "internal command". IIRC, what should happen here is a new
instance of bash is spawned as part of a pipeline that sends the output
of the find (which is "exec'd" by that new instance of bash, the child)
into the parent. The parent reads the input from the pipe and can do
whatever it wants, in this case build an array. It then uses the array
as data to the loop.
The "command line" is never constructed with the long list. It is only
passed to the child (the new instance of bash that is part of the
pipeline). That instance receives an argument count and an array of
pointers to the arguments. In "C" parlance it looks something like this.
main(argc, *argv[]) /* could be **argv instead */
{
/* stuff to do */
.
.
.
}
The "*argv[]" pointers point to the parts of the "command line",
find /usr -xdev
The child execs find, passing the "/usr" and "-xdev" as arguments to
find (which has a similar "main" construct), another "command line". The
I/O redirection was already done by the parent, so the child need not
even know that "stdout" is a pipe.
The longest command line in this case is "find /usr -xdev', 15
characters. Find "sees" only 10 characters.
I hope I've remembered correctly, that this is not FUD, and that it
helps someone.
>
--
Bill
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
Robert Nichols wrote:
These shouldn't make any difference. The limit is on the size of the
expanded shell command line.
Really?
$ M=0; N=0; for W in `find /usr -xdev 2>/dev/null`; do M=$(($M+1));
N=$(($N+${#W}+1)); done; echo $M $N
156304 7677373
vs.
$ /bin/echo `find /usr -xdev 2>/dev/null`
bash: /bin/echo: Argument list too long
For the first case, the shell never tries to pass the list as command
arguments.
It builds the list internally, limited only by memory size, and
processes the
words one by one.
Is that peculiar to bash? I thought the `command` construct was
expanded by shells into the command line before being evaluated.
--
Les Mikesell
[EMAIL PROTECTED]
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: ls and rm: "argument list too long"
Les Mikesell wrote:
thad wrote:
it should be:
for i in `ls /var/amavis/tmp`
do
rm $i
done
These shouldn't make any difference. The limit is on the size of the
expanded shell command line.
Really?
$ M=0; N=0; for W in `find /usr -xdev 2>/dev/null`; do M=$(($M+1));
N=$(($N+${#W}+1)); done; echo $M $N
156304 7677373
vs.
$ /bin/echo `find /usr -xdev 2>/dev/null`
bash: /bin/echo: Argument list too long
For the first case, the shell never tries to pass the list as command arguments.
It builds the list internally, limited only by memory size, and processes the
words one by one. As a final test case, by using the shell's builtin 'echo'
the whole 7-plus megabytes gets echoed to the terminal:
$ echo `find /usr -xdev 2>/dev/null`
(no errors -- just lots of output)
Anyway, the "for i in `ls ...`" solution breaks for paths that include
embedded white space.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
RE: [CentOS] Re: ls and rm: "argument list too long"
> > rm -rf /var/amavis/tmp > > > > and get only "argument list too long" as feedback. > > > > Is there a way to go round this problem? > > > > I have CentOS 5.2. > > > It isn't a problem with the commands, it is a problem of how > long a command > line can be when piped to a command. > > rm -rf /var/amavis/tmp is effectively the same as rm -rf > /var/amavis/tmp/1 > /var/amavis/tmp/2 /var/amavis/tmp/3 /var/amavis/tmp/4 > /var/amavis/tmp/5 ... > etc. The number of diles and directories in that folder is > the limiting factor. I don't believe this is correct. The command "rm -rf /path/to/dir" doesn't expand on the shell the same way "rm -rf /path/to/dir/*" would. Unless I'm misunderstanding your comment, "rm -rf /path/to/dir" will remove everything as intended without blowing out the argument list. Dealing with file removal and getting 'argument list too long' is a FAQish question, and there is more than one way to get around the issue. Common workarounds include find piped to xargs rm, the above mentioned recursive directory nuke, one line perl scripts, etc. -John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: ls and rm: "argument list too long"
on 10-17-2008 2:30 AM Jussi Hirvi spake the following: > Since when is there a limit in how long directory listings CentOS can show > (ls), or how large directories can be removed (rm). It is really annoying to > say, for example > > rm -rf /var/amavis/tmp > > and get only "argument list too long" as feedback. > > Is there a way to go round this problem? > > I have CentOS 5.2. > It isn't a problem with the commands, it is a problem of how long a command line can be when piped to a command. rm -rf /var/amavis/tmp is effectively the same as rm -rf /var/amavis/tmp/1 /var/amavis/tmp/2 /var/amavis/tmp/3 /var/amavis/tmp/4 /var/amavis/tmp/5 ... etc. The number of diles and directories in that folder is the limiting factor. And yes, Fedora would have the same limitation. -- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
On Fri, Oct 17, 2008 at 4:09 AM, Jeremy Sanders <[EMAIL PROTECTED]> wrote: > > This limitation has been removed from more recent kernels. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba > > http://www.gnu.org/software/coreutils/faq/#Argument-list-too-long > This is usually not a kernel issue at all - it is a shell issue. The limitation is the len ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Re: ls and rm: "argument list too long"
Jeremy Sanders wrote: piping ls to xargs should do the trick. man xargs for details. Ok, thanks for ideas, Laurent and Lawrence. A strange limitation in ls and rm, though. My friend said he hasn't seen that in Fedora. This limitation has been removed from more recent kernels. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba http://www.gnu.org/software/coreutils/faq/#Argument-list-too-long It is probably still best not to expect the ability to build infinitely long command lines. You can hit some other limit eventually. -- Les Mikesell [EMAIL PROTECTED] ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Re: ls and rm: "argument list too long"
Jussi Hirvi wrote: > Lawrence Guirre ([EMAIL PROTECTED]) > kirjoitteli (17.10.2008 12:55): >> piping ls to xargs should do the trick. man xargs for details. > > Ok, thanks for ideas, Laurent and Lawrence. > > A strange limitation in ls and rm, though. My friend said he hasn't seen > that in Fedora. This limitation has been removed from more recent kernels. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba http://www.gnu.org/software/coreutils/faq/#Argument-list-too-long Jeremy ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
