kc2rgw has asked for the wisdom of the Perl Monks concerning the following question:

Thanks to Botje on freenode #perl...this is FIXED!!

Apparently inetd is using block buffering....so the fix was simply

$| = 1;

I would have never known about this issue....this cost me hours and hours

Thanks Botje! and hope this helps someone else out

One additional note....that is deprecated and the proper form is

STDOUT->autoflush;

This is a snippet from a longer app.

The app, when run in a shell works 100% as expected.

It asks for input from a user, validates, and submits to an online service to look up the data that was entered and return a listing.

The app is run from inetd and the interface to the app is a telnet session.

This is for a packet radio node, to look up ham call signs, thus the arcane inetd/telnet interface.

When run via telnet and inetd, invalid entries return immediately to the prompt. a 'q' to quit, immediately exits, but with a valid call sign, it just sits and I have to hit <enter> one more time...then it responds completely normally.

Outside this block I have to set TERM=dumb or I get no display at all via telnet. I also have to do term resets as is shown in this snippet, in two other places or I get no display via the telnet session.

In the shell, none of that term mangling is needed

while ($seskey) { print "Callsign? or q: \n"; ( my $call = <STDIN> ); $call =~ s/[^a-zA-Z0-9]*//g; # Should we quit? if ( $call =~ m/^q.*/ ) { exit; } if ( not $call =~ m/^[a-zA-Z].*[0-9][a-zA-Z].*$/) { system(($^O eq 'MSWin32') ? 'cls' : 'clear'); print "invalid call \n"; next; }

Replies are listed 'Best First'.
Re: app via inetd and telnet, terminal handling weirdness
by cdarke (Prior) on Jan 31, 2010 at 11:01 UTC
    It sounds like your terminal settings. If you are accessing via telnet then you are probably using some sort of terminal emulator, depending on whose telnet package you are using. On UNIX you should set the TERM environment variable to the same terminal type that your remote package is emulating, and make sure that you export it. For example a basic emulation done by some primitive packages use the old DEC terminal vt52 as their emulation target, so on UNIX you would set:
    export TERM=vt52
    If using C shell (csh or tcsh) you will need:
    setenv TERM vt52
    If you set TERM in one of your start-up files (.profile, .kshrc, .bash_profile, .login depending on which shell version and whether the session is a login shell or not) then you have to beware that you might require a different type when not using telnet (xterm, for example).

    Display issues are often a mis-match of TERM and the emulator, or sometimes a really bad emulation. The fact that you do not have a problem when not using telnet only means that in that case your TERM setting is correct.

      I'll play with a few more TERM types. VT100 oddly enough results in a blank screen, where 'dumb' got it going again.

      This is not only telnet, but will be a telnet session gatewayed by a packet radio session...about as dumb an interface as is possible.

      Thanks for the reply

      So with fresh eyes after some sleep. I think what is happening is, in telnet or within the 'node' application wrapper as an alternate way to run it, I think the /n is being stripped or not sent upon <enter key> of the input, so a second <enter> is registering the input finally

      still no luck with various TERM types though

      Is there a way to push a /n back through the interface? Sort of pre-load <STDIN> with a /n ?