Beefy Boxes and Bandwidth Generously Provided by pair Networks vroom
Problems? Is your data what you think it is?

Re: Re: An introduction to POE

by RMGir (Parson)
on Aug 10, 2003 at 12:59 UTC ( #282605=note: print w/ replies, xml ) Need Help??

in reply to Re: An introduction to POE
in thread An introduction to POE

What platform did it freeze on? You may want to file a bug report.

I'm not sure what the behaviour of \n\r will be on different platforms.

I'm QUITE sure that using \012\015 is a bad idea. What if the poor user is running on a EBCDIC system? \n\r has a chance of doing the right thing, \012\015 doesn't.

You solution with signals does answer the original question, but the point wasn't to solve that problem perfectly, it was to introduce POE. Besides, you didn't implement command-line history or editing :)) (j/k)

Comment on Re: Re: An introduction to POE
Re: Re: Re: An introduction to POE
by rob_au (Abbot) on Aug 10, 2003 at 13:23 UTC
    I'm QUITE sure that using \012\015 is a bad idea ... \n\r has a chance of doing the right thing.

    Um, I don't think so - Read the perlport man page under the heading "Newlines". To quote:

    A common misconception in socket programming is that "\n" eq "\012" everywhere. When using protocols such as common Internet protocols, "\012" and "\015" are called for specifically, and the values of the logical "\n" and "\r" (carriage return) are not reliable.

    print SOCKET "Hi there, client!\r\n"; # WRONG print SOCKET "Hi there, client!\015\012"; # RIGHT

    This is equally applicable to the use of the literal \r and \n in general programming.


    perl -le 'print+unpack"N",pack"B32","00000000000000000000001001111000"'

      (We're getting pretty far off the topic of POE here...)

      You are correct for network protocols. Of course, at that level it's important that the correct bytes are sent, if you're doing raw FTP or RSH, for instance.

      But for terminal interactions, you have to have "the right thing" happen. And what does the right thing can be different from platform to platform. In those cases, I think \n and \r are the correct choices.

      Even if you're accessing another system remotely, it's the terminal driver on that system that will make the decision how to translate local \n into the right thing on the wire.

        Even when it comes to network protocols, "\r" and "\n" can be a better choice than "\012\015". In fact, the only reason this "\012\015" has become popular is the old Macintosh! If it weren't for that, then there would be no case where "\012\015" was a better choice.

        Consider running Perl on an EBCDIC system (yes, there are such ports of Perl) trying to talk SMTP to send mail. You need to say "HELO\n" but try to be "portable" and say "HELO\012". You think the SMTP server you are talking to is going recognize "HELO" in EBCDIC?? Of course not. Which means that on an EBCDIC system talking over some socket emulation, you are going to be going through a EBCDIC/ASCII converting gateway and if you send "\012" through that from the EBCDIC side, it isn't going to reach the other side as "\n". You want "HELO\n".

        It is sad that the old Mac mistakes have so confused people about what is portable code. "\012\015" is portable to the old Mac but is very specific to the near-ASCII nature of old Macs. Using such without first testing whether you are on a system where it works just indicates that you don't care about alternate character encodings. ASCII has become so popular that you can probably justify this sometimes.

        But I find it silly that people proclaim how this makes their code more portable. It is just an old Mac thing. I'm not sure what non-ASCII environments Perl will end up running on; probably not very many. But hard-coding magic numbers is just not the way to go.

        See Re^4: Line Feeds (rumor control) for if you want more on this. (:

                        - tye
Re: Re: Re: An introduction to POE
by rcaputo (Chaplain) on Aug 28, 2003 at 06:09 UTC

    Some versions of Linux don't seem to get along with non-blocking ReadKey. I received a test case about it in e-mail on 23 August:

    #!/usr/bin/perl use Term::ReadKey; ReadMode 5; # Turn off controls keys while (1) { while (not defined ($key = ReadKey(-1))) { print "Foo\n"; sleep (1); } print "Get key $key\n"; ($key eq 'q') and last; } ReadMode 0; # Reset tty mode before exiting

    If the test case fails for you, please e-mail a note to so (a) I'll see it, and (b) I won't forget it. :) Since it's a platform-dependent problem, it would help a lot if output from uname -a and perl -V were included. Thanks.

    -- Rocco Caputo - -

      (Also emailed as requested)

      It's not very happy on a redhat 9 box:

      perl Foo Foo Foo Foo Foo Foo Foo Foo Foo Foo Terminated ~/xml mike@tux6202 $ qqqqqqq ~/xml $ perl -v This is perl, v5.8.0 built for i386-linux-thread-multi (with 1 registered patch, see perl -V for more detail) Copyright 1987-2002, Larry Wall ... ~/xml $ uname -a Linux tuxXXXX 2.4.20-18.9smp #1 SMP Thu May 29 06:55:05 EDT 2003 i686 +i686 i386 GNU/Linux
      It DOES, however, work fine on a Redhat 7.x box with perl 5.6.1, with uname info:
      Linux tuxYYY 2.4.18-26.7.xsmp #1 SMP Mon Feb 24 09:37:16 EST 2003 i68 +6 unknown


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://282605]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2014-04-19 02:55 GMT
Find Nodes?
    Voting Booth?

    April first is:

    Results (475 votes), past polls