in reply to unexpected STDIN

This line will not do what you think it will:

if ($answer eq ('y' or 'yes')) {

[download]

Someone else asked how to get input from STDIN recently too: Continure when "y" and none for "n"

Replies are listed 'Best First'.
Re^2: unexpected STDIN
by GhodMode (Pilgrim) on Apr 30, 2011 at 11:17 UTC

    Thanks wind, but it's not really clear what you mean. Could you be more specific?

    I think you might be referring to my placement of the parentheses and I do see the problem there. My code is actually evaluating ('y' or 'yes') first, then comparing the (boolean) result (true since 'y' is not an empty string) to the value of $answer.

    This is probably better: if (($answer eq 'y') or ($answer eq 'yes')){

    I caught that one on my own, but I hadn't gotten to that point yet when I asked the question. I wasn't even getting prompted for the info when I asked the question because it was using the file from the command line instead of <STDIN>

    The thread you linked to doesn't refer to order of precedence... Did you notice another problem that I haven't seen yet?

    Thank you.
    --
    Ghodmode
    www.ghodmode.com/blog
[reply]
[d/l]
[select]
      My code is actually evaluating ('y' or 'yes') first, then comparing the (boolean) result (true since 'y' is not an empty string) to the value of $answer.

      If I correctly understand this statement, I would make the following small, but important, clarification:

      <quibble>
      The expression
          ('y' or 'yes')
      will always return 'y' specifically (rather than a 'canonical' true of 1) because the short-circuiting logical-or operator returns the value of the first operand that is true (or false if none is true). Thus
          (($answer eq 'y') or ($answer eq 'yes'))
      (fully parenthesized) is probably certainly better than
          ($answer eq ('y' or 'yes'))
      because the former will actually get around to evaluating  ($answer eq 'yes') someday if  $answer is not 'y'.
      </quibble>

      This may seem a mere, quibbling detail, but the Devil (and the 3 AM, tearing-your-hair-out debug session) is in the details.

[reply]
[d/l]
[select]

        +1 ... That's right.

        I got the exact effect of the misplaced parentheses wrong. It will actually work if the response is 'y' because that parenthesized expression will always yield 'y'.

        I might have gotten the reason for that effect right. Since 'or' is a logical operator, it evaluates the truth of the two operands. Since the first one is not an empty string, it's true, so the result of the expression is the first string, not just true like I originally stated.

        --
        Ghodmode
        www.ghodmode.com/blog
[reply]

      This is actually like “my first almost-bug,” in “my first program” which was a re-telling of the Corn/Fox/Chicken puzzle.   I had written statements (in BASIC) like this one:

      IF F AND C AND L = 1 THEN 80

      Although the program technically “worked” as written, my mentor at the time pointed out that it was not written the right way.   The computer interpreted the statement this way:

      IF (F) AND (C) AND (L = 1) THEN 80

      ... and it “worked” because a nonzero integer, in that particular (data-typeless...) BASIC dialect, was interpreted as “truth.”   But it did not express my thoughts at the time:

      IF (F = 1) AND (C = 1) AND (L = 1) THEN 80

In Section Seekers of Perl Wisdom