Front page | perl.perl5.porters |
Postings from January 2013
[perl #108278] -T STDIN hangs
Thread Previous
|
Thread Next
From:
James E Keenan via RT
Date:
January 28, 2013 01:31
Subject:
[perl #108278] -T STDIN hangs
Message ID:
rt-3.6.HEAD-27190-1359336668-312.108278-15-0@perl.org
On Mon Jan 16 16:02:32 2012, tom christiansen wrote:
> "Craig A. Berry" <craig.a.berry@gmail.com> wrote
> on Mon, 16 Jan 2012 17:25:50 CST:
>
> > On Mon, Jan 16, 2012 at 7:02 AM, Zefram <zefram@fysh.org> 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
https://rt.perl.org:443/rt3/Ticket/Display.html?id=108278
Thread Previous
|
Thread Next