odd chars in perldoc prior to 5.10.0 (was: Re: How to print question)

[szr]

Steven M. O'Neill wrote:
> mmccaws2 <mmc...@comcast.net> wrote:
>> Your code is almost exactly what I had. But what is the "$| = 1;"
>> for?
>
> perldoc perlvar | grep '$|'

After reading, I threw this into my linux console (where perldoc
defaults to my 5.8.8 installation compiled from the tarball.)

I noticed the grep didn't return any output. I then attempted using
perldoc from perl 5.10.0 (also compiled from tarball, using the same
options as I did for 5.8.8 if that means anything here) and it did
return the correct text:

$ perldoc5.8.8 perlvar | grep '$|'

$ perldoc5.10.0 perlvar | grep '$|'
$| If set to nonzero, forces a flush right away and after every
buffered by the system or not; $| tells you only whether
you�?Tve

---------1---------2---------3---------4---------5---------6---------7---------8

I greped a part of that text in perldoc 5.8.8:

$ perldoc5.8.8 perlvar | egrep 'If set to nonzero|buffered by the
system'
$�", If set to nonzero, forces a flush right away and after every
buffered by the system or not; $�", tells you only whether
you�?Tve

Same thing happens for 5.8.2, 5.8.0, and 5.6.1. Also notice how the line
beginning with "buffered" is offset by two characters, since there seems
to be two extra characters in the first line (where it should be just
$|)

Also, in any version, the "you've" at the end has extra characters as
well.

I've tried using different $TERM's (it's normally xterm) and different
fonts to no avail. In fact the only place it works right is to sit in
from the machine itself and log into a local console. Normally I ssh
into this machine from my main machine. I ssh using Secure CRT 5.5.3.

Yes, I realize this is may be a bit out of the scope of this news group,
but I would like to know if anyone else encountered this problem. I
suspect it is a term/font issue. (and I don't have this problem using
ActiveState 5.8.7 and 5.6.1 in XP PS2.)

Thank you.

--
szr

[Tad J McClellan]

szr <sz...@szromanMO.comVE> wrote:
> Steven M. O'Neill wrote:
>> mmccaws2 <mmc...@comcast.net> wrote:
>>> Your code is almost exactly what I had. But what is the "$| = 1;"
>>> for?
>>
>> perldoc perlvar | grep '$|'
>
> After reading, I threw this into my linux console (where perldoc
> defaults to my 5.8.8 installation compiled from the tarball.)
>
> I noticed the grep didn't return any output.

> I

> suspect it is a term/font issue.

You can eliminate term/font issues by using plain text:

perldoc -t perlvar | grep '$|'

--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"

[szr]

Tad J McClellan wrote:
> szr <sz...@szromanMO.comVE> wrote:
>> Steven M. O'Neill wrote:
>>> mmccaws2 <mmc...@comcast.net> wrote:
>>>> Your code is almost exactly what I had. But what is the "$| = 1;"
>>>> for?
>>>
>>> perldoc perlvar | grep '$|'
>>
>> After reading, I threw this into my linux console (where perldoc
>> defaults to my 5.8.8 installation compiled from the tarball.)
>>
>> I noticed the grep didn't return any output.
>
>
>> I
>> suspect it is a term/font issue.
>
>
> You can eliminate term/font issues by using plain text:
>
> perldoc -t perlvar | grep '$|'

Thank you, that does the trick.

--
szr

[Ted Zlatanov]

On Fri, 18 Apr 2008 06:51:19 -0500 Tad J McClellan <ta...@seesig.invalid> wrote:

TJM> You can eliminate term/font issues by using plain text:

TJM> perldoc -t perlvar | grep '$|'

This can be made permanent by setting the environment variable PERLDOC
to '-t' and then using perldoc as usual.

Ted

[Joe Smith]

szr wrote:

> $ perldoc5.8.8 perlvar | egrep 'If set to nonzero|buffered by the
> system'

> $ā", If set to nonzero, forces a flush right away and after every
> buffered by the system or not; $ā", tells you only whether
> youā?Tve

>
> I've tried using different $TERM's (it's normally xterm) and different
> fonts to no avail. In fact the only place it works right is to sit in
> from the machine itself and log into a local console. Normally I ssh
> into this machine from my main machine. I ssh using Secure CRT 5.5.3.

That's what happens when $ENV{LANG}='en_US.UTF-8' and Secure CRT
is set to "Character encoding: OEM" or anything but UTF-8.

Either 'setenv LANG en_US' or change the character encoding in Secure CRT.

-Joe

[szr]

Thanks, setting LANG=en_US did the trick (though leaving $LANG with
'en_US.UTF-8' and setting CRT to use UTF-8 yielded a non-responsive
console, and corruted output when I forced a reconnect, as if it did not
understand what it was getting from the server (perhaps a bug in parsing
UTF-8 output, or some other encoding issue.)

I'll just set LANG to en_US in my .bash_profile, thanks again.

--
szr