I think the size can be changed in AIX 5L via smitty system. However,
you should consider using xargs. For example, instead of:
rm *
(ksh will expand * to all files in the current directory, thus blowing
the limit)
use:
ls | xargs rm
(where xargs will separate the list of files from stdin so that rm gets
invoked several times)
Ton
In article <u87n9v...@corp.supernews.com>,
This would be because I presume that you supplied something like rm * if
which is too many for the command to processing in one command line
statement (remember that * is equated by the shell before executing the
command)
If you want to remove all files drop to the parent directory and do a
rm -rf {mydirectory}
or selectively delete a few at a time
rm -f [a-z]*
rm -f [0-9]*
Hope this is of help
Regards,
Brent Butchard
"mark" <ma...@amicusystems.com> wrote in message
news:u87n9v...@corp.supernews.com...
cd /foo
find . -mtime -5 -exec rm {} \:
rm *
Read the man on find, that should tell you what I was doing there. This
usually happens to me when there is too many files in the directory so I
usually hust view of remove or ?? by listing them with the find command.
find . -name "*commonstring*" -ls
Anyway that is probably something that you didn't need to know,
Hope it helps but
Adrian
"Brent Butchard" <bbut...@ultradata.com.au> wrote in message
news:a60rg2$cgs$1...@perki.connect.com.au...
"Adrian" <ahi...@SPAM.tpg.com.au> schrieb im Newsbeitrag
news:3c84...@dnews.tpgi.com.au...
> What about removing the files in 2 steps ??
>
> cd /foo
> find . -mtime -5 -exec rm {} \:
> rm *
>
> Read the man on find, that should tell you what I was doing there. This
> usually happens to me when there is too many files in the directory so I
> usually hust view of remove or ?? by listing them with the find command.
> find . -name "*commonstring*" -ls
>
But find does travers subdirectories. So you might get in trouble to delete
files only in one directory.
My favorate command is " echo * | xargs -n10 rm"
Hajo
Well, it's true, but xargs will go around it
find . |xargs rm -f
or, if you have file names with 'spaces' in them
find . |xargs -i rm -f {}
To see how it works:
find . |xargs -i echo "rm -f {}"
rmdir should work as well.
--
Bela Gazdy, EUCLID/AIX Systems Support
Curmudgeon of Academic Hodge-Podge, ITD/ATG @ Emory
"...who shook his family tree, and a bunch of NUTS fell out."
>> find . -name "*commonstring*" -ls
>>
>
> But find does travers subdirectories. So you might get in trouble to delete
> files only in one directory.
> My favorate command is " echo * | xargs -n10 rm"
'echo *' is not much better than 'rm *', since it gets the same
pattern expansion of '*'.
'ls | xargs rm' should be better.
for I in `ls -1`; do rm -f $I;done
NOTE: you can use meta chars like * ? (ls -1 file*.dat)
Bye.
"Wladimir Mutel" <m...@fluffy.isd.dp.ua> wrote in message
news:slrna8mo7...@fluffy.isd.dp.ua...
echo * is much better because you can say "echo *.tmp" or something
without getting the "paramter list to long" error because "echo *"
does not produce a paramter list. Its just echo what the shell expands
for it.
Hajo
Um, no, that's not correct. The shell will be limited to a certain
amount of workspace in expanding wildcards; it does this _before_
executing the command, and therefore the prior comment is correct.
If the shell runs out of room during the expansion, you get the error
message. The 'find' version is the one that will not be limited
to shell implementation details.
--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
________________________________________________________________________
>Hans-Joachim Ehlers wrote:
>>
>> Wladimir Mutel <m...@fluffy.isd.dp.ua> wrote in message news:<slrna8mo7...@fluffy.isd.dp.ua>...
>> > В статье <a6655k$bucjh$1...@ID-78836.news.dfncis.de> Hans-Joachim Ehlers написал(а):
>> >
>> > >> find . -name "*commonstring*" -ls
>> > >>
>> > >
>> > > But find does travers subdirectories. So you might get in trouble to delete
>> > > files only in one directory.
>> > > My favorate command is " echo * | xargs -n10 rm"
>> >
>> > 'echo *' is not much better than 'rm *', since it gets the same
>> > pattern expansion of '*'.
>>
>> echo * is much better because you can say "echo *.tmp" or something
>> without getting the "paramter list to long" error because "echo *"
>> does not produce a paramter list. Its just echo what the shell expands
>> for it.
>
>Um, no, that's not correct. The shell will be limited to a certain
>amount of workspace in expanding wildcards; it does this _before_
>executing the command, and therefore the prior comment is correct.
>If the shell runs out of room during the expansion, you get the error
>message. The 'find' version is the one that will not be limited
>to shell implementation details.
>
Does it make a difference if ehco is a built-in, in which case the parameter
list won't be pased in the execve() system call, and therefore not a limited
by the kernel?
BTW, I wouldn't use ehco in this way either.
Villy
Nope. The maximum command line length is what limits your workspace.
Built-in
or not, there's a finite number of characters for wildcard expansion.
I'm not sure under AIX, but under linux (and I'm using the same shell, zsh so
it could behave the same) the backquote substitution, when too long, generates
an error.
Solution was
ls | while read myfile
do
rm -f $myfile
done;
Yet another suggestion for hardening against funky filenames
> rm -f $myfile
rm -f -- "$myfile"
> done;
The "--" says no more options, and the quotes take care of whitespace in names.
--
George Baltz N3GB
Computer Sciences Corp Rule of thumb: ANYthing offered
@NOAA/NESDIS/IPD by unsolicited email is a hoax,
Suitland, MD 20746 ripoff, scam or outright fraud.
>>This work, no matter how many files do you have on you directory.
>> for I in `ls -1`; do rm -f $I;done
>>NOTE: you can use meta chars like * ? (ls -1 file*.dat)
> I'm not sure under AIX, but under linux (and I'm using the same shell, zsh so
> it could behave the same) the backquote substitution, when too long, generates
> an error.
> Solution was
> ls | while read myfile
> do
> rm -f $myfile
> done;
Or maybe
ls | xargs rm -f --