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:
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):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 }
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.if ( @ARGV == 0 and -t ) { die "Usage: $0 list.file or some_command | $0\n";
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
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |