Re: Now what would you expect this to print out?
On Tuesday 20 May 2008 16:44, RW wrote: > On Tue, 20 May 2008 11:33:50 +0200 > > Jonathan McKeown <[EMAIL PROTECTED]> wrote: > > On Tuesday 20 May 2008 02:41, RW wrote: > > > On Mon, 19 May 2008 21:46:03 +1200 > > > > > > Jonathan Chen <[EMAIL PROTECTED]> wrote: > > > > find /usr/src \( -name Makefile -or -name '*.mk' \) -print > > > > > > Why does that make a difference, when print always evaluates to > > > true? > > > > > > x AND true = x > > > > > > so > > > > > > (a OR b) AND true = a OR b > > > a OR (b AND true) = a OR b > > > > It makes a difference (as in programming) because -print is used for > > its side-effect rather than its value, and the binding order > > influences when the side-effect happens. > > That's still a bit counter-intuitive because in normal programming > languages the binding order modifies side-effects via the evaluation > order. And in both cases the evaluation order would be expected to be > left-to-right, with -print running last. Yes. I'm actually talking rubbish. find evaluates its argument expression left-to-right, and the ``precedence'' actually applies to term grouping rather than evaluation order. (This does affect the outcome, but not in the way I glibly said it did). What I should have said is that like a lot of programming languages, find is lazy when it comes to Boolean expressions: when it gets a TRUE in an -or or a FALSE in an -and, the value of the whole expression must be TRUE or FALSE respectively, regardless of what the remaining terms are, so why bother evaluating them? (It's usually referred to as short-circuiting). > I guess what you are saying is that the side-effect of print is based-on > a Boolean "running-value". And without the brackets, the first test has > been evaluated, but not yet ORed into that "running-value", by the time > that print runs. That's not quite how it works. Rewriting find /usr/src -name Makefile -or -name '*.mk' -print using extra parens to emphasise the implicit grouping, and including the implicit -and, gives: find /usr/src -name Makefile -or \( -name '*.mk' -and -print \) in other words, an -or with two terms, one of which happens to be an expression. If -name Makefile is true, the -or is satisfied, so nothing else is evaluated, and find goes on to the next filename. Otherwise, the expression in the second term has to be evaluated. If -name '*.mk' is false, the -and is satisfied (which also satisfies the -or) and find moves to the next filename. If it's true, the -and can't be satisfied without evaluating the -print. The end result is that only files matching '*.mk' are printed. Rewriting the other case, find /usr/src \( -name Makefile -or -name '*.mk' \) -and -print If the first expression is false, the -and is satisfied and the -print is not evaluated. If the first expression is true (meaning either of the -name arguments is true), then the -and can't be satisfied without evaluating the -print. The last case is find /usr/src -name Makefile -or -name '*.mk' find quickly analyses this, finds no output action, and converts it to the second form above, internally placing parens around the whole expression and an -and -print after it. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Tue, 20 May 2008 11:33:50 +0200 Jonathan McKeown <[EMAIL PROTECTED]> wrote: > On Tuesday 20 May 2008 02:41, RW wrote: > > On Mon, 19 May 2008 21:46:03 +1200 > > > > Jonathan Chen <[EMAIL PROTECTED]> wrote: > > > find /usr/src \( -name Makefile -or -name '*.mk' \) -print > > > > Why does that make a difference, when print always evaluates to > > true? > > > > x AND true = x > > > > so > > > > (a OR b) AND true = a OR b > > a OR (b AND true) = a OR b > > It makes a difference (as in programming) because -print is used for > its side-effect rather than its value, and the binding order > influences when the side-effect happens. That's still a bit counter-intuitive because in normal programming languages the binding order modifies side-effects via the evaluation order. And in both cases the evaluation order would be expected to be left-to-right, with -print running last. I guess what you are saying is that the side-effect of print is based-on a Boolean "running-value". And without the brackets, the first test has been evaluated, but not yet ORed into that "running-value", by the time that print runs. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Tuesday 20 May 2008 02:41, RW wrote: > On Mon, 19 May 2008 21:46:03 +1200 > > Jonathan Chen <[EMAIL PROTECTED]> wrote: > > On Mon, May 19, 2008 at 01:49:35AM -0700, Garrett Cooper wrote: > > > Riddle for the day for folks that have source trees... what would > > > you expect this to print out (ask yourself the question and then > > > execute the command)? > > > > > > find /usr/src -name Makefile -or -name '*.mk' -print > > > > > > The expected output and what actual output differed in my mind, but > > > maybe somebody else can "shed some light" on the logic behind what > > > happened > > > > It's a problem that catches many young players with find(1). One has > > to remember from reading the man-page that all directives have an > > implicit AND operator on it; and that includes the "-print" directive. > > So to get what you want, you have to introduce brackets: > > > > find /usr/src \( -name Makefile -or -name '*.mk' \) -print > > Why does that make a difference, when print always evaluates to true? > > x AND true = x > > so > > (a OR b) AND true = a OR b > a OR (b AND true) = a OR b It makes a difference (as in programming) because -print is used for its side-effect rather than its value, and the binding order influences when the side-effect happens. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Mon, 19 May 2008 12:40:46 +0200, Jonathan McKeown <[EMAIL PROTECTED]> wrote: > I forget where I saw this quote first, but the last five words always > make me think of the find command: > > Real Programmers consider "what you see is what you get" to be just as > bad a concept in Text Editors as it is in women. No, the Real Programmer > wants a "you asked for it, you got it" text editor - complicated, cryptic, > powerful, unforgiving, dangerous. The page at http://www.pbm.com/~lindahl/real.programmers.html suggests that this quote is from ``A letter to the editor of Datamation, volume 29 number 7, July 1983.'' The author of that page writes ``I've long ago lost my dog-eared photocopy, but I believe this was written (and is copyright) by Ed Post, Tektronix, Wilsonville OR USA,'' so it may be a bit tricky to verify the claim. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Mon, 19 May 2008 21:46:03 +1200 Jonathan Chen <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 01:49:35AM -0700, Garrett Cooper wrote: > > Riddle for the day for folks that have source trees... what would > > you expect this to print out (ask yourself the question and then > > execute the command)? > > > > find /usr/src -name Makefile -or -name '*.mk' -print > > > > The expected output and what actual output differed in my mind, but > > maybe somebody else can "shed some light" on the logic behind what > > happened > > It's a problem that catches many young players with find(1). One has > to remember from reading the man-page that all directives have an > implicit AND operator on it; and that includes the "-print" directive. > So to get what you want, you have to introduce brackets: > > find /usr/src \( -name Makefile -or -name '*.mk' \) -print > Why does that make a difference, when print always evaluates to true? x AND true = x so (a OR b) AND true = a OR b a OR (b AND true) = a OR b ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Monday 19 May 2008 11:46, Jonathan Chen wrote: > On Mon, May 19, 2008 at 01:49:35AM -0700, Garrett Cooper wrote: > > Riddle for the day for folks that have source trees... what would you > > expect this to print out (ask yourself the question and then execute the > > command)? > > > > find /usr/src -name Makefile -or -name '*.mk' -print > > > > The expected output and what actual output differed in my mind, but maybe > > somebody else can "shed some light" on the logic behind what happened > > It's a problem that catches many young players with find(1). One has > to remember from reading the man-page that all directives have an > implicit AND operator on it; and that includes the "-print" directive. > So to get what you want, you have to introduce brackets: > > find /usr/src \( -name Makefile -or -name '*.mk' \) -print Or, slightly bizarrely, just leave the -print off altogether - as the manpage says, If none of -exec, -ls, -print0, or -ok is specified, the given expression shall be effectively replaced by ( given expression ) -print. [Note the parens around given expression] I forget where I saw this quote first, but the last five words always make me think of the find command: Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor - complicated, cryptic, powerful, unforgiving, dangerous. Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
> Riddle for the day for folks that have source trees... what would you expect > this to print out (ask yourself the question and then execute the command)? > > find /usr/src -name Makefile -or -name '*.mk' -print > > The expected output and what actual output differed in my mind, but maybe > somebody else can "shed some light" on the logic behind what happened [I > read through the find(1) code and can see why it does what it does, but I > still don't find the result useful]. Looks like you wanted to do this: find /usr/src \( -name Makefile -o -name '*.mk' \) -print Implicit operator is and (-a) and is arithmetic, and is equivalent to multiplication, or is equivalent to addition ... so and as the priority. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Now what would you expect this to print out?
On Mon, May 19, 2008 at 01:49:35AM -0700, Garrett Cooper wrote: > Riddle for the day for folks that have source trees... what would you expect > this to print out (ask yourself the question and then execute the command)? > > find /usr/src -name Makefile -or -name '*.mk' -print > > The expected output and what actual output differed in my mind, but maybe > somebody else can "shed some light" on the logic behind what happened It's a problem that catches many young players with find(1). One has to remember from reading the man-page that all directives have an implicit AND operator on it; and that includes the "-print" directive. So to get what you want, you have to introduce brackets: find /usr/src \( -name Makefile -or -name '*.mk' \) -print Cheers. -- Jonathan Chen <[EMAIL PROTECTED]> -- If you're right 90% of the time, why quibble about the remaining 3%? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
