What is the source of my input, file or STDIN?

[pgregory]

As I understand it, <> operator will open all items in @ARGV allowing
one
to do a shell command line of 

   perl.script file1 file2 file3

and inside perl.script you only need 

while (<>) { ... syntax to read all the files on the command line.


<> will also open STDIN if the perl script is invoked from a pipe, such
as

ls | perl.script

So, 1. from within perl.script, how can one tell if the input stream is
coming from
STDIN or a file that was opened by <>?

2. If input stream is not coming from STDIN, but a file, how can one
tell which file is the current file (assuming multiple files were
specified on the command line)?

Thanks.

 - Paul

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[drieux]

On Jan 6, 2004, at 9:32 AM, [EMAIL PROTECTED] wrote:
[..]
So, 1. from within perl.script, how can one tell if the input stream is
coming from
STDIN or a file that was opened by <>?
2. If input stream is not coming from STDIN, but a file, how can one
tell which file is the current file (assuming multiple files were
specified on the command line)?
This is gonna sound a bit silly, so laugh along
with me while I play this out.
If you want to know which is the whom For What,
why not simply code it that way?
As an illustration:


In this case I will walk the @ARGV if there is
anything to walk, test that the file exists,
then pass it off to a count_lines() function,
which will open it and count the number of lines.
If there are no arguments at the command line,
then we will call count_lines() without a file name.
On the inside of the count_lines() function is the trick

	$file ||= '-'; # we open STDIN unless file

either we were passed a file name to open, or we
will set $file to '-' so that it will read from STDIN.
cf: perldoc -f open

ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[Jenda Krynicky]

From: [EMAIL PROTECTED]
> As I understand it, <> operator will open all items in @ARGV allowing
> one to do a shell command line of 
> 
>perl.script file1 file2 file3
> 
> and inside perl.script you only need 
> 
> while (<>) { ... syntax to read all the files on the command line.
> 
> 
> <> will also open STDIN if the perl script is invoked from a pipe,
> such as
> 
> ls | perl.script
> 
> So, 1. from within perl.script, how can one tell if the input stream
> is coming from STDIN or a file that was opened by <>?
> 
> 2. If input stream is not coming from STDIN, but a file, how can one
> tell which file is the current file (assuming multiple files were
> specified on the command line)?

>From perldoc perlvar:

$ARGV   contains the name of the current file when reading from 
<>.

HTH, Jenda
= [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =
When it comes to wine, women and song, wizards are allowed 
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[William.Ampeh]

>So, 1. from within perl.script, how can one tell if the input stream is
>coming from STDIN or a file that was opened by <>?

Use select

>2. If input stream is not coming from STDIN, but a file, how can one
>tell which file is the current file (assuming multiple files were
>specified on the command line)?

My solution is the hard way.  Open the files yourself and use the
respective filenames as their filehandles.
That is:
open($foo, "< $foo") or die "Could not open $foo: $!\n";


__

William Ampeh (x3939)
Federal Reserve Board


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: What is the source of my input, file or STDIN?

[pgregory]

Thanks for the help drieux.

I could have been more explicit in my question to have stated that
I want perl.script to exit quietly if there are no files on the 
command line or if not invoked as the recipient of piped output.

I tested your code (I named the file test.input.source) and ...

Case 1. a file is specified - works as desired.
> test.input.source test.input.source 
file test.input.source had 59 number of lines
we saw 59 number of lines

Case 2. a file is cat'd to test.input.source - works as desired.
> cat test.input.source |test.input.source
no command line args - switching to STDIN
STDIN had 59 number of lines
we saw 59 number of lines
>

Case 3. (this is the difficult case for me) the script is invoked
with no file and no pipe to it.  I would like the script to 
end quietly, such as
>test.input.source
>

Instead, it waits for input.

> test.input.source   
no command line args - switching to STDIN


and now it waits forever.


So I do not want to explicitly open STDIN if there is not a pipe 
already waiting to send me data.

It just dawned on me that I may not be using the correct terminology
since "pipe" and "STDIN" probably imply much more than I mean for them 
to convey.

I hope this is more clear.  And again, thanks for your help.

 - Paul

-Original Message-
From: drieux [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 06, 2004 11:20 AM
To: Perl Beginners Mailing List
Subject: Re: What is the source of my input, file or STDIN?



On Jan 6, 2004, at 9:32 AM, [EMAIL PROTECTED] wrote:
[..]
> So, 1. from within perl.script, how can one tell if the input stream
is
> coming from
> STDIN or a file that was opened by <>?
>
> 2. If input stream is not coming from STDIN, but a file, how can one
> tell which file is the current file (assuming multiple files were
> specified on the command line)?

This is gonna sound a bit silly, so laugh along
with me while I play this out.

If you want to know which is the whom For What,
why not simply code it that way?

As an illustration:
<http://www.wetware.com/drieux/pbl/perlTrick/CommandLine/ 
file_or_stdin.plx>

In this case I will walk the @ARGV if there is
anything to walk, test that the file exists,
then pass it off to a count_lines() function,
which will open it and count the number of lines.

If there are no arguments at the command line,
then we will call count_lines() without a file name.

On the inside of the count_lines() function is the trick

$file ||= '-'; # we open STDIN unless file

either we were passed a file name to open, or we
will set $file to '-' so that it will read from STDIN.

cf: perldoc -f open


ciao
drieux

---


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

RE: What is the source of my input, file or STDIN?

[david]

[EMAIL PROTECTED] wrote:

> 
> Case 3. (this is the difficult case for me) the script is invoked
> with no file and no pipe to it.  I would like the script to
> end quietly, such as
>>test.input.source
>>
> 
> Instead, it waits for input.
> 
>> test.input.source
> no command line args - switching to STDIN
> 
> 
> and now it waits forever.

select / IO::Select is what you are looking for. i suggested the following 
to someone who asked exactly the same question a while back. if you have 
searched this group hard enough, you would have found the solution:

#!/usr/bin/perl -w
use strict;

#--
#-- script.pl
#--

use IO::Select;

if(@ARGV){
print join("\n", "get file: ",@ARGV) . "\n";
}else{

my $buf;
my $line;

my $io = IO::Select->new(\*STDIN);

while($io->can_read(0)){
last unless(sysread(STDIN,$buf,1024));
$line .= $buf;
}

if(defined $line){
print "get line $line";
}else{
print STDERR "no input\n";
}
}

__END__

[panda]$ script.pl
no input
[panda]$ script.pl file.html
get file:
file.html
[panda]$ echo "hi" | script.pl
get line hi
[panda]$

perldoc -f select
perldoc IO::Select

david
-- 
sub'_{print"@_ ";* \ = * __ ,\ & \}
sub'__{print"@_ ";* \ = * ___ ,\ & \}
sub'___{print"@_ ";* \ = *  ,\ & \}
sub'{print"@_,\n"}&{_+Just}(another)->(Perl)->(Hacker)

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[Steve Grazzini]

On Jan 6, 2004, at 3:17 PM, [EMAIL PROTECTED] wrote:
Case 3. (this is the difficult case for me) the script is
invoked with no file and no pipe to it.  I would like the
script to end quietly
  die usage() if @ARGV == 0 and -t;

I didn't show you how to check for the pipe (-p) because
this should probably work, too:
  % your-script 

--
Steve
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[R. Joseph Newton]

[EMAIL PROTECTED] wrote:

> >So, 1. from within perl.script, how can one tell if the input stream is
> >coming from STDIN or a file that was opened by <>?
>
> Use select
>
> >2. If input stream is not coming from STDIN, but a file, how can one
> >tell which file is the current file (assuming multiple files were
> >specified on the command line)?
>
> My solution is the hard way.  Open the files yourself and use the
> respective filenames as their filehandles.
> That is:
> open($foo, "< $foo") or die "Could not open $foo: $!\n";
>
> __
>
> William Ampeh (x3939)
> Federal Reserve Board

I'd go with your solution.  The mass-file operator surely has its place, but
I think it gets over-emphasized.Right offhand, I have hard time imagining a
context in which I would want to do homogeous processing with a whole
argument list of files.  In the cases where I would want to, I can't imagine
wanting to type them in at a command-line.

I can't help but suspect that this gets used way too much as a symptom of
operator fetishism.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[R. Joseph Newton]

[EMAIL PROTECTED] wrote:

> Thanks for the help drieux.
>
> I could have been more explicit in my question to have stated that
> I want perl.script to exit quietly if there are no files on the
> command line or if not invoked as the recipient of piped output.

So what have you tried to adjust the code for this desired effect?

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[John W. Krahn]

[EMAIL PROTECTED] wrote:
> 
> As I understand it, <> operator will open all items in @ARGV allowing
> one to do a shell command line of
> 
>perl.script file1 file2 file3
> 
> and inside perl.script you only need
> 
> while (<>) { ... syntax to read all the files on the command line.
> 
> <> will also open STDIN if the perl script is invoked from a pipe, such
> as
> 
> ls | perl.script
> 
> So, 1. from within perl.script, how can one tell if the input stream is
> coming from
> STDIN or a file that was opened by <>?
> 
> 2. If input stream is not coming from STDIN, but a file, how can one
> tell which file is the current file (assuming multiple files were
> specified on the command line)?

$ARGV will contain the name of the current file or '-' if reading from
STDIN.

$ perl -le'while (<>) {eof && print $ARGV}' test.txt test1.txt
test.txt
test1.txt
$ perl -le'while (<>) {eof && print $ARGV}' < test.txt
-
$ cat test.txt | perl -le'while (<>) {eof && print $ARGV}'   
-



John
-- 
use Perl;
program
fulfillment

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[drieux]

On Jan 6, 2004, at 1:07 PM, david wrote:
[EMAIL PROTECTED] wrote:
Case 3. (this is the difficult case for me) the script is invoked
with no file and no pipe to it.  I would like the script to
end quietly, such as
test.input.source

Instead, it waits for input.

test.input.source
no command line args - switching to STDIN

and now it waits forever.
select / IO::Select is what you are looking for.
[..]

My compliments to David, as always.

The reason the code is 'waiting for ever' in
the case of having no STDIN is that it is in a
blocking IO Read on STDIN.
So since we have a better spec, I have updated the code
to show how the IO::Select could be used to gate
for the case that the code was called without
command line input, nor a current connection for STDIN.


Note all of the noisy 'print statements' are there
merely to show the transition of the logic of the code.
On Jan 6, 2004, at 12:53 PM, Steve Grazzini wrote:

On Jan 6, 2004, at 3:17 PM, [EMAIL PROTECTED] wrote:
Case 3. (this is the difficult case for me) the script is
invoked with no file and no pipe to it.  I would like the
script to end quietly
  die usage() if @ARGV == 0 and -t;
You might not want to test if there is a
controlling terminal - since that would prevent
the pipe fitting from working unless there was a
controlling terminal. A problem that will crop up
when JoeBob opts wants to use the pipe fitting in
their KSH script...
I didn't show you how to check for the pipe (-p) because
this should probably work, too:
  % your-script We have So got to talk about your meds here...

8-)

To be honest, I had not thought about the idea of
'-p' even trying to test to see if it was a pipe
since it is-ish when one connects the pipe fittings
of the standard shell, or as you have done, the
express redirection of input...
[jeeves: 30:] wc -l funk*
  14 funk_env.plx
[jeeves: 31:] ./file* < funk*
no command line args - switching to STDIN
STDIN had 14 number of lines
we saw 14 number of lines
[jeeves: 32:]
The 'redirect in' of "<" simply is a way of changing
how STDIN is feed to the calling program by the shell.
It of course is dependent upon how the shell copes
with re-attaching STDIN|STDOUT combo's...
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: What is the source of my input, file or STDIN?

[Steve Grazzini]

On Jan 7, 2004, at 1:10 PM, drieux wrote:
On Jan 6, 2004, at 12:53 PM, Steve Grazzini wrote:
  die usage() if @ARGV == 0 and -t;
You might not want to test if there is a
controlling terminal
I want to test whether STDIN (the default argument for -t)
is hooked up to the terminal (which is what -t tells you) so
that  doesn't block waiting for user input.
But if you want to quibble, this still blocks:

  % perl -pe 'BEGIN{ die if @ARGV == 0 and -t }' /dev/tty

--
Steve
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Pipe and STDIN - Re: What is the source of my input, file or STDIN?

[drieux]

On Jan 6, 2004, at 12:17 PM, [EMAIL PROTECTED] wrote:
[..]
It just dawned on me that I may not be using the
correct terminology since "pipe" and "STDIN" probably
imply much more than I mean for them to convey.
[..]

This is a good angst point to raise.

Technically STDIN|STDOUT|STDERR denote
merely 'file descriptors' that will be
opened by the shell in compliance with
how the shell saw the voodoo passed to it.
Normally they will be implemented as a 'pipe'
unless we do something else with them, at
which they may be implemented as a 'closed fd'
8-)
One can implement Pipes that are not the
first three fd's in the _iobuf[] - and yes,
one can get into massed weirdness when screwing
around at that level. So the way to think about the
problem is that the first three fd's "stdin|stdout|stderr"
will be implemented at pipes, and as such are a proper
subset of the set of Pipes. We tend to speak in terms
of 'pipe fittings' because we think of them in terms of say
	ps -ef | grep foo | egrep -v grep | awk '{print $2}'

which we on the perl side of the line could have implemented
with say perl's "popen()" approach of say
open(PS, "ps $ps_args |") or die "unable to popen(ps $ps_args): $!";
while()
{
# your proc grovelling here...
}
close(PS);
But for some reason, I'd hazzard to say that about 99%
of us fail to set a $SIG{'PIPE'} handler to deal with
the prospects of the pipe breaking because, well
most of the time we just do not care. Even MORE SO
when it is stdin|stdout|stderr ...
So the converse of your kvetch is of course,

Gosh, now that I feel at home writing pipe fittings,
when, where and how would I really want to be building
my own pipes and/or popen() types of tricks?
well for that there is perldoc perlipc
for everything else, there is ioctl()
8-)
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

-t and STDIN was Re: What is the source of my input, file or STDIN?

[drieux]

On Jan 7, 2004, at 10:37 AM, Steve Grazzini wrote:
[..]
I want to test whether STDIN (the default argument for -t)
is hooked up to the terminal (which is what -t tells you) so
that  doesn't block waiting for user input.
[..]

I have absolutely no problem with the idea that
one wants to use '-t' to establish that there is
a controlling terminal, AKA a ttyline - but the
problem is the false assumption that this is in
some way associated with STDIN.
IF i am going to guard my code with '-t' to
establish if there is any STDIN then as soon
as the code is used inside of a forked and exec'd
event where the child process is no longer attached
to the TTYLINE then
	foo | bar

will break because bar, failing to find it's controlling
terminal will not see the information coming at it from
foo through the STDIN pipe. So if one wanted to check
that there were bits in STDIN, then one should do that
with the IO::Select approach - since that will tell one
if there are bits on STDIN, even if the process itself
is being run without a controlling terminal.
To help illustrate the point:



now granted, I have only tested this on darwin|freebsd|solaris|linux
and only with perl 5.6 and 5.8 but they all come back with:
vladimir: 67:] perl got_ttyline.plx
This Will Gin Up:
Mother Got Back:hello, I am /tmp/drieux/CallMe.txt
Mother Got Back:what tty line?
Mother Got Back:STDIN says : /tmp/drieux/SomeCmd.txt:About to shout out
Mother Got Back:STDIN says : sending var1
Mother Got Back:STDIN says : sending thing2
Mother Got Back:STDIN says : sending thing3
vladimir: 68:]
So it is possible that there are implementations of this
which will not work in the way that I expect it - but
as a general rule of thumb if one wants to know that
one has a controlling terminal - "-t" then one should
test for it. But simply because there is no controlling
terminal does NOT mean that there is nothing on STDIN.
So that we are clear on this, it is not merely an issue
in Perl, this is even MORE depressing when it is coded
in a 'realCoderLanguage[dm]' and worse YET when the dilbert
made TOTALLY irrational presumptions that if there was no
controlling terminal that this of course meant that the build
was suppose to use some WingNarkFrimFrimFrim library that of
course leads to totally wacky problems when the build by hand
at a terminal works find, and all of the code builds correctly
but Blows Big Ones when done in an automated environment


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: -t and STDIN was Re: What is the source of my input, file or STDIN?

[Steve Grazzini]

On Jan 7, 2004, at 2:57 PM, drieux wrote:
But simply because there is no controlling
terminal does NOT mean that there is nothing on STDIN.
Were you reading that code backwards?

  die usage() if @ARGV == 0 and -t;

  # if ((THERE ARE NO FILENAMES IN ARGV) &&
  # (STDIN IS HOOKED UP TO A TERMINAL))
  # {
  # COMPLAIN;
  # }
We only complain if STDIN *is* a tty.

I have absolutely no problem with the idea that
one wants to use '-t' to establish that there is
a controlling terminal, AKA a ttyline - but the
problem is the false assumption that this is in
some way associated with STDIN.
% perldoc -f -X
... If the argument is omitted, tests "$_", except for
"-t", which tests STDIN.
--
Steve
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: -t and STDIN was Re: What is the source of my input, file or STDIN?

[drieux]

On Jan 7, 2004, at 12:42 PM, Steve Grazzini wrote:

On Jan 7, 2004, at 2:57 PM, drieux wrote:
But simply because there is no controlling
terminal does NOT mean that there is nothing on STDIN.
Were you reading that code backwards?

  die usage() if @ARGV == 0 and -t;

  # if ((THERE ARE NO FILENAMES IN ARGV) &&
  # (STDIN IS HOOKED UP TO A TERMINAL))
  # {
  # COMPLAIN;
  # }
We only complain if STDIN *is* a tty.
DUH! decaff...

I am probably a little Hyper about STDIN and TTY.

since I was also thinking about moving towards the
classic approach of say
	foo | bar file1 file2 file3 --stdin

vice the older and uglier

	foo | bar file1 file2 file3 -

so that bar could do both - which would have
problems if I was going to be dying off in that
case - but would of course not be dying off were
I spawned in a sub_shell where there was no controlling
terminal...
So the problem remains the problem, namely that it
is a bit of a cheat to hope that the existence of
a terminal line will work as an arbitor of whether
or not there is STDIN with bits in it.
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]