From: Michael G Schwern Date: 23:03 on 01 Nov 2007 Subject: find . -print0 -name 'foo' | xargs rm I want to delete a bunch of unnecessary text files in a pile of NOVA episodes I have archived. Ok, no problem... $ cd ~/Movies/NOVA/ $ find . -name '*.txt' | xargs rm rm: cannot remove `./NOVA': No such file or directory rm: cannot remove `-': No such file or directory rm: cannot remove `Search': No such file or directory rm: cannot remove `For': No such file or directory rm: cannot remove `A': No such file or directory rm: cannot remove `Safer': No such file or directory rm: cannot remove `Cigarette': No such file or directory Oh that's right, in Unix nobody would ever possibly put a space in a filename (a hate for later). So I need to separate things with a null byte, ok... $ find . -print0 -name '*.txt' | xargs -0 rm Whoopsie, everything's deleted. 10 gigs of fine public educational video, gone. Turns out putting -print0 first instead of last causes some sort of crazy find switch boolean madness to short circuit and everything becomes true. I'm sure there's some perfectly self-consistent, logical and yet still TOTALLY INSANE reason why this is so making find the well-dressed, but completely off his rocker guy on the bus trying to convince you to remove the plastic border from around your license plate. To save fuel. Because your car will weigh less. [1] Makes perfect sense, right? Hate. [1] No joke, he had little pamphlets with the math and everything.
From: Michael Jinks Date: 23:24 on 01 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Thu, Nov 01, 2007 at 04:03:20PM -0700, Michael G Schwern wrote: > > $ find . -print0 -name '*.txt' | xargs -0 rm I hates xargs. It has its place I guess, but this ain't it, and souping up GNU find to (try to, sometimes) feed nice path names to xargs seems only to have made GNU find that much more hateful. Since I learned how to make -exec do my bidding, I think I can count on one hand the number of times I've had to hate xargs. Efficiency be damned. But yeah, you do want to put it after any test conditions... ...or, hate zsh, and wrap your find command in a $() subshell, but with zsh you get a whole new book of hates to read from into the wee hours. I'm not going to get started, it's my turn to cook dinner tonight.
From: A. Pagaltzis Date: 23:56 on 01 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm * Michael Jinks <mjinks@xxxxxxxx.xxx> [2007-11-02 00:30]: > On Thu, Nov 01, 2007 at 04:03:20PM -0700, Michael G Schwern wrote: > > > > $ find . -print0 -name '*.txt' | xargs -0 rm > > I hates xargs. It has its place I guess, but this ain't it, > and souping up GNU find to (try to, sometimes) feed nice path > names to xargs seems only to have made GNU find that much more > hateful. > > Since I learned how to make -exec do my bidding, I think I can > count on one hand the number of times I've had to hate xargs. Except that's a red herring, because if he had but `-exec rm \;` where he put his `-print0`, the exact same thing would have happened. Regards,
From: H.Merijn Brand
Date: 00:08 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On Fri, 2 Nov 2007 00:56:49 +0100, "A. Pagaltzis" <pagaltzis@xxx.xx> wrote:
> * Michael Jinks <mjinks@xxxxxxxx.xxx> [2007-11-02 00:30]:
> > On Thu, Nov 01, 2007 at 04:03:20PM -0700, Michael G Schwern wrote:
> > >
> > > $ find . -print0 -name '*.txt' | xargs -0 rm
> >
> > I hates xargs. It has its place I guess, but this ain't it,
> > and souping up GNU find to (try to, sometimes) feed nice path
> > names to xargs seems only to have made GNU find that much more
> > hateful.
> >
> > Since I learned how to make -exec do my bidding, I think I can
> > count on one hand the number of times I've had to hate xargs.
>
> Except that's a red herring, because if he had but `-exec rm \;`
> where he put his `-print0`, the exact same thing would have
> happened.
Would it? Is {} the default arg somehow?
find . -exec rm {} \; -name '*.txt'
^^
would have given you at least loads of errors about the directories
that cannot be removed with rm :)
From: Michael G Schwern
Date: 03:29 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
H.Merijn Brand wrote:
> Would it? Is {} the default arg somehow?
>
> find . -exec rm {} \; -name '*.txt'
> ^^
>
> would have given you at least loads of errors about the directories
> that cannot be removed with rm :)
Got those with xargs, too, which was when I realized something had gone
horribly, horribly wrong.
From: Michael Jinks Date: 00:09 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Fri, Nov 02, 2007 at 12:56:49AM +0100, A. Pagaltzis wrote: > * Michael Jinks <mjinks@xxxxxxxx.xxx> [2007-11-02 00:30]: > > On Thu, Nov 01, 2007 at 04:03:20PM -0700, Michael G Schwern wrote: > > > > Since I learned how to make -exec do my bidding, I think I can > > count on one hand the number of times I've had to hate xargs. > > Except that's a red herring, because if he had but `-exec rm \;` > where he put his `-print0`, the exact same thing would have > happened. I wasn't trying to debug his find usage; he'd already noted that in his initial posting. I was hating on xargs. Hey, what do you know, I still am. Hate hate hate.
From: David Cantrell
Date: 15:02 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On Fri, Nov 02, 2007 at 12:56:49AM +0100, A. Pagaltzis wrote:
> > On Thu, Nov 01, 2007 at 04:03:20PM -0700, Michael G Schwern wrote:
> > > $ find . -print0 -name '*.txt' | xargs -0 rm
> Except that's a red herring, because if he had but `-exec rm \;`
> where he put his `-print0`, the exact same thing would have
> happened.
This is what happened:
find
ok, I'm going to find something
.
in the current directory
-print0
I'll print its name (or exec rm, or ...)
-name '*.txt'
and see if it is called *.txt
the end
and then do nothing. i wonder why the user wanted to see what it's
name was and then not do anything about it. <shrug>
Perhaps the confusion comes from the use of -blah for keywords in the
find mini-language instead of just a plain unadorned blah, which makes
it look like you're giving a load of options instead of a sequence of
instructions. That it's a mini-language becomes obvious when you find
that there's AND, OR and NOT operators, (bracketing) for precedence, and
so on.
From: Martin Ebourne Date: 23:32 on 01 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Thu, 2007-11-01 at 16:03 -0700, Michael G Schwern wrote: > Oh that's right, in Unix nobody would ever possibly put a space in a filename > (a hate for later). So I need to separate things with a null byte, ok... > > $ find . -print0 -name '*.txt' | xargs -0 rm > > Whoopsie, everything's deleted. 10 gigs of fine public educational video, > gone. Turns out putting -print0 first instead of last causes some sort of > crazy find switch boolean madness to short circuit and everything becomes true. > > I'm sure there's some perfectly self-consistent, logical and yet still TOTALLY > INSANE reason why this is so making find the well-dressed, but completely off Yes, of course, this is how it's always worked. Because you're not really giving options to find, but an expression, just happens that most of the operators start with hyphen. So the -print/-print0/-ls/-exec/whatever is evaluated at the point in the expression where it appears. Too bad for you the first operator in an expression is of course always executed by definition. Sure, I can see why this is hateful and totally surprising to anyone new to find, it is one of those tools where the the options/arguments are non-standard and don't behave like other tools. Unlike dd, tar, ps, and other tools where the non-standardness is totally gratuitous and very crap, at least find is deviating for good reason. One of the rules to save your bacon, just like you should always 'select ... from ... where ...' before you 'delete from ... where ...', 'find ... -print' before you 'find ... -exec rm \;' or xargs equivalent. Cheers, Martin.
From: Michael G Schwern Date: 03:20 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm Martin Ebourne wrote: > One of the rules to save your bacon, just like you should always > 'select ... from ... where ...' before you 'delete from ... where ...', > 'find ... -print' before you 'find ... -exec rm \;' or xargs equivalent. No, you turn off autocommit, you maniac. Which reminds me, I'd long ago written a "trash" script to provide an undoable rm. $ cat ~/bin/trash #!/bin/sh mv --backup=numbered "$@" ~/.Trash/ Maybe I should remember to use that.
From: Martin Ebourne Date: 08:10 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Thu, 2007-11-01 at 20:20 -0700, Michael G Schwern wrote: > Martin Ebourne wrote: > > One of the rules to save your bacon, just like you should always > > 'select ... from ... where ...' before you 'delete from ... where ...', > > 'find ... -print' before you 'find ... -exec rm \;' or xargs equivalent. > > No, you turn off autocommit, you maniac. Actually I usually do both. After all, it's usually still easier to be sure you're deleting the right stuff than it is to be sure you haven't deleted the wrong stuff. Cheers, Martin.
From: Peter da Silva
Date: 23:35 on 01 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On 01-Nov-2007, at 18:03, Michael G Schwern wrote:
> $ find . -print0 -name '*.txt' | xargs -0 rm
That's a mistake.
> Whoopsie, everything's deleted. 10 gigs of fine public educational
> video,
> gone. Turns out putting -print0 first instead of last causes some
> sort of
> crazy find switch boolean madness to short circuit and everything
> becomes true.
Nope, the result of the expression is exactly the same as before.
Consider the difference between "find ... -print -exec something '{}'
';'" and "find ... -exec something '{}' ';' -print".
The former prints out all the files it's applying "something" to, so
you know what you somethinged.
The latter prints out all the files for which "something" succeeded,
so you know what the something files are.
There's nothing crazy about it at all. It's not a flag, if it was a
flag it would be a single character (this is a good decade and a hlaf
before that crazy GNU getopt shit). It's a term in an expression. The
hateful thing isn't that it behaved that way, it's that they put a
"-" in front of the terms in the expression instead of something else
like "+" or "=" so you wouln't think it was some kind of long format
option. They should have been able to see 15 years into the future
and realize that when people started using versions of getopt
(something else that didn't exist when find was written) that
supported long options that people would decide that find was just
doing the same thing.
And then they should have realised that those crazy GNU guys would
make the final "-print" optional, so it looked even more like a flag.
Because it's not.
And I'm really not sure whether I'm being sarcastic there or not. The
"-" business was asking for trouble, and there's always been some
people complaining about find being some kind of exception because it
uses those crazy long options. It's not, it's consistent, it's just
hateful.
But it took the Free Software Foundation to pump the hate up to 11,
and I can't blame them for not realizing they were going to.
(That kind of thing is why I used "+" to indicate long options when I
was playing around with the things, so they didn't get confused with
short ones)
From: A. Pagaltzis Date: 00:16 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm * Peter da Silva <peter@xxxxxxx.xxx> [2007-11-02 00:40]: > It's a term in an expression. The hateful thing isn't that it > behaved that way, it's that they put a "-" in front of the > terms in the expression instead of something else like "+" or > "=" so you wouln't think it was some kind of long format > option. Well find will get on your case if you mix paths and predicates anyway. So they should have done what sed and awk do and made expression a string passed either as first parameter or as an argument to the an -e switch. Because find is a little language every bit as much as sed, if not awk. It just quite doesn't want to think of itself that way. Regards,
From: Peter da Silva Date: 00:24 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 01-Nov-2007, at 19:16, A. Pagaltzis wrote: > Well find will get on your case if you mix paths and predicates > anyway. Yes, they could have just had one token to say "that's the last file, the rest is an expression". That would also have worked. > So they should have done what sed and awk do and made > expression a string passed either as first parameter > or as an argument to the an -e switch. That leads to quoting hell, which find is trying to avoid. Also, find predates sed and I think awk as well. > Because find is a little language > every bit as much as sed, if not awk. It just quite doesn't want > to think of itself that way. It thinks of itself that way just fine. It's not responsible for what other people think it is.
From: Phil Pennock Date: 00:52 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 2007-11-01 at 19:24 -0500, Peter da Silva wrote: > On 01-Nov-2007, at 19:16, A. Pagaltzis wrote: >> Well find will get on your case if you mix paths and predicates >> anyway. > > Yes, they could have just had one token to say "that's the last file, the > rest is an expression". That would also have worked. -prune is an action, not a selector. If people learn -prune, I find (hah!) that they suddenly start to understand find(1) better, as things click. find blah -whatever -prune -o -whichever -print Eg: $ find /dev \( -type b -o -type c \) -prune -o -print This is informative on FreeBSD: $ find -L /dev \( -type b -o -type c \) -prune -o \! -type d -print (spots the socket) whilst this Ubuntu derivative has so much crap littering about the filesystem that it's necessary to instead: $ find /dev \( -type b -o -type c \) -prune -o \! \( -type d -o -type l \) -print Now, if someone seems to be doing well in an interview (understanding quoting is done by the shell would be a nice enough change) then it's fun to check if they can spot the security hole in $ find /tmp -blah -print0 | xargs -0 rm -- And yeah, if you know the answer then, uhm, can I tempt you to apply for a job? :)
From: A. Pagaltzis
Date: 02:34 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
* Peter da Silva <peter@xxxxxxx.xxx> [2007-11-02 01:31]:
> On 01-Nov-2007, at 19:16, A. Pagaltzis wrote:
>> So they should have done what sed and awk do and made
>> expression a string passed either as first parameter or as an
>> argument to the an -e switch.
>
> That leads to quoting hell, which find is trying to avoid.
Leads to?
find . \( -name 'foo*' -o -name '*bar' \) -prune -o -exec rm {} \;
You are already roasting, buddy.
Regards,
From: Peter da Silva
Date: 03:40 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On 01-Nov-2007, at 21:34, A. Pagaltzis wrote:
> find . \( -name 'foo*' -o -name '*bar' \) -prune -o -exec rm {} \;
There's no nested quotes there. That's barely quoting heck.
It's when you find yourself faced with 'if("'"$A"'" = $0)' and you
need to put THAT inside `` and you're trying to remember if
"`..."..."...`" parses as ("`...")(...)("...`") or ("`(..."..."...)
`") (IYKWIMAITYD) and you decide to shove part of it into a shell
function to avoid the problem. THEN you're in quoting hell.
Because they didn't invent shell functions until the '80s.
From: Aaron Crane Date: 00:56 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm Peter da Silva writes: > there's always been some people complaining about find being some > kind of exception because it uses those crazy long options. It's > not, it's consistent, it's just hateful. Well, it's consistent with itself, sure, but hardly with the rest of Unix of that vintage. I'm reminded of Mark Pilgrim's line that "Interoperating only with yourself is just a standards-compliant form of masturbation." The manual for Fifth Edition (where I think find first appeared in its modern form) has apparently been lost, but find(1) in Sixth Edition says: .sh BUGS Syntax should be reconciled with .it if. By the release of Seventh Edition, that's been upgraded to this: .SH BUGS The syntax is painful. Oh how true.
From: Peter da Silva Date: 03:32 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 01-Nov-2007, at 19:56, Aaron Crane wrote: > .sh BUGS > Syntax should be reconciled with > .it if. The way "if" and kin worked in v6 sucked dead hairy wombats, though.
From: Michael G Schwern
Date: 03:27 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
Peter da Silva wrote:
> On 01-Nov-2007, at 18:03, Michael G Schwern wrote:
>> $ find . -print0 -name '*.txt' | xargs -0 rm
>
> That's a mistake.
THANK YOU CAPTAIN OBVIOUS!
>> Whoopsie, everything's deleted. 10 gigs of fine public educational
>> video,
>> gone. Turns out putting -print0 first instead of last causes some
>> sort of
>> crazy find switch boolean madness to short circuit and everything
>> becomes true.
>
> Nope, the result of the expression is exactly the same as before.
>
> Consider the difference between "find ... -print -exec something '{}'
> ';'" and "find ... -exec something '{}' ';' -print".
That sort of "pin the quotes on the expression" game you have to play with
-exec that I always get wrong is why I use xargs.
> The former prints out all the files it's applying "something" to, so you
> know what you somethinged.
>
> The latter prints out all the files for which "something" succeeded, so
> you know what the something files are.
>
> There's nothing crazy about it at all. It's not a flag, if it was a flag
> it would be a single character
That you say that like it should be obvious is, in and of itself, crazy.
> It's a term in an expression. The hateful
> thing isn't that it behaved that way, it's that they put a "-" in front
> of the terms in the expression instead of something else like "+" or "="
> so you wouln't think it was some kind of long format option.
Bingo. Different things should look different.
> They should
> have been able to see 15 years into the future and realize that when
> people started using versions of getopt (something else that didn't
> exist when find was written) that supported long options that people
> would decide that find was just doing the same thing.
Or, maybe, 15 years later, we'd be using something better than find.
From: Peter da Silva Date: 03:42 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 01-Nov-2007, at 22:27, Michael G Schwern wrote: > That you say that like it should be obvious is, in and of itself, > crazy. When find was written, it was obvious. That it's become crazy is hateful. > Or, maybe, 15 years later, we'd be using something better than find. You have a C compiler, write one.
From: Jonathan Stowe Date: 08:23 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Thu, 2007-11-01 at 18:35 -0500, Peter da Silva wrote: > And then they should have realised that those crazy GNU guys would > make the final "-print" optional, so it looked even more like a flag. > Because it's not. Yes it was at this point that I started to realize something was wrong with GNU find. /J\
From: Martin Ebourne Date: 09:35 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm Jonathan Stowe <jns@xxxxxxxxx.xxx> wrote: > On Thu, 2007-11-01 at 18:35 -0500, Peter da Silva wrote: >> And then they should have realised that those crazy GNU guys would >> make the final "-print" optional, so it looked even more like a flag. >> Because it's not. > > Yes it was at this point that I started to realize something was wrong > with GNU find. Not to mention making the pathname optional. Yes, I had a cron script that passed a glob into the pathname that =20 happened to resolve to nothing one day due to a change elsewhere. So =20 GNU find guessed I meant . (which was also /) and proceeded to delete =20 all the files on my harddisk while I wasn't there to stop it. =20 Fortunately it only got as far as /lib/libc.so.1 and then rm stopped =20 working. Still, left one hell of a mess to recover from. Yes, thanks =20 GNU. Was GNU really the first to make -print optional though? It's been =20 optional on most unixen for a long time, certainly HP-UX from nearly =20 20 years ago, SYS V, BSD (not sure when from), OS/F, IRIX. Optional =20 pathname though, certainly didn't work on any of those (excluding =20 modern BSD). Cheers, Martin.
From: Peter da Silva
Date: 13:30 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On 02-Nov-2007, at 04:35, Martin Ebourne wrote:
> Was GNU really the first to make -print optional though? It's been
> optional on most unixen for a long time,
Errrr... no?
> certainly HP-UX from nearly 20 years ago,
If so it was HP's own perversion.
> SYS V,
Not up through SVR2.
> BSD (not sure when from),
Not before the '90s.
> OS/F,
What's that? OSF/1? Which one?
> IRIX.
Irix is almost as clabbered as HP/UX, in completely different ways.
Googling tells me that POSIX added it, but not when:
Assuming the presence of -print was added to correct a
historical pitfall that plagues novice users, it is entirely upwards-
compatible from the historical System V find utility. In its simplest
form ( find directory), it could be confused with the historical BSD
fast find. The BSD developers agreed that adding -print as a default
expression was the correct decision and have added the fast find
functionality within a new utility called locate.
However, the FreeBSD man pages say that the locate utility was added
for 4.4BSD, in the early '90s, so that's was when it happened.
The oldest GNU man pages also have this behavior, but I can't find
revision history going back before Findutils 4.
From: Smylers Date: 09:57 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm Peter da Silva writes: > There's nothing crazy about [-print] at all. It's not a flag, if it > was a flag it would be a single character Then there's things like like -maxdepth. FreeBSD find doesn't include it in the list of 'options', instead categorizing it as a 'primary', but it carries this caveat: If any -maxdepth primary is specified, it applies to the entire expression even if it would not normally be evaluated. So it has the behaviour of an option, but the appearance of a term in the expression. In the circumstances it isn't surprising that some people might get confused about the rules applying to other terms. GNU find is different (of course). It does classify -maxdepth as an 'option'. But it isn't in the list of 'options' that find takes (presumably that would be too simple); instead it sub-classifies the 'expressions' (that follow options in a find command) into 'tests', 'actions', and, um 'options'. Meaning the manpage has two lists of 'options'. Nice. The introduction to expression-options suggests: ... for clarity, it is best to place them at the beginning of the expression. A warning is issued if you don't do this. And indeed a warning is issued: $ find . -name '*.txt' -maxdepth 1 find: warning: you have specified the -maxdepth option after a non-option argument -name, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments. Hmmm, before "other arguments", eh? That suggests putting it as the very first argument -- let's try that: $ find -maxdepth 1 . -name '*.txt' find: paths must precede expression Usage: find [-H] [-L] [-P] [path...] [expression] So even its own error messages get confused by this stuff! Hate! Smylers
From: Peter da Silva Date: 13:36 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 02-Nov-2007, at 04:57, Smylers wrote: > Peter da Silva writes: >> There's nothing crazy about [-print] at all. It's not a flag, if it >> was a flag it would be a single character > Then there's things like like -maxdepth. The QNX man pages for find document where each option came from. That's useful. They list -maxdepth as (GNU). QNX added a "-NOP" to turn off the automatic "-print". :)
From: David Cantrell Date: 15:08 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On Thu, Nov 01, 2007 at 06:35:57PM -0500, Peter da Silva wrote: > There's nothing crazy about it at all. It's not a flag, if it was a > flag it would be a single character (this is a good decade and a hlaf > before that crazy GNU getopt shit). Even without that crazy GNU getopt shit -print could be -p -r -i -n -t.
From: Chris Devers
Date: 03:50 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On Thu, 1 Nov 2007, Michael G Schwern wrote:
> I want to delete a bunch of unnecessary text files in a pile of NOVA episodes
> I have archived. Ok, no problem...
Anything beyond rudimentary find has always scared me into laziness.
If the .txt files are all known to be at the same depth, why not just:
$ cd ~/Movies/NOVA
$ find . | grep '\.txt$' # just to skim the list & be sure...
$ rm */*/*.txt
Hm?
Then repeat the `find . | grep ...` to verify you got them all.
If there's some another level down, no problem:
$ rm */*/*/*.txt
Et voila.
I know find is powerful enough to blow my foot off, so I try not to
point it that way to begin with.
From: A. Pagaltzis
Date: 05:05 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
* Chris Devers <cdevers@xxxxx.xxx> [2007-11-02 04:55]:
> Anything beyond rudimentary find has always scared me into
> laziness.
Would that every system I touch had Perl and the File::Find::Rule
module installed. Given
alias ffr='perl -MFile::Find::Rule'
Michael's original example would be
ffr -e'unlink find->name("*.txt")->in(".")'
Alas...
Regards,
From: Abigail
Date: 09:19 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 02, 2007 at 06:05:11AM +0100, A. Pagaltzis wrote:
> * Chris Devers <cdevers@xxxxx.xxx> [2007-11-02 04:55]:
> > Anything beyond rudimentary find has always scared me into
> > laziness.=20
>=20
> Would that every system I touch had Perl and the File::Find::Rule
> module installed. Given
>=20
> alias ffr=3D'perl -MFile::Find::Rule'
>=20
> Michael's original example would be
>=20
> ffr -e'unlink find->name("*.txt")->in(".")'
File::Find confuses me.
If I have the need to use a find like functionality from within a=20
Perl program, I will *always* shell out and use find instead of
using File::Find.
Abigail
--EeQfGwPcQSOJBaQU
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFHKuu8BOh7Ggo6rasRAtS+AJ9tDtXI5qiMUw3Vpwrc5FA0NIxx4QCghpHC
ScvJwfLQSY+Ih2pFliuXj6E=
=poYN
-----END PGP SIGNATURE-----
--EeQfGwPcQSOJBaQU--
From: A. Pagaltzis Date: 15:56 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm Hi Abigail, * Abigail <abigail@xxxxxxx.xx> [2007-11-02 10:30]: > On Fri, Nov 02, 2007 at 06:05:11AM +0100, A. Pagaltzis wrote: > > Would that every system I touch had Perl and the > > File::Find::Rule module installed. > > File::Find confuses me. File::Find::Rule -- not File::Find. File::Find is a pain and a half. Regards,
From: Peter da Silva Date: 16:45 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 02-Nov-2007, at 10:56, A. Pagaltzis wrote: > File::Find::Rule -- not File::Find. This naming convention is made of hate and rotting wombat spleens.
From: demerphq
Date: 16:16 on 02 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On Nov 2, 2007 10:19 AM, Abigail <abigail@xxxxxxx.xx> wrote:
> On Fri, Nov 02, 2007 at 06:05:11AM +0100, A. Pagaltzis wrote:
> > * Chris Devers <cdevers@xxxxx.xxx> [2007-11-02 04:55]:
> > > Anything beyond rudimentary find has always scared me into
> > > laziness.
> >
> > Would that every system I touch had Perl and the File::Find::Rule
> > module installed. Given
> >
> > alias ffr='perl -MFile::Find::Rule'
> >
> > Michael's original example would be
> >
> > ffr -e'unlink find->name("*.txt")->in(".")'
>
>
> File::Find confuses me.
>
> If I have the need to use a find like functionality from within a
> Perl program, I will *always* shell out and use find instead of
> using File::Find.
I'm curious what confuses you about it?
Note that isnt hateful, but it never struck me as confusing.
Although i do recall being shocked at how slow it was to do on a
windows box over a network share. But then i learned that that was due
to windows/Perl stupidity meaning that Perl would open EVERY DANG FILE
just so it could get one field for stat that ive never seen anybody
use on a windows box anyway. (Hence the introduction of
${^WIN32_SLOPPY_STAT} in later versions of perl).
I could never decide who to hate more about that actually, Windows for
not making the field populatable from a mere stat or what windows
calls a stat, or activestate for defaulting to doing the extra work to
populate it despite its virtual non use for cultural reasons.
Yves
From: Phil Pennock Date: 05:39 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 2007-11-01 at 23:50 -0400, Chris Devers wrote: > $ cd ~/Movies/NOVA > $ find . | grep '\.txt$' # just to skim the list & be sure... > $ rm */*/*.txt > > Hm? > > Then repeat the `find . | grep ...` to verify you got them all. > > If there's some another level down, no problem: > > $ rm */*/*/*.txt zsh% rm **/*.txt Want to chase symlinks? zsh% rm ***/*.txt Only those older than 7 days? zsh% rm **/*.txt(m+7) Want to not have to worry about the length of argv? (Thank you, Unix) zsh% zmodload zsh/files zsh% rm **/*.txt zsh% type rm rm is a shell builtin Now, that's not to say zsh is sweetness and light. It tends towards being write-only. There are ... a plethora of options. But it's less hate-worthy than the alternatives (and fairly easy to hack on to reduce hate).
From: Peter da Silva Date: 13:06 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 02-Nov-2007, at 00:39, Phil Pennock wrote: > zsh% rm **/*.txt zsh is a whole new category of hate, as far as I'm concerned. Especially when you have a PFY who loves zsh and uses it for scripting after you've told him not to. And then leaves.
From: sabrina downard Date: 14:55 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm > zsh is a whole new category of hate, as far as I'm concerned. zsh is the weirdest shell I've ever used. That hasn't stopped me from adopting it as my login shell, but it keeps giving me occasions to say "what the fuck? that shouldn't have worked." Like the first time when I did something like "rpm -qi bcfg2<tab>," hitting tab absent-mindedly and muscle-memory'edly, and then it autocompleted. Total "wtf, there are no RPMs in my cwd" moment there. Then there was the one time I hit absent-mindedly hit tab to autocomplete the name of a remote file on an scp command line and IT WORKED. I was completely freaked out for a good few minutes after that one; I had to go read documentation, and oh, how that burned. Though I really did want to beat someone upside the head when I found their little built in rm -i behavior. Yes, mother, I meant to delete *, I unalias rm on login for a reason, now quit meddling. I'm a little afraid of what it's going to come up with next time. This is a definite love-hate relationship for me. (Not least because I am used to various sorts of brain-damage, like in iterating over strings with spaces in them in shell loops, and it confuses me to find that someone actually fixed the brain-damage rather than working around it like the rest of us.) Still, it's better than that constant "I want to spork my eyes out" sensation of being stuck with bash because everyone else thinks I'm quite insane for wanting ksh93. I might be quite insane for other reasons but dear hearts, just because it's got a GNU label slapped on it and you think that GNU is cool doesn't mean I necessarily want to get within range of it. Also, bash has cooties. --s.
From: Rafael Garcia-Suarez Date: 15:00 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 02/11/2007, sabrina downard <viv@xxxxxxxx.xxx> wrote: > > zsh is a whole new category of hate, as far as I'm concerned. > > zsh is the weirdest shell I've ever used. That hasn't stopped me from > adopting it as my login shell, but it keeps giving me occasions to say > "what the fuck? that shouldn't have worked." Like the first time when > I did something like "rpm -qi bcfg2<tab>," hitting tab absent-mindedly > and muscle-memory'edly, and then it autocompleted. Total "wtf, there > are no RPMs in my cwd" moment there. Then there was the one time I > hit absent-mindedly hit tab to autocomplete the name of a remote file > on an scp command line and IT WORKED. I was completely freaked out > for a good few minutes after that one; I had to go read documentation, > and oh, how that burned. bash has some customizable completions features like that too (I'm not used to zsh, but I assume they're similarly implemented.) I find them highly hateful, because I want my tab completion to be fast, and must not rely on parsing rpm index files or fetching info over a network. So I usually disable them.
From: Peter da Silva Date: 16:42 on 02 Nov 2007 Subject: Re: find . -print0 -name 'foo' | xargs rm On 02-Nov-2007, at 09:55, sabrina downard wrote: > (Not least because > I am used to various sorts of brain-damage, like in iterating over > strings with spaces in them in shell loops, and it confuses me to find > that someone actually fixed the brain-damage rather than working > around it like the rest of us.) That's not "brain damage", that's "consistency". For a programming language, consistency is important. That's the kind of thing that makes me want to spork someone's eyes out. > Still, it's better than that constant > "I want to spork my eyes out" sensation of being stuck with bash > because everyone else thinks I'm quite insane for wanting ksh93. Bash is full of hateful inconsistent extension hate too.
From: Phil Pennock
Date: 01:53 on 03 Nov 2007
Subject: Re: find . -print0 -name 'foo' | xargs rm
On 2007-11-02 at 08:06 -0500, Peter da Silva wrote:
> Especially when you have a PFY who loves zsh and uses it for scripting
> after you've told him not to.
Yeah, I said it's write-only. I support not using it for production
scripting, but then this is an environment which disavows Perl and has
turned Python into a compiled language rather than risk having libraries
change underneath you.
I just end up getting all the shell code reviews because I'm enough of a
pedant to spot the bash-isms and say "no, you can't use #!/bin/sh if
you're relying on a bash extension". Mind, bash extensions are allowed,
as is use of #!/bin/bash, but in theory those never go out to Production
machines. Really. Uhuh.
On 2007-11-02 at 09:55 -0500, sabrina downard wrote:
> Though I really did want to beat someone upside the head when I found
> their little built in rm -i behavior. Yes, mother, I meant to delete
> *, I unalias rm on login for a reason, now quit meddling.
Yeah, I did mention the plethora of options. Here, you want:
setopt rm_star_silent
which is set automatically in sh/ksh compatibility modes.
> might be quite insane for other reasons but dear hearts, just because
> it's got a GNU label slapped on it and you think that GNU is cool
> doesn't mean I necessarily want to get within range of it. Also, bash
> has cooties.
I get irritated at the people boasting about wonderful bash features,
which were taken from ksh/ksh93/zsh. I am less irritated but curiously
perplexed at the blinkered attitude when I hear "bash has arrays"; yeah,
some years after zsh added associative arrays to the regular arrays it
already had and besides which bash copied the ksh behaviour whereby
$array expands to ${array[0]} instead of $array{[@]}. :^( To get this
brokenness in zsh, you have to either be in sh/ksh compatibility mode or
explicitly ask for it with "setopt ksh_arrays".
Insane. I reference the array, I want its contents. Give me the damn
contents. I swear, most of the resistance to use of arrays in
sh-derivative shells must be because of this braindead crap.
On 2007-11-02 at 16:00 +0100, Rafael Garcia-Suarez wrote:
> bash has some customizable completions features like that too (I'm not
> used to zsh, but I assume they're similarly implemented.) I find them
> highly hateful, because I want my tab completion to be fast, and must
> not rely on parsing rpm index files or fetching info over a network.
> So I usually disable them.
bash's tab completion is loosely modelled on that of tcsh, which is also
what the old completion system in zsh (man zshcompctl) is based on.
zsh's newer tab-completion is based on a ... "baroque" architecture of
shell functions with line-editor support, user-preference support (via
zstyle) and more. It's more capable and it's surprisingly fast; the
remote stuff tends to cache. It does tend to surprise me when it gets
stuff automatically right (remote pathnames surprised me, the first
time) and it irritates because it's no longer so easy to handle the
common case for personal commands ("give me filenames from inside that
directory there"). I'm grudgingly coming to appreciate its benefits. I
keep the hate for special occasions, there.
It was a pain in the butt to figure out the right incantations to keep
zsh from doing complete ~user expansion in an LDAP-based environment
of >10k users. But still doable, because enough of the shell is exposed
to make it possible to lie to the shell and pretend that only a small
set of usercodes belonging to my colleagues exist, unless and until any
additional usercodes are seen, in which case only those are added.
But hey, my mailcheck-imap program (Perl) can use GSSAPI to
automatically dump a list of subscribed folders and I can hook this into
zsh to let me tab-complete IMAP folders. That alone is a productivity
boost I am loath to surrender.
-Phil
Generated at 10:26 on 16 Apr 2008 by mariachi