in reply to RE: Answer: What is a good
in thread What is a good "Press any key to continue" code?

No. Never use <> when you mean <STDIN>.

What if you're using the elements of @ARGV to hold keywords or other items?

I'd fail this one in code review, since it has a trivial fix, could cause significantly odd behavior, and indicates a confused mind in general.

My code-review rule is:

if you prompt to STDOUT, you should read from STDIN, not ARGV.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: RE: Answer: What is a good
by tye (Sage) on Sep 22, 2000 at 07:32 UTC

    I voted this down because I see no reason to accuse anyone of having a confused mind. Even just stating that you think that someone may have been confused should be done with some tact.

    I assume the personal attack was not intentional, hence I felt it should be brought to your attention.

    I also see no reason to tie writing to STDOUT with reading from STDIN. A very standard practice is to "read from @ARGV" and write to STDOUT (one used by many Unix commands and one that Perl has even devoted a command-line option to). Perhaps you meant "if you write a prompt to STDOUT..."?

            - tye (but my friends call me "Tye")
      I think you are being too sensitive.

      When merlyn says, If you prompt to STDOUT, I think most people (OK I do) will read that as, If you print an interactive message to STDOUT, which is what was meant.

      Furthermore the phrase ...in general indicates a confused mind... does not say that Fastolfe in particular has a confused mind. It just says that this kind of mistake is symptomatic of a confused mind. Which it is. If you do not understand how <> differs from <STDIN>, that indicates confusion! Even worse, if you meant that you expect files in @ARGV to correctly hold responses to interactive commands in a script you are still changing, that indicates dangerous programming practices!

      All of which goes to say that even though I had let merlyn's post pass before, I voted ++ to counteract your -- because I thought your reasoning was not very good.

      UPDATE
      I have been told that "prompt" was originally "print", which shows why - particularly when a point has caused comment - it is good to make it clear that there was an edit.

        I didn't consider this a big deal. It was just meant as a reminder to endeavor to be tactful. I did say that I didn't think that the personal attack was intentional. And I won't further argue the reasonableness of either side.

        Update 2: Don't read further unless you enjoy squabbling [ and who doesn't ;) ]. I give merlyn the benefit of the doubt that it wasn't intentional.

        However, in the future I will be sure to "cut and paste" any text from merlyn before commenting on it. Silently updating your post to make someone's argument against it look foolish is just childish. This is made even worse by merlyn commenting on tilly's reply without even mentioning that half of tilly's reply was based on a silent edit. Prior to that step merlyn could have claimed that making the modification silently was just an oversight.

        Who knows what any of merlyn's nodes in this thread will read at the time anyone reads my node here? Will they just be empty like merlyn has done before with nodes that were not popular. For the record, the original node I commented on said: "if you write to STDOUT, you should read from STDIN, not ARGV". When tilly saw my reply merlyn's node had changed "write" to "prompt" with no other changes that I could see (certainly there was no "update" notice).

        Update: I decided that the actual original wording used "write" instead of "print" so I updated this node to reflect that.

                - tye (but my friends call me "Tye")
        Furthermore the phrase ...in general indicates a confused mind... does not say that Fastolfe in particular has a confused mind. It just says that this kind of mistake is symptomatic of a confused mind.
        Yes, I mean it that way. In code review, you don't usually get the luxury of reading each line of code. You rely on patterns of behavior. I treat some combinations of things as "speed bumps" that are not only questionable behavior in and of themselves, but also say "slow down, there's likely to be other confusion near here as well". And the result of this slowing down often pays off in finding other bugs.

        Code review and QA is an art, not a science. After years of reading other people's code, I do a lot of things automatically, and I'm attempting to describe my behavior here, so if it doesn't always come across clean, bear with me. {grin}

        -- Randal L. Schwartz, Perl hacker