Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re^2: Perl Term::ReadLine::Gnu Signal Handling Difficulties

by sgt_b2002 (Initiate)
on Nov 13, 2012 at 13:50 UTC ( #1003614=note: print w/replies, xml ) Need Help??

in reply to Re: Perl Term::ReadLine::Gnu Signal Handling Difficulties
in thread Perl Term::ReadLine::Gnu Signal Handling Difficulties

Hi Mr. Muskrat

Thanks for the help. I tried the script you provided and can see how to set the Gnu variables now, but my script still doesn't act how I think it should.

Given the script you provided, I'll hit control-c to send an INT to the script while at the prompt. I expect to see "I got a INT" right after I hit control-c. Instead, the script stays at the prompt until I hit enter. After hitting enter I see "I got a INT".

Is this the designed behavior? Ideally, I'd like to have the signal handlers trigger as soon as the signal is received.

Thanks again for helping me out. :)

  • Comment on Re^2: Perl Term::ReadLine::Gnu Signal Handling Difficulties

Replies are listed 'Best First'.
Re^3: Perl Term::ReadLine::Gnu Signal Handling Difficulties
by Mr. Muskrat (Canon) on Nov 13, 2012 at 14:07 UTC

    It works for me; that is to say that when I run it and press ctrl-c, it exits with "I got a INT".

    We are going to need more information about the environment where you are testing this. Let's start with operating system, version of Perl, version of Term::ReadLine::Gnu and version of GNU Readline library version should be sufficient for now.

    By the way, it's impolite to cross-post without saying you've cross-posted.

      Thanks again for the reply. I'll be sure to mention cross positing if it happens again as well.

      So I've tested this in two environments and in each, the ctrl-c isn't handled until I press enter. Here are the two environments.

      OS: Gentoo Linux 2.6.35 x86_64 Perl: 5.12.4 Term::ReadLine::Gnu: 1.20 readline version: 6.2_p1 OS: Gentoo Linux 3.3.8 x86_64 Perl: 5.16.1 Term::ReadLine::Gnu: 1.20 readline version: 6.2_p1

      As an aside, I added the following line as a quick check to make sure I'm using Term::ReadLine::Gnu when testing this on different machines.

      print $term->ReadLine."\n";

      Again, thanks for your help with this. :)

        My apologies. Apparently I tested this on the wrong box. I was using Term::ReadLine::Stub instead of Term::ReadLine::Gnu. I'll try again in a bit and keep you updated with what I find.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1003614]
[tye]: I just daemonized and getlogin() still knew who I had been.
[tye]: perhaps loginuid ? Not that I concede that something not being in /proc means it is not useful.
[Corion]: tye: That's really interesting, but maybe it is because getlogin() returns the name, or the uid, so if that user has been replaced by another user with the same uid in the meantime, that's no problem to the system...
[davido]: or on ubuntu /var/run/utmp
[Corion]: Otherwise, I would imagine that a user with a process still alive would lock that information in memory.
[davido]: so last -f /var/run/utmp on ubuntu provides similar (though more verbose) info
[oiskuu]: glibc getlogin just does ttyname() and falls back on getutline(); it's not security related at all. (reminds me of sendmail and remote finger services of the naive early spam era)
[Corion]: But yes, "who started this process" is interesting information :)
[tye]: no, I really believe that "login user" was added as a fundamental bit of info about each process in order to enhance the usefulness of auditing
[Corion]: Ah - if that information is saved in a file, then you could theoretically spam that file and confuse getlogin(). So, don't use it for authentication :)

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2017-06-23 19:36 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (554 votes). Check out past polls.