Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Hmm... I thought this issue was fixed in linux like 10 years ago. 4000 files really doesn't seem too excessive and should be able to be removed no problem. So this issue clearly exists in OS X - maybe not in ubuntu. Developing on OS X and deploying to ubuntu

Is there a system level workaround in either environment? I really don't want to have to think about this issue for such a small number of files? Does this issue still exist in linux specifically ubuntu?

share|improve this question
    
What are you asking about? Mac OS X or Ubuntu? –  Wuffers Feb 20 '12 at 3:05
1  
uhh... i think the title is pretty clear –  timpone Feb 20 '12 at 3:09
1  
And then you went and muddled it with the last question –  soandos Feb 20 '12 at 3:17
    
Please revise your question. It is not clear what system you're asking about, whether you're asking about the cause or for a workaround. –  Daniel Beck Feb 20 '12 at 6:19
    
@timpone: No, it isn't. You ask about Mac OS X in the title but your question itself only mentions Ubuntu. –  Wuffers Feb 20 '12 at 15:06

3 Answers 3

This is not an issue but a limit. You can use something like this:

find ./ -exec rm -rf {} \;

Or what is the matter of not using an alternative that does the job?

share|improve this answer
    
hmm.... maybe just alias rm -rf to that? –  timpone Feb 22 '12 at 3:26

While I can't speak for other *nixs, AFAIK, this "issue" has always existed in Mac OS X.

ARG_MAX is defined as the following in /usr/include/sys/syslimits.h:

#define ARG_MAX   (256 * 1024)  /* max bytes for an exec function */

sysctl kern.argmax returns:

kern.argmax: 262144

(This is in Mac OS X 10.7.3; many of these types of limits have been increased gradually over the course of the lifetime of OS X).

share|improve this answer
    
thx, helpful to know –  timpone Feb 22 '12 at 3:35

This is still a problem on all Unixes I know of, as well as Windows. It's really a limit on the number of bytes being passed on the command line, not the number of files or whatever.

Try getconf ARG_MAX to see the limit (in bytes) for your Unix. You can use the xargs command to work around such problems.

share|improve this answer
    
xargs tends to be SLOW - just more surprised this is still an issue than anything. such a common procedure. ugh... –  timpone Feb 20 '12 at 3:21
    
This particular problem doesn't pop up on Windows all that often, because the shell doesn't expand wildcards, it's up to each app to do that. –  afrazier Feb 22 '12 at 1:02
    
Yeah, but I'd also say that a big reason for this being the case is that Windows has traditionally had sub-par shell capabilities, so no one likes to use it much. That said, I have run into this problem on Windows while compiling a project with a big list of lengthy pathnames being passed to the compiler executable. –  jjlin Feb 22 '12 at 1:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.