Rule Number One for writing "UNIX-style" command-line tools: Thou shalt not prompt the user for keyboard input. Whatever decisions the user needs to make in order for the tool to do his bidding on a given run, it should be possible to have those decisions made before hitting "Enter" on the command line to make it run -- and those decisions take the form of "arguments" (one or more space-separated "word" tokens that are typed directly after the name of the program).

In other words, everything the program needs to know from the user needs to be provided via @ARGV (and/or, in more sophisticated/complicated settings, by %ENV). Refactor your script so that the stuff expected from the user via STDIN comes from @ARGV (or %ENV) instead.

If the nature of the program involves showing the user some data or processing results before asking for a decision -- such that the user won't know what directives to supply to the script until after it starts running -- you are up a creek. That is not a unix-shell-style process, and you won't really be able to use it effectively in any sort of pipeline command.

UPDATE: Looking again at what you said, it seems that you want the user to provide a list of items of interest, you process each list item as the user supplies it, and then the user has give a special signal when they are done.

It would actually be easier for the user -- and provide many other benefits that you will discover over time -- if you ask the them to supply the name of a file that contains the list.

Alternatively, the user could supply a list by running some other process and piping its output to your script (e.g.  ls | grep some_pattern | cut -f1 -d. | uniq | your_script or any variety of other methods).

Either way, all your script needs to do is:

my @input_list = <>; chomp @input_list; for my $item ( @input_list ) { ## instead of "while (1)" ... # do what needs to be done without further directions from u +ser }
Of course, when people are used to running the script all by itself (not in a pipeline, and without any args), changing it to this sort of approach can be disorienting: now they run it and it just sits there doing nothing (waiting for input on STDIN), and the user doesn't know what to do (they're waiting for instructions). To cure that problem, put the following as the first thing (right after "use strict;" and any other modules/pragmas you are using):
if ( @ARGV == 0 and -t ) { die "Usage: $0 list.file or some_command | $0\n";
The "-t" is true when STDIN is known to be the tty (expecting input from the keyboard), and is false when STDIN is tied to a pipeline. So if there's no pipeline for input and no file name given on the command line, you have to stop and tell the user how to run the command.

In reply to Re^3: How do I pipe the output of a Perl program to something else? by graff
in thread How do I pipe the output of a Perl program to something else? by azredwing

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.