Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've seen a good one -- actually got asked it in a phone screen I did last year:

"How would you recursively delete all files with extension 'mp3' in a given directory tree?"

The (simplest) correct answer (I know) is

    find /path/to/wherever -name "*.mp3" -exec rm -fv {} \;
Maybe that's more of a pons asinorum, I suppose, but then isn't a pons asinorum precisely what a fizzbuzz question is meant to be?


Alternatively, you can just use

    find /path/to/wherever -name "*.mp3" -delete


The simplest would be

    find /path/to/wherever -name "*.mp3" -delete
This works at least in GNU find and FreeBSD.


At which point I'd argue that using -exec with an appropriate command is simpler, in the general case, than using one of find(1)'s many, many, many twiddly little command-line arguments. Granted, -exec spawns a process per file, but processor cycles are cheaper than brain cycles, &c., &c.


That seems like a recipe for holy-war between those who kind-of like xargs and those who think find | xargs is an abomination.


Can't we

    cd /path/to/wherever
    rm -rf *.mp3

?


You have stumbled squarely into the tripwire implicit in that question; "rm -rf *.mp3" ignores directories whose names don't end in ".mp3", and deletes those whose do.


It's supposed to be recursive. That would only delete the files in the current directory, not subdirectories as well.


-r is the 'recursive' flag.


Yes, but it doesn't do what you think it does. Feel free to try it for yourself if you don't believe me.


  find path -iname "*.mp3" -print0 | xargs -0 rm -fv


I'd give half marks for this, because it optimizes (meaninglessly) for processes, at the risk of ending up with "rm: Too many arguments" in a directory tree containing a sufficiently large number of MP3 files.


xargs knows the maximum command line length, and will invoke the program more than once if necessary. One of the points of xargs is to break up invocations of a program into chunks of arguments that fit in one maximum length command line.

  xargs reads items
  from  the  standard  input, delimited by blanks (which can be protected
  with double or single quotes or a backslash) or newlines, and  executes
  the  command (default is /bin/echo) one or more times with any initial-
  arguments followed by items read from standard input.

  --max-chars=max-chars
  -s max-chars
         Use at most max-chars characters per command line, including the
         command  and  initial-arguments and the terminating nulls at the
         ends of the argument strings.  The largest allowed value is sys‐
         tem-dependent,  and  is  calculated as the argument length limit
         for exec, less the size of your environment, less 2048 bytes  of
         headroom.   If this value is more than 128KiB, 128Kib is used as
         the default value; otherwise, the default value is the  maximum.
         1KiB is 1024 bytes.


Well, how about that! It could be that I formed my opinion regarding xargs before it got that smart, or it could be the old Red Hat boxes on which I mostly learned my craft didn't bother compiling in that capability. Either way, I'm glad to know about it now, and thank you very kindly for pointing it out to me!


breaking up the input into multiple executions is feature #1 for xargs and has been present since PWB UNIX in 1977


Then perhaps I'm thinking of "rm -f `find ...`". In any case, thanks for pointing it out; I learned something new today.


Well put


zero marks for not understanding how xargs works


And a resounding "no hire" for privileging snark over substance.


wouldn't take an offer from a place where sysadmins wouldn't read a man page to verify a candidate's answer




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: