I'd skip the redirection. You can get the names of files from the command line in @ARGV and read them from the convenient default diamond <> (e.g. perl -e'print while <>' *.txt ). That leaves you free to use yout tty for STDIN.

#!/usr/bin/perl -w

use strict;

open(TTY,"+< /dev/tty")
  or die "Couldn't open tty: $!\n";
print TTY "Are you sure? ";
if (my $l = <TTY> !~ /^y/i)
{
  die "Cancelled by user.\n";
}

while (<>)
{
  print;
}
[download]

• using <> for reading incomming records, so I don't have to care if data comes from pipe or redirection or files supplied on command line,
• -t STDIN for determining if STDIN is a terminal,
• open /dev/tty to get the user input (which was my original problem)
• and Term::Readkey to avoid the need of hitting an extra RETURN.

#!/usr/bin/perl
use strict;
use warnings;
use Term::ReadKey;

# Is data comming?
usage() unless ( ( ! -t STDIN ) || ((defined($ARGV[0])) && ( -f $ARGV[
+0] )) );
open(TTY,"+</dev/tty") or die "Couldn't open tty: $!\n";

# input record separator is \x1d
$/ = "\x1D";

while ( my $rec = <>) {
  next unless defined $rec;
  show_formatted_record();

  print TTY "\n\nOne more? y/n ";

  ReadMode('cbreak', *TTY);
  my $answer = ReadKey(0, *TTY);
  ReadMode('normal', *TTY);

  last if $answer !~ /^[yY]$/;
}
print "\n";

#---- functions: 
sub usage { print "usage: ...\n"; exit 1; }

sub show_formatted_record { print "..."; }
[download]

You have also got Term::ReadKey if you want single keystroke responses.

Correction:

• You need to dupe STDERR as a readable file handle first, and this doesn't work in later versions of perl (5.8 and later won't allow you to dupe a write-only file-handle into a readable filehandle... although even by the 5.0 docs, it shouldn't be allowed (is my face red, or what))

  [me@host bin]$ perl -we 'open STDERRIN,"+<&STDERR" or die $!; my $line
  + = <STDERRIN>;  print STDERRIN "YAY!!! $line";'
  asdfasf
  YAY!!! asdfasf
  [me@host bin]$
  [download]

If you are not redirecting, then STDIN, STDOUT and STDERR are really all references to the same thing, your terminal. You can see this by running (at least on linux):

ls -l /proc/self/fd/
[download]

ls -l /proc/self/fd/ < /dev/null
ls -l /proc/self/fd/ | cat
ls -l /proc/self/fd/ 2> /dev/null   #redrect STDERR
[download]

If you want to be clever, then you can try to detect which of STDIN, STDOUT and STDERR are actually terminals, by using the -t operator. Also, you could just reach around the standard IO channels and open a direct shot to the controlling tty of the process like:

open TTY, ">/dev/tty" or die "Couldn't open /dev/tty $!";
[download]

You can read from STDERR. It's just as easy as <STDERR>.

Really?

$ perl -wle 'print while <STDERR>'
Filehandle STDERR opened only for output at -e line 1.
$
[download]

How do you plan to read from STDERR, and how do you tell your terminal that what you type should be connected the the STDERR of the foreground job?

Abigail

ACK! My bad for posting untested code. You have to dupe STDERR to pull this off:

open STDERRIN,"<&STDERR" or die "Could not dupe STDERR for input: $!\n
+";
my $line = <STDERRIN>;
[download]

While STDERR is a file-descriptor to your terminal (if you haven't redirected stdout), it is only an outbound channel... so you need to open an inbound channel to the same device if you want to read from it.

------------
:Wq
Not an editor command: Wq

perl -e '$fn=shift @ARGV;open FN, $fn;print while (<FN>);print "\nInpu
+t :";print <STDIN>;' num.txt
[download]

Which prints the contents of my "num.txt" file, then prompts for input:

1481422100622192272001352141350602152800661492052301431991681632291972
+09
Input :test
test
[download]