[opensuse] /bin/rm: Argument list too long
Hello: I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/* but got the error message: bash: /bin/rm: Argument list too long The file number in the folder is ~ 60 000. Why rm is not working? Is this a bug? How can I delete these files w/o removing the folder itself? Thanks, IG ps: The system is default openSUSE 10.3 with default kde 3.5.7 ui: Te már megnézted, hogy diszlexiásak-e a gyerekeid? Találtam egy szülőknek szóló diszlexiatesztet, ingyenes oldal, nem kerül semmibe. Ne várj, töltsd ki te is! Kattints ide: www.diszlexiateszt.hu/i.php?id=fr080325 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Mar 26, 2008 at 11:51 AM, Istvan Gabor
Hello:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
but got the error message: bash: /bin/rm: Argument list too long
Known problem: http://www.moundalexis.com/archives/000035.php -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 26 March 2008 12:07, Nick Zeljkovic wrote:
How can I delete these files w/o removing the folder itself?
find .thumbnails -type f -exec rm -rf {} \;
This could be very slow, since there must be a fork / exec for each file. Usually much faster is this: % find dirName(s) {findCriteria} -print0 |xargs -0 rm By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary. Note the use of find's -print0 option and the corresponding -0 option to xargs. This causes each file name to be delineated by a NUL character which means that files with spaces or other funky characters in their names won't mess things up.
And no, it's not a bug.
Not at all, just a limit.
-- Nick Zeljkovic
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
% find dirName(s) {findCriteria} -print0 |xargs -0 rm
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
You learn something new every day :) -- Nick Zeljkovic -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2008-03-26 at 21:21 +0100, Per Jessen wrote:
Randall R Schulz wrote:
% find dirName(s) {findCriteria} -print0 |xargs -0 rm
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
huh? It's what xargs does. It's the basic functionality of the program Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "Anders Johansson"
On Wed, 2008-03-26 at 21:21 +0100, Per Jessen wrote:
Randall R Schulz wrote:
% find dirName(s) {findCriteria} -print0 |xargs -0 rm
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
huh? It's what xargs does. It's the basic functionality of the program
Anders
Bizarrely, he's right though. The man page (at least on linux at least on suse) doesn't quite say what the point is. It says it "builds command lines from stdin" but that doesn't mean very much. It doesn't actually say the two crucial parts about: 1) up to the limit if the shell or system or the application 2) re-executing as necessary, indefinitely, until input is exhausted It is a funny sort of a blind spot. 99.99% of people who read the page, and obviously the author too, do not notice the lack bcause we all just know what xargs is for somehow from some other source. In my case because the SCO Xenix man page for xargs was of better quality. :) I don't remember it exactly but I'm pretty sure that was where I first encountered xargs and the purpose of the util was made clear. The current SCO Open Server 5.0.7 man page is probably the same and says, among other useful things: "When no options are coded, the initial-arguments are followed by arguments read continuously from standard input until an internal buffer is full, and command is executed with the accumulated arguments. This process is repeated until there are no more arguments. When there are option conflicts (for example, -l and -n), the last specified option has precedence." You might say "why would you man xargs unless you already knew you needed xargs, and thus, what xargs was for?" Lots of reasons. Starting with: "This script is running xargs. Why?" "Some dude/magazine/etc... told me to run blah |xargs blah. What will that do?" It should also be noted that it's also useful for iterating through arbitrarily large lists one item at a time instead of accumulating large command lines. When I say "or the application" above that means, maybe the limit is just one filename argument per invcation because app foo can only handle one file at a time. (like say, vorbiscomment) xargs -n 1 will do that. The point of xargs isn't really to accumulate large command lines, but rather to handle input of unknown/unlimited size and chunk it into command lines of whatever size is needed, which may just as easily be one item as MAXCARGS. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-26 at 18:26 -0400, Brian K. White wrote:
Bizarrely, he's right though. The man page (at least on linux at least on suse) doesn't quite say what the point is. It says it "builds command lines from stdin" but that doesn't mean very much. It doesn't actually say the two crucial parts about: 1) up to the limit if the shell or system or the application 2) re-executing as necessary, indefinitely, until input is exhausted
It is a funny sort of a blind spot. 99.99% of people who read the page, and obviously the author too, do not notice the lack bcause we all just know what xargs is for somehow from some other source.
I did not know. I had to use xargs recently, and I wanted one argument per command line, it was not happening, and I knew not why. I thought the default was one command per line precisely. Obviusly I was wrong, now I know, but the man page did not put me wise. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6tBJtTMYHG2NR9URAhOOAJoC3G65cTES5CU1K0iTLbZ92GJ7YgCZAQSN AbxydSj1si0UCFwqOamZmVk= =PZYg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, Mar 26, 2008 at 3:26 PM, Brian K. White
It is a funny sort of a blind spot. 99.99% of people who read the page, and obviously the author too, do not notice > the lack bcause we all just know what xargs is for somehow from some other source.
I find that more often than you might expect. Coders are often the worst documenters. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-26 at 22:50 +0100, Anders Johansson wrote:
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
huh? It's what xargs does. It's the basic functionality of the program
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6s7atTMYHG2NR9URAvllAKCS9G9fDbXu3LZg1fvLyEml8hHAkQCfbVfS niW4dygW7whZkazeC7YN1JY= =BQ1j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. a écrit :
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
quite surprisingly, man xargs in google gives many different file contents, some clear, other not jdd -- Jean-Daniel Dodin Président du CULTe www.culte.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 2008-03-26 23:47, jdd sur free wrote:
Carlos E. R. a écrit :
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
quite surprisingly, man xargs in google gives many different file contents, some clear, other not
jdd
whatis xargs xargs (1) - build and execute command lines from standard input xargs (1p) - construct argument lists and invoke utility man 1p xargs Curiously, it's described in the PPM page of xargs. /Sylvester -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
huh? It's what xargs does. It's the basic functionality of the program
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
Exactly - in particular, the '-0' argument doesn't say anything about matching any size limit. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 27 March 2008 17:33:08 Per Jessen wrote:
Carlos E. R. wrote:
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Randall, that has got to be one of the coolest pieces of advice I've seen here. "man xargs" doesn't even mention it.
huh? It's what xargs does. It's the basic functionality of the program
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
Exactly - in particular, the '-0' argument doesn't say anything about matching any size limit.
Possibly because that's not what -0 does. -0 just tells xargs to not use blanks or newlines as parameter separator, but to wait for a null character instead Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Anders Johansson wrote:
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
Exactly - in particular, the '-0' argument doesn't say anything about matching any size limit.
Possibly because that's not what -0 does. -0 just tells xargs to not use blanks or newlines as parameter separator, but to wait for a null character instead
Ah, now I'm beginning to see your point. I would have _sworn_ that "| xargs <cmd>" did not take the max # arguments into account, which is why I thought '-0' somehow altered that. But I am clearly wrong - "| xargs <cmd>" _does_ know about max number of arguments. I still feel certain I've done stuff like: find <dir> -type f | xargs zgrep -i blah and seen something like "too many arguments" or whatever it is, but of course I can't reproduce that now. It's not as if I haven't been using xargs, I think I use it quite a few times daily - but as Peter Zeljkovic said "You learn something new every day". /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "Per Jessen"
But the thing is, the xarg's man page does not clearly say that it joins arguments up to the size limit. There are hints that concurs with that fact, but it is not clearly stated :-)
Exactly - in particular, the '-0' argument doesn't say anything about matching any size limit.
Possibly because that's not what -0 does. -0 just tells xargs to not use blanks or newlines as parameter separator, but to wait for a null character instead
Ah, now I'm beginning to see your point. I would have _sworn_ that "| xargs <cmd>" did not take the max # arguments into account, which is why I thought '-0' somehow altered that. But I am clearly wrong - "| xargs <cmd>" _does_ know about max number of arguments. I still feel certain I've done stuff like: find <dir> -type f | xargs zgrep -i blah and seen something like "too many arguments" or whatever it is, but of course I can't reproduce that now. ------------ If you run: find /path/to/foo -type f -name foo* | xargs zgrep -i blah in the wrong place, you will still get arg list too long. That is why it's always: find /path/to/foo -type f -name 'foo*' | xargs zgrep -i blah single-forward-quotes <aside> I have seen scripts that are part of expensive commercial software that did just that. They used xargs to process a list of unpredictable size - good! They used shell globbing characters to generate the list - bonehead! ...Then they go on in the same script to use chown and chmod in backwards order such that chown undoes what chmod did. </aside> If you don't use find -print0 |xargs -0 then any files with spaces in the names will look like seperate files (which don't exist) to whatever command you ran with xargs. If you have filenames with globbing characters in them (this is legal), then they may be handled ok by find and xargs and then be expanded by the shell on the command line that xargs created, thus increasing the command line beyond the maximum since xargs would have created a line that was already maxxed out. It's also possible for there to be discrepencies between the app being run by xargs, and the rest of the system. Maybe the shell and the kernel will tolerate up to 4k (I think it's more like 100 or 400 but no matter) so xargs generates 4k command lines, but maybe appfoo can only handle 1k ? There are probably lots of odd ways to to cause the message or similar ones despite the utils working perfectly as advertised. There is nothing wrong in any of that, it's up to you to know what you are doing, or at least be prepared to figure out what you did wrong in 99.9999% of the times when some util doesn't do what you expected. :) -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 27 March 2008 15:35, Brian K. White wrote:
...
If you run: find /path/to/foo -type f -name foo* | xargs zgrep -i blah in the wrong place, you will still get arg list too long. That is why it's always: find /path/to/foo -type f -name 'foo*' | xargs zgrep -i blah single-forward-quotes
It's even more complicated than that. BASH has an option that determines whether an argument with glob characters ('*', e.g.) that matches no files is an error or is passed as entered (including the glob characters). Personally, though I have my shell configured to pass non-matching glob patterns through, with only one exception I always quote glob-bearing arguments. The exception is grep's --include= or --exclude= options. The likelihood that I have files whose names begin with "--include=" or "--exclude=" is low enough to be considered zero (by me).
<aside> I have seen scripts that are part of expensive commercial software that did just that. They used xargs to process a list of unpredictable size - good! They used shell globbing characters to generate the list - bonehead! ...Then they go on in the same script to use chown and chmod in backwards order such that chown undoes what chmod did. </aside>
I see lots of very poorly written shell scripts. It's not as easy to do right as many people seem to think.
If you don't use find -print0 |xargs -0 then any files with spaces in the names will look like seperate files (which don't exist) to whatever command you ran with xargs.
Actually, they could exist. There's no reason a given directory could not contain both of these file names, e.g.: "foo" "foo is bar"
If you have filenames with globbing characters in them (this is legal), then they may be handled ok by find and xargs and then be expanded by the shell on the command line that xargs created, thus increasing the command line beyond the maximum since xargs would have created a line that was already maxxed out.
Xargs does not use the shell to interpret the command invocations it creates. It goes directly to the kernel's fork and exec primitives.
It's also possible for there to be discrepencies between the app being run by xargs, and the rest of the system. Maybe the shell and the kernel will tolerate up to 4k (I think it's more like 100 or 400 but no matter) so xargs generates 4k command lines, but maybe appfoo can only handle 1k ?
That's not how it works. Xargs deals only in the maximum argument list limits (number of args and / or total argument bytes). While I can't say that no command imposes its own limits on the size of arguments lists, there's really no reason to do so and I know of no programs that have internal limits to the size of the argument list they will successfully process.
...
-- Brian K. White
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
It's also possible for there to be discrepencies between the app being run by xargs, and the rest of the system. Maybe the shell and the kernel will tolerate up to 4k (I think it's more like 100 or 400 but no matter) so xargs generates 4k command lines, but maybe appfoo can only handle 1k ?
That's not how it works.
Sure it is.
Xargs deals only in the maximum argument list limits (number of args and / or total argument bytes). While I can't say that no command imposes its own limits on the size of arguments lists,
You sure can't.
there's really no reason to do so and I know of no programs that have internal limits to the size of the argument list they will successfully process.
Within the very small world of a modern linux distribution where such things as *conf() exist and sticking to programs supplied by the vendor, maybe you are indeed hard pressed to find an app that doesn't break that assumption. Suffice it to say I have seen a larger world. You have some body of experience, and an assumption that you haven't seen broken. That is fine and a perfectly reasonable and correct basis for continuing to operate from that assumption by default. Doing so is called being efficient and in tune with your environment. But do not mistake that for gospel. Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks? -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thursday 27 March 2008 18:51, Brian K. White wrote:
It's also possible for there to be discrepencies between the app being run by xargs, and the rest of the system. Maybe the shell and the kernel will tolerate up to 4k (I think it's more like 100 or 400 but no matter) so xargs generates 4k command lines, but maybe appfoo can only handle 1k ?
That's not how it works.
Sure it is.
No. It's not. There's no way for xargs to know about anything other than the kernel-imposed argument list size limit.
....
Suffice it to say I have seen a larger world.
Prove it.
You have some body of experience, and an assumption that you haven't seen broken. That is fine and a perfectly reasonable and correct basis for continuing to operate from that assumption by default. Doing so is called being efficient and in tune with your environment. But do not mistake that for gospel.
I live by no gospel. And, I dare say, I'm not as arrogant as you.
Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks?
Because it can make no assumptions about the configuration of the kernel on which it's running.
-- Brian K. White
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz:
There's no way for xargs to know about anything other than the kernel-imposed argument list size limit.
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf. Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Wolfgang Woehl wrote:
Randall R Schulz:
There's no way for xargs to know about anything other than the kernel-imposed argument list size limit.
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
check the man pages for the shells usually they list the length of the command line buffer. In 4.3 BSD, I believe the buffer was 10 kiB. -- which I thought was deliriously excessive back before I understood shell scripting and filename globbing. I have no clue what it is now, and also, these are GNU man pages, not AT&T-derived BSD man pages.
Wolfgang
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 28 March 2008 01:23, Wolfgang Woehl wrote:
Randall R Schulz:
There's no way for xargs to know about anything other than the kernel-imposed argument list size limit.
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
% egrep ARG_MAX /usr/include/linux/limits.h #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
Wolfgang
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Friday 28 March 2008 01:23, Wolfgang Woehl wrote:
Randall R Schulz:
There's no way for xargs to know about anything other than the kernel-imposed argument list size limit. Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
% egrep ARG_MAX /usr/include/linux/limits.h #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
And I believe there's also a maximum size to the number of pointers in the array char *argv[]. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 28 March 2008 11:05, Sam Clemens wrote:
Randall R Schulz wrote:
On Friday 28 March 2008 01:23, Wolfgang Woehl wrote:
Randall R Schulz:
There's no way for xargs to know about anything other than the kernel-imposed argument list size limit.
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
% egrep ARG_MAX /usr/include/linux/limits.h #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
And I believe there's also a maximum size to the number of pointers in the array char *argv[].
I only know how it was implemented in the old (very old) days, but the representation of the arguments + environment was simply as a blob of bytes with NUL bytes deliminting individual arguments and a pointer marking the end of the arguments and the beginning of the environment. The vectors of argument and environment value pointers was reconstituted in the user mode code on the "other side" of the exec call. If that's still the scheme being used, then it doesn't matter how many individual arguments and environment variables there are, just the number of bytes it takes to hold them all (including the delimiting / separating NULs). Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sam Clemens:
Randall R Schulz wrote:
On Friday 28 March 2008 01:23, Wolfgang Woehl wrote:
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
% egrep ARG_MAX /usr/include/linux/limits.h #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
Aha. Is there a decent method to calculate the size of any given argv[] and thereby learn whether a process will exceed and fail? Odd: ulimit -n gives 1024, grep OPEN_MAX limits.h gives 256. Also grep LINK_MAX limits.h gives 127 but I can create more.
And I believe there's also a maximum size to the number of pointers in the array char *argv[].
Couldn't find that one ... Wolfgang -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 29 March 2008 07:36, Wolfgang Woehl wrote:
Sam Clemens:
Randall R Schulz wrote:
On Friday 28 March 2008 01:23, Wolfgang Woehl wrote:
Where can I read the argument list size limit? I fail to see anything relevant with ulimit -a or in proc or in pam's limits.conf.
% egrep ARG_MAX /usr/include/linux/limits.h #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
Aha. Is there a decent method to calculate the size of any given argv[] and thereby learn whether a process will exceed and fail?
It's the number of bytes of argument + the number of arguments (the latter term accounts for the NUL byte at the end of each argument). The environment is identical to arguments for this purpose, so you need to add in the size of the environment (names and equal signs included) plus the number of environment variables. You can get that by simply using $(env |wc -c). That works because the newlines in the env output take the places of the NULs used internally. E.g.: % echo $(env |wc -c) 4392
Odd: ulimit -n gives 1024, grep OPEN_MAX limits.h gives 256. Also grep LINK_MAX limits.h gives 127 but I can create more.
Some of those limits are dynamically (run-time) configurable. ARG_MAX apparently is not.
And I believe there's also a maximum size to the number of pointers in the array char *argv[].
Couldn't find that one ...
I don't think there is one, but I'm not 100% sure about that.
Wolfgang
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Brian K. White wrote:
It's also possible for there to be discrepencies between the app being run by xargs, and the rest of the system. Maybe the shell and the kernel will tolerate up to 4k (I think it's more like 100 or 400 but no matter) so xargs generates 4k command lines, but maybe appfoo can only handle 1k ? That's not how it works.
Sure it is.
Xargs deals only in the maximum argument list limits (number of args and / or total argument bytes). While I can't say that no command imposes its own limits on the size of arguments lists,
You sure can't.
there's really no reason to do so and I know of no programs that have internal limits to the size of the argument list they will successfully process.
Within the very small world of a modern linux distribution where such things as *conf() exist and sticking to programs supplied by the vendor, maybe you are indeed hard pressed to find an app that doesn't break that assumption.
I'll side with Randall on this one.
Suffice it to say I have seen a larger world.
Not for core commands on any Unix or Linux distribution I've ever seen... and I've used and/or adminned more Unix distributions than I can count on both hands.
You have some body of experience, and an assumption that you haven't seen broken. That is fine and a perfectly reasonable and correct basis for continuing to operate from that assumption by default. Doing so is called being efficient and in tune with your environment. But do not mistake that for gospel.
It's a damned fine assumption. Any unix with core commands that violate his assumption is fundamentally broken.
Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks?
which "configure" is that? $ which configure $ Hmmm... it seems that "configure" is *NOT* a standard command. What do you think about that? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks?
which "configure" is that?
$ which configure $
Hmmm... it seems that "configure" is *NOT* a standard command.
What do you think about that?
I think anyone who sees dot-slash-configure and pretends not to know what it refers to has lost the focus of the discussion. Or if they really don't know then they are not qualified to have any opinion in this discussion. Sure, a lot of unix happened before 1991 when autoconf was first created, but is a person who got very experienced but then dropped out in '91 so thoroughly that they never enountered ./configure in the next _17_ years likely to be on an opensuse mail list ? I agree completely that within any particular bag of tools sold as part of one kit under one name will generally all adhere to the same set of limits across the board. I was pointedly alluding to code and/or bins that may not come from the same source as this or that particular xargs binary. Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Brian K. White wrote:
Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks?
which "configure" is that?
$ which configure $
Hmmm... it seems that "configure" is *NOT* a standard command.
What do you think about that?
I think anyone who sees dot-slash-configure and pretends not to know what it refers to has lost the focus of the discussion.
No...I was driving home a point. Although common, "configure" is a not a standard program
Or if they really don't know then they are not qualified to have any opinion in this discussion. Sure, a lot of unix happened before 1991 when autoconf was first created, but is a person who got very experienced but then dropped out in '91 so thoroughly that they never enountered ./configure in the next _17_ years likely to be on an opensuse mail list ?
Configure doesn't know diddly squat about an environment.. that's why it runs a million tests trying to figure out just what is and is not there, and what capabilities the system has, before trying to even create a Makefile, and usually, determine which CFLAGS to mandate, etc.
I agree completely that within any particular bag of tools sold as part of one kit under one name will generally all adhere to the same set of limits across the board.
I was pointedly alluding to code and/or bins that may not come from the same source as this or that particular xargs binary.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
----- Original Message -----
From: "Sam Clemens"
Brian K. White wrote:
Consider the implications of this for a while: Why does ./configure run an empirical test, trying progressively larger and larger command lines until it breaks?
which "configure" is that?
$ which configure $
Hmmm... it seems that "configure" is *NOT* a standard command.
What do you think about that?
I think anyone who sees dot-slash-configure and pretends not to know what it refers to has lost the focus of the discussion.
No...I was driving home a point.
Although common, "configure" is a not a standard program
And my point was not about ./configure itself at all. Totally missed the boat. But this is rather far off topic by now. I apologize to the list. -- Brian K. White brian@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sam Clemens wrote:
which "configure" is that?
$ which configure $
Hmmm... it seems that "configure" is *NOT* a standard command.
What do you think about that?
I think anyone who sees dot-slash-configure and pretends not to know what it refers to has lost the focus of the discussion.
No...I was driving home a point.
Although common, "configure" is a not a standard program
It is usually a script generated by the standard 'autoconf/automake' utilities. I tend to agree with Brian that dot-slash-configure is a well-known and fairly standard command - with various exceptions to prove the rule. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Per Jessen wrote:
Sam Clemens wrote:
which "configure" is that?
$ which configure $
Hmmm... it seems that "configure" is *NOT* a standard command.
What do you think about that? I think anyone who sees dot-slash-configure and pretends not to know what it refers to has lost the focus of the discussion.
No...I was driving home a point.
Although common, "configure" is a not a standard program
It is usually a script generated by the standard 'autoconf/automake' utilities. I tend to agree with Brian that dot-slash-configure is a well-known and fairly standard command - with various exceptions to prove the rule.
And that's part of the point. Configure is a shell script, not a compiled executable file, and it doesn't assume to know anything about the environment, because it's purpose is to test the environment so that a program knows what models to compile against (i.e. BSD vs SystemV style differences (most glaring in the strings library)...whats the name of the C compiler? cc or gcc, etc....and as alluded to... how big of a buffer is available to the standard shell(s)?). It's more of a helper tool than a standard app. And even if the entire world used only one CPU, it still couldn't be distributed as a binary... it MUST be a shell-script, precisely because there is so much variation in platforms out there.
/Per Jessen, Zürich
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2008-03-27 at 20:23 +0100, Per Jessen wrote: ...
I still feel certain I've done stuff like:
find <dir> -type f | xargs zgrep -i blah
and seen something like "too many arguments" or whatever it is, but of course I can't reproduce that now.
Check the "bugs" section of the man page, when it talks about somecommand | xargs -s 50000 echo | xargs -I '{}' -s 100000 rm '{}' it may be related to what you mention. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH7CMZtTMYHG2NR9URAsXCAJ47JyYAl9RhqsLkG3ZQSMfRoq0EZACglG9J oQ2Ra8EtczMLQQkEHa/uPOk= =rEsq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Wednesday 26 March 2008 12:07, Nick Zeljkovic wrote:
How can I delete these files w/o removing the folder itself?
find .thumbnails -type f -exec rm -rf {} \;
This could be very slow, since there must be a fork / exec for each file. Usually much faster is this:
% find dirName(s) {findCriteria} -print0 |xargs -0 rm
By doing this, xargs essentially "batches up" maximal (w.r.t. the argument size limit) sets of file names and invokes rm only as many times as necessary.
Note the use of find's -print0 option and the corresponding -0 option to xargs. This causes each file name to be delineated by a NUL character which means that files with spaces or other funky characters in their names won't mess things up.
That is excellent, world class advice. I will file that away. As Dostoevsky said, It's always rewarding to talk to a clever man. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-03-26 at 19:51 +0100, Istvan Gabor wrote:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
but got the error message: bash: /bin/rm: Argument list too long
The file number in the folder is ~ 60 000.
Why rm is not working?
Because the argument list is too long :-)
Is this a bug?
Nop. however, that the .thumbnails directory becomes so large, could be a bug.
How can I delete these files w/o removing the folder itself?
With some other command line, without a "*" on it. When you type "anycommand .thumbnails/large/*" the shell will expand that to something so large that it overflows the capacity for a single line. The typical solution is a combination of find and xargs and pipes, so that the delete command gets a file at a time. Or use midnight comander, I think it can handle it. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6qAutTMYHG2NR9URAkIiAJ9XRvfPNekKWTo7Owh3JWQiaWglSQCgh2lc GfxlJni38N4VFdir26f+6bw= =sAgJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 26 March 2008 12:51, Istvan Gabor wrote:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
< snip >
How can I delete these files w/o removing the folder itself?
Any particular reason you don't want to remove the directory? It will get recreated as needed (that is the behavior in 10.2 at least). -- Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Istvan Gabor wrote:
Hello:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
but got the error message: bash: /bin/rm: Argument list too long
The file number in the folder is ~ 60 000.
Why rm is not working? Is this a bug?
How can I delete these files w/o removing the folder itself?
ls -1 .thumbnails/large/* | while read f; do rm $f; done /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 26 March 2008 13:08, Per Jessen wrote:
Istvan Gabor wrote:
...
How can I delete these files w/o removing the folder itself?
ls -1 .thumbnails/large/* | while read f; do rm $f; done
This is as slow as the find -exec approach and vulnerable to files with spaces and other special characters in their names. The find + xargs approach is still the best for circumstances like this. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Randall R Schulz wrote:
On Wednesday 26 March 2008 13:08, Per Jessen wrote:
Istvan Gabor wrote:
...
How can I delete these files w/o removing the folder itself?
ls -1 .thumbnails/large/* | while read f; do rm $f; done
This is as slow as the find -exec approach and vulnerable to files with spaces and other special characters in their names.
Sigh. Allright, how about: ls -1 .thumbnails/large/* | while read f; do rm "$f"; done
The find + xargs approach is still the best for circumstances like this.
Not without knowing the exact circumstances - it does work very well of course, but then so does my suggestion, given the right set of circumstances :-) /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 26 March 2008 13:29, Per Jessen wrote:
Randall R Schulz wrote:
On Wednesday 26 March 2008 13:08, Per Jessen wrote:
Istvan Gabor wrote:
...
How can I delete these files w/o removing the folder itself?
ls -1 .thumbnails/large/* | while read f; do rm $f; done
This is as slow as the find -exec approach and vulnerable to files with spaces and other special characters in their names.
Sigh. Allright, how about:
ls -1 .thumbnails/large/* | while read f; do rm "$f"; done
That's probably sufficient, though to be extremely nitpicky, Unix file systems allow newlines in file names. The use of the shell's "read" builtin cannot be made to accommodate that, while find with -print0 and xargs with -0 handle absolutely any file name that will ever appear on a Unix (or Linux or *BSD, etc.) system. And while people rarely create such things, they do sometimes come into existence (perhaps most often due to scripting errors!).
The find + xargs approach is still the best for circumstances like this.
Not without knowing the exact circumstances - it does work very well of course, but then so does my suggestion, given the right set of circumstances :-)
I'm not convinced. It's longer and harder to type (personally, I frequently mess up interactive input of shell control syntax, most often leaving out the "do" or "then" keywords, which just makes a mess of things). And while I don't know how many files need to be processed before the xargs approach significantly outstrips the iterated invocation rm approach, it is probably not all that many.
/Per Jessen, Zürich
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
How can I delete these files w/o removing the folder itself?
ls -1 .thumbnails/large/* | while read f; do rm $f; done
This won't work. The problem is the * which the shell expands BEFORE the command is called. There is a limit on the number of characters that can be passed to execv(2). That is xargs(1) purpose: to do the minimum number of forks while staying within execv(2) limits.
Is this an exercise? What's wrong with "rm -rf .thumbnails/large" followed by "mkdir .thumbnails/large"?
What's wrong with it is that is may not regenerate the directory with the same ownership or permissions. The original owner also didn't say whether they wanted the files beginning with a period deleted or the files deleted recursively. The original poster said "rm .thumbnails/large/*" and just to be perverse, I'm going to take him at his literal word. So in that case, no period files and no recursion. Here is the incantation: (cd .thumbnails/large; find . -maxdepth 1 -type f ! -regex '^\./\..*' -print0 | xargs --null rm -f) The reason that the () are used is that it is executed in a subshell (the Bash shell forks itself, runs the commands, then exits) and running in a subshell leaves you in the same directory as you started. The reason that "-maxdepth 1 is used is to stop recursion. "-type f" prevents looking at directories. "! -regex '^\./\..*'" says to not match files that begin with "./." (i.e., dot files). The reason that "-print0" and "--null" are used is to allow file names with spaces in them to be deleted. The reason that "-f" is passed to "rm" is so files without the write bit on are also removed (assuming you have permission). I often using xargs with etags. Witness, rm TAGS; find . -name '*.[hc]' -print0 | xargs --null etags -a for Emacs tags. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2008-03-26 at 19:51 +0100, Istvan Gabor wrote:
How can I delete these files w/o removing the folder itself?
Is this an exercise? What's wrong with "rm -rf .thumbnails/large" followed by "mkdir .thumbnails/large"? It is by far and away the fastest option Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
First, thank you all for your help.
How can I delete these files w/o removing the folder itself?
Is this an exercise? What's wrong with "rm -rf .thumbnails/ large" followed by "mkdir .thumbnails/large"?
It can occur that I have to delete only files with a similar pattern, eg 'rm aaaaa*'. In this case I can't delete the whole directory. IG ui: Te már megnézted, hogy diszlexiásak-e a gyerekeid? Találtam egy szülőknek szóló diszlexiatesztet, ingyenes oldal, nem kerül semmibe. Ne várj, töltsd ki te is! Kattints ide: www.diszlexiateszt.hu/i.php?id=fr080325 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2008-03-27 at 12:02 +0100, Istvan Gabor wrote:
How can I delete these files w/o removing the folder itself?
Is this an exercise? What's wrong with "rm -rf .thumbnails/ large" followed by "mkdir .thumbnails/large"?
It can occur that I have to delete only files with a similar pattern, eg 'rm aaaaa*'. In this case I can't delete the whole directory.
The names of the files in that directory are senseless, they don't give a clue as to what they are: 0694ea8c9e6477a095825eb551cf28f2.png 4b9cd3078b260f5f03f2e610f732f0f6.png 9ac2860069d366c54423ecd73798a05a.png c9cfb18168937465468927a0b301e2dc.png 16e952d9bf2b28310c12ce8c6796c544.png 4c94d243010d50921c2f70b001dc508d.png a1011ad9c15ff97c57e1d1c9765e265b.png cd8caec9e7653183aaa2024d56a38866.png 227d1875f47d981f3517ffc09f1fb893.png 4d9218d516505654d7afda51782df615.png a120e43e94f91fd80e1535b5c9a8aaeb.png cea7b6c9a8e508724f1547847caa68ee.png So go ahead, find a pattern of what you want to delete / not delete... :-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH642PtTMYHG2NR9URAjdMAJ93eZkERbjo8Y6veTDASfTWf1J+wgCeNxgb 9NX6uvmVhZnrtXdURYFU2ME= =2aZI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Thursday 2008-03-27 at 12:02 +0100, Istvan Gabor wrote:
How can I delete these files w/o removing the folder itself?
Is this an exercise? What's wrong with "rm -rf .thumbnails/ large" followed by "mkdir .thumbnails/large"?
It can occur that I have to delete only files with a similar pattern, eg 'rm aaaaa*'. In this case I can't delete the whole directory.
The names of the files in that directory are senseless, they don't give a clue as to what they are:
0694ea8c9e6477a095825eb551cf28f2.png 4b9cd3078b260f5f03f2e610f732f0f6.png 9ac2860069d366c54423ecd73798a05a.png c9cfb18168937465468927a0b301e2dc.png 16e952d9bf2b28310c12ce8c6796c544.png 4c94d243010d50921c2f70b001dc508d.png a1011ad9c15ff97c57e1d1c9765e265b.png cd8caec9e7653183aaa2024d56a38866.png 227d1875f47d981f3517ffc09f1fb893.png 4d9218d516505654d7afda51782df615.png a120e43e94f91fd80e1535b5c9a8aaeb.png cea7b6c9a8e508724f1547847caa68ee.png
So go ahead, find a pattern of what you want to delete / not delete...
Well, I haven't stated directly but certainly meant that the directory can be any directory with losts of files, not only .thumbnails/large. IG ui: Te már megnézted, hogy diszlexiásak-e a gyerekeid? Találtam egy szülőknek szóló diszlexiatesztet, ingyenes oldal, nem kerül semmibe. Ne várj, töltsd ki te is! Kattints ide: www.diszlexiateszt.hu/i.php?id=fr080325 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Thu, 27 Mar 2008, Carlos E. R. wrote:-
The names of the files in that directory are senseless, they don't give a clue as to what they are:
They may not give a clue as to what they are, but they're not quite senseless. From what I can see, the names are constructed from the md5sum of the original image, and stored in .png format. Of course, that won't help you in trying to find a pattern to their names, since there essentially isn't one. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-P2 @ ~100Mnodes RC5-72 @ ~15Mkeys SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit | openSUSE 11.0a1 SUSE 10.1 64bit | openSUSE 10.2 64bit | openSUSE 10.3 64bit RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2008-03-27 at 14:44 -0000, David Bolt wrote:
On Thu, 27 Mar 2008, Carlos E. R. wrote:-
The names of the files in that directory are senseless, they don't give a clue as to what they are:
They may not give a clue as to what they are, but they're not quite senseless. From what I can see, the names are constructed from the md5sum of the original image, and stored in .png format. Of course, that won't help you in trying to find a pattern to their names, since there essentially isn't one.
Obviously, they have a meaning to the machine. There will be an index somewhere. The checksum is to ensure the file has not changed meanwhile. But they have no meaning to the human, no easy way to know which file they refer to unless you do have a look at them. Deleting them all is OK, they will be recreated as needed. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH6/oVtTMYHG2NR9URAm+kAJ9a66n/bgmu8Vtlvy4ydKGbAOnH0gCgg/2z 4feEYxIYW/8WkmwbkNcurx8= =b1Ql -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Istvan Gabor wrote:
Hello:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
D=.thumbnails/large rm -rf $D mkdir $D -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 26 March 2008 21:08:40 Sam Clemens wrote:
Istvan Gabor wrote:
Hello:
I've just realized that my .thumbnails folder occupies 3.3 Gbyte space. I wanted to empty it by: rm .thumbnails/large/*
D=.thumbnails/large rm -rf $D mkdir $D
I just delete the whole directory. It will be made again the next time thumbnails are created. rm -rf ~/.thumbnails. I guess a more robust solution would be to have cron run a script that deletes old thumbnails once the size is over some maximum? Just haven't had a need for that. Alvin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (17)
-
Alvin -
Anders Johansson -
Brian K. White -
Carlos E. R. -
David Bolt -
Don Raboud -
Istvan Gabor -
jdd sur free -
John Andersen -
Nick Zeljkovic -
Per Jessen -
Randall R Schulz -
Sam Clemens -
Scott Simpson -
Sloan -
Sylvester Lykkehus -
Wolfgang Woehl