lampert@millipore.com (Jeff Lampert) (11/15/90)
I had an application run wild and create thousands of zero length files on
my Sequent UNIX box a few days ago. All the files were in one sub-directory
and began with the characters SRW. "No big deal", I thought. "I'll just cd
to that directory and 'rm SRW*'"
Unfortunately, when I tried that, I got the error 'Arg list too long'.
When the shell tried to parse the asterisk, there were too many filenames
to fit in the argument list. What was I to do? The filenames were similar
to 'SRW634534872'. I could issue the command 'rm SRW63453487*', then
'rm SRW63453486*', etc. Or I could also write the directory list to a file,
then have a shell script delete the files from the directory list. (Keep
in mind that 'ls SRW*' also produces the 'Arg list too long' error for the
same reason.) Well, here's a neat work-around that I found. Since I'm
new to UNIX, I don't know how well known this is, but I hope it helps
someone other than me...
The 'find' command does'nt seem to have the 'Arg list' limitation. It also
has the feature of being able to execute a command on the files that it finds.
So, by giving the command:
find . -name "SRW*" -exec rm {} \;
I was able to delete all the SRW files. By adding -print, you can see the
files being worked on:
find . -name "SRW*" -print -exec rm {} \;
Keep in mind that find works recursively, and that the above command will
remove all files "SRW*" in the sub-directories below the current one!!!
This may be what you want, or not. Be careful.
One last example:
To change file protection on all files in a directory, and all files beneath
that directory,
cd /dirname
find . -name "*" -print -exec chmod 700 {} \;
Hope this helps. Any better ways? Please E-Mail me. Any way to aviod
recursion? Again, please let me know...
lampert@millipore.comboyd@necisa.ho.necisa.oz (Boyd Roberts) (11/16/90)
In article <1990Nov14.192707.1099@millipore.com> lampert@millipore.com (Jeff Lampert) writes: >So, by giving the command: > >find . -name "SRW*" -exec rm {} \; > >I was able to delete all the SRW files. Wow! Just when I thought the xargs thread had died. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
darcy@druid.uucp (D'Arcy J.M. Cain) (11/16/90)
In article <1990Nov14.192707.1099@millipore.com> Jeff Lampert writes: > [...] >The 'find' command does'nt seem to have the 'Arg list' limitation. It also >has the feature of being able to execute a command on the files that it finds. >So, by giving the command: > >find . -name "SRW*" -exec rm {} \; > >I was able to delete all the SRW files. > [...] >Hope this helps. Any better ways? Please E-Mail me. Any way to aviod >recursion? Again, please let me know... ls | grep '^SRW' | while read X do rm $i done -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
darcy@druid.uucp (D'Arcy J.M. Cain) (11/16/90)
In article <1990Nov16.001140.11923@druid.uucp> I wrote: >ls | grep '^SRW' | while read X >do rm $i >done Ouch! Please don't flood my mailbox or the net. Of course I meant do rm $X -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
nrf@cbnewsh.att.com (neal.r.fildes) (11/17/90)
> In article <1990Nov16.001140.11923@druid.uucp> >>ls | grep '^SRW' | while read X >>do rm $X >>done > I would recommend the xargs(1) command for such things. it saves fork/exec's e.g. ls | grep '^SRW' | xargs rm xargs bunches up a number of arguments into one fork/exec!
bernie@DIALix.oz.au (Bernd Felsche) (11/17/90)
In <1990Nov16.001140.11923@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >In article <1990Nov14.192707.1099@millipore.com> Jeff Lampert writes: >> [...] >>The 'find' command does'nt seem to have the 'Arg list' limitation. It also 'find' does have it, if you pass it too many arguments! The command used below hides filename expansion from the shell. Ask what would happen if you hadn't quoted "SRW*"? >>find . -name "SRW*" -exec rm {} \; >> [...] Unfortunate side-effect is that files with matching names in subdirectories will also be removed. The following method is slow and also requires many forks, making you very popular on a busy system. >ls | grep '^SRW' | while read X >do rm $i >done We all know that the "best" way is to allow the shell to expand filenames and echo them into xargs... right? vis: echo SRW* | xargs -n10 -n option defines the maximum number of arguments to pass to rm. This may be too many for some older systems, or where pathnames are very long... the -s option to xargs defines the size allowed, but then, most users don't know what size to use... I also thought that the 'xargs' debate had finished... but then, maybe nobody read the second-last entry in the reference manual. -- ________Bernd_Felsche__________bernie@DIALix.oz.au_____________ [ Phone: +61 9 419 2297 19 Coleman Road ] [ TZ: UTC-8 Calista, Western Australia 6167 ]
mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (11/22/90)
In article <1990Nov16.001140.11923@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: :In article <1990Nov14.192707.1099@millipore.com> Jeff Lampert writes: :> [...] :>The 'find' command does'nt seem to have the 'Arg list' limitation. It also :>has the feature of being able to execute a command on the files that it finds. :>So, by giving the command: :> :>find . -name "SRW*" -exec rm {} \; :> :>I was able to delete all the SRW files. :> [...] :>Hope this helps. Any better ways? Please E-Mail me. Any way to aviod :>recursion? Again, please let me know... : :ls | grep '^SRW' | while read X :do rm $i :done : :-- :D'Arcy J.M. Cain (darcy@druid) | :D'Arcy Cain Consulting | I support gun control. :West Hill, Ontario, Canada | Let's start with the government! :+ 416 281 6094 | As a side issue, get a load of this construct taken from a host management utility (that not surprisingly failed with an 'ls - arg list too long' message cd /etc;ls * | grep hosts >/dev/null 2>&1 if test $? -ne 0 then echo /etc/hosts not found exit 1 fi This atrocity (instead of 'if test -f /etc/hosts ...') snuck by because the QA guys started with a small set of environment variables whereas I came in su'ed to root and I use about 1k of env variables. I eventually fixed the problem but bypassed it by clearing out my environment space of all but essential variables. As another aside, take a look at this creation: grep -v parm_a filename |\ grep -v parm_b |\ grep -v parm_c |\ grep -v parm_d |\ grep -v parm_e |\ grep -v parm_f |\ grep -v parm_g |\ grep -v parm_h |\ grep -v parm_i |\ grep -v parm_j |\ grep -v parm_k |\ grep -v parm_l |\ grep -v parm_m |\ grep -v parm_n |\ grep -v parm_o |\ grep -v parm_p |\ grep -v parm_q |\ grep -v parm_r \ >/tmp/config$$ The intent was to remove a number of different parms from filename so they could later be readded. It blew up when it ran me out of processes (we later found out that an application's de-installation procedure munged our PROCS and NPROCS entries for the configuration - gee, thanks). I, of course, had quite a few things running, unlike the QA people who come in on a nice clean box. It makes you wonder what kind of numbskulls that put to work writing software - with all the tools available to do this job - awk, nawk, sed, ex, egrep - they chose the most inappropriate tool and beat the hell out of the box to get things done. I replaced it with egrep egrep -v 'parma_a|parm_b|...|parm_r' filename. -- Dan Mercer NCR Network Products Division - Network Integration Services Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) "MAN - the only one word oxymoron in the English Language"
tif@doorstop.austin.ibm.com (Paul Chamberlain) (11/27/90)
In article <728@npdiss1.StPaul.NCR.COM> mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) writes: >I replaced it with >egrep -v 'parma_a|parm_b|...|parm_r' filename. egrep -v 'parma_[a-r]' filename. Would've been a lot less typing. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif