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]
 

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]
 

-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]