develooper Front page | perl.perl5.porters | Postings from January 2013

[perl #108278] -T STDIN hangs

Thread Previous | Thread Next
James E Keenan via RT
January 28, 2013 01:31
[perl #108278] -T STDIN hangs
Message ID:
On Mon Jan 16 16:02:32 2012, tom christiansen wrote:
> "Craig A. Berry" <> wrote
>    on Mon, 16 Jan 2012 17:25:50 CST:
> > On Mon, Jan 16, 2012 at 7:02 AM, Zefram <> wrote:
> >>  Father Chrysostomos wrote:
> >>> If STDIN is a tty, -T STDIN just hangs waiting for input.
> >>>
> >>> Is there such a thing as a non-blocking getc that we can use to
> solve this?
> Yes and no.
> ==> Yes: If isatty(0) and you're in canonical mode, then that is
> really
>          going to get in your way.  But it's not hard to deal with--on
> Unix.
> ==> No:  You can't do it portably without an incredible amount of
> pain.
>          That's why people install Term::ReadKey and such.
> >> That sounds like correct behaviour. �-T is defined to examine file
> content.
> Known issue.  Way known.
> Ever since back in 1988 when -T first appeared, I've told people a
> googolplex
> times that it is disastrously unsafe to blindly call -T on anything
> you
> haven't already determined is a "plain" file, and that I could think
> of no
> realistic situation when your (-T arg) shouldn't always be preceded by
> a
> guard test, as in probably (-f arg && -T arg).  Maybe there is one; I
> dunno.
> > But if something is not a file, wouldn't it be fairly safe to say
> it's
> > also not a file containing a high proportion of ASCII characters in
> > the first 512 bytes?
> That sounds anything but safe to me.  Perl shouldn't make things up.
> Just because I haven't thought of why there oughtn't be a -f guard
> built into it doesn't mean that there isn't one that I just haven't
> thought of yet.  After all...
>     "Unix was not designed to stop its users from doing stupid things,
>      as that would also stop them from doing clever things. --Doug
> Gwyn"
>          =~ s/Unix/Perl/r;
> > Why does pp_fttext even bother with filehandles where S_ISREG isn't
> true?
> So it can look at the current buffer if it's already got data read
> into that,
> perhaps?  Notice that the function only does a getc/ungetc if the
> buffer is
> empty, so it could use what's already there.  Per perlfunc:
>  If "-T" or "-B" is used on a filehandle, the current IO buffer
>  is examined rather than the first block.
> The problem is what to do if you don't have any of them, since
> pipes/sockets
> and character devices (and who knows what else) can block
> indefinitely. All I
> can say is that is a *very* well-known/documented issue; again, per
> perlfunc:
>    Because you have to read a file to do the "-T" test, on most
>    occasions you want to use a "-f" against the file first, as in
>    "next unless -f $file && -T $file".
> So it's not as though they haven't been warned.  Repeatedly.  For
> ages.
> Yes, you can argue that that also means there's a problem.  Perhaps
> that's what this
> --tom

Reviewing the discussion in this older ticket this evening, I believe
that Tom is correct in saying that we have duly warned people of the use
of '-T' nor preceded by '-f'.  Specifically, in 'perlfunc' we have this:

Because you have to read a file to do the "-T" test, on most occasions
you want to use a "-f" against the file first, as in "next unless -f
$file && -T $file".

So I don't see that we have a real bug here.  If anyone disagrees,
please speak up now, as I am taking this ticket for the purpose of
closing it in seven days.

Thank you very much.
Jim Keenan

via perlbug:  queue: perl5 status: open

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About