expectperl-discuss

[Expectperl-discuss] Solaris horizontal linewrap problem

[Miguel <mt...@mt...>]

Summary
-------
Problem with horizontal line-wrap when spawning telnet on SunOS 5.8.
How do I turn off this 'feature' of solaris in a portable way?

Detail
------
I developed some perl code which uses Expect on a linux box. The script
spawns telnet to talk to a cisco router. I encountered a problem when I
moved the script to a Solaris box (where I don't have much operational
experience).

When I $exp->send(a-line-of-text-which-is-very-long) then the echoed
results has lots of backspaces in it. I can see this behavior when I run
Solaris telnet from the command line ... rather than wrapping to the
next line the telnet is (apparently) doing me the 'favor' of wrapping
the text on the same line. The result is that my script is broken.

I tried setting $exp->raw_tty(1) ... no joy

I tried $exp->spawn('COLUMNS=250 ; telnet foo') ... no joy ... although
this does work from the command line

I tried $exp->spawn('TERM=dumb ; telnet foo') ... no joy ... although
this does work from the command line

I didn't see anything in the man page

I searched the web and found a few people complaining, but did not see a
fix.

bash has a similar feature. I saw one person complaining that bash was
broken was doing this to him on his Solaris system. I suspect that this
may have been a case of Solaris doing it to him.

Any suggestions?

Thanks in advance for your help.

Miguel

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Roland G. <Ro...@Gi...>]

Hmm, well I can confirm from my experience that solaris ptys are 
somewhat broken in many regards. But this doesn't help you. :-)

What comes to mind is to circumvent ptys completely. Have you considered 
using Net::Telnet instead of spawning a telnet program?

Hope this helps,

Roland

Miguel wrote:

> Summary
> -------
> Problem with horizontal line-wrap when spawning telnet on SunOS 5.8.
> How do I turn off this 'feature' of solaris in a portable way?
> 
> Detail
> ------
> I developed some perl code which uses Expect on a linux box. The script
> spawns telnet to talk to a cisco router. I encountered a problem when I
> moved the script to a Solaris box (where I don't have much operational
> experience).
> 
> When I $exp->send(a-line-of-text-which-is-very-long) then the echoed
> results has lots of backspaces in it. I can see this behavior when I run
> Solaris telnet from the command line ... rather than wrapping to the
> next line the telnet is (apparently) doing me the 'favor' of wrapping
> the text on the same line. The result is that my script is broken.
> 
> I tried setting $exp->raw_tty(1) ... no joy
> 
> I tried $exp->spawn('COLUMNS=250 ; telnet foo') ... no joy ... although
> this does work from the command line
> 
> I tried $exp->spawn('TERM=dumb ; telnet foo') ... no joy ... although
> this does work from the command line
> 
> I didn't see anything in the man page
> 
> I searched the web and found a few people complaining, but did not see a
> fix.
> 
> bash has a similar feature. I saw one person complaining that bash was
> broken was doing this to him on his Solaris system. I suspect that this
> may have been a case of Solaris doing it to him.
> 
> Any suggestions?
> 
> Thanks in advance for your help.
> 
> Miguel
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
> 
> 

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Miguel <mt...@mt...>]

> Hmm, well I can confirm from my experience that solaris ptys are
> somewhat broken in many regards. But this doesn't help you. :-)
>
> What comes to mind is to circumvent ptys completely. Have you considered
>  using Net::Telnet instead of spawning a telnet program?
Roland,

That sounds like a great idea.

I just took a look at the Expect & Net::Telnet man pages ... and frankly
it isn't yet clear to me how to hook to two together. That is ... what
method(s) do I use instead of $exp->spawn('telnet foo')

Any pointers would be appreciated

Gracias,
Miguel

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Austin S. <te...@of...>]

On Thu, May 01, 2003 at 11:45:25PM +0200, Miguel wrote:
> 
> > Hmm, well I can confirm from my experience that solaris ptys are
> > somewhat broken in many regards. But this doesn't help you. :-)
> >
> > What comes to mind is to circumvent ptys completely. Have you considered
> >  using Net::Telnet instead of spawning a telnet program?
> Roland,
> 
> That sounds like a great idea.
> 
> I just took a look at the Expect & Net::Telnet man pages ... and frankly
> it isn't yet clear to me how to hook to two together. That is ... what
> method(s) do I use instead of $exp->spawn('telnet foo')
> 
> Any pointers would be appreciated

	You can Expect-ize a Net::Telnet object by doing something like

$Expect::Exp_Internal = 1;

$t = new Net::Telnet();
$t->open($host);
$t->login($name, $pass);

$e = Expect->exp_init($t);

print $e "ls\r";

$e->expect(60, $prompt);


	though you may want to just look at the Net::Telnet native routines
such as 'cmd' and the like.

	There are basically two schools of thought. One is "use Net::Telnet
because it's the tool made for the protocol" (telnet in this case). It will
be more portable, and support protocol-specific functionality better as a
general rule. The other is "use Expect because you are lazy". Handy if you
are already familiar with it and don't need portability. The API is always
the same.

	Both schools of thought have their advantages, well at least IMO.
There's also a combo of the two, like you suggest, which is sort of a best
of both worlds approach where you let the protocol specific lib do the
dirty work, then use Expect afterwards.

	Austin

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Miguel <mt...@mt...>]

> 	You can Expect-ize a Net::Telnet object by doing something like
>
> $Expect::Exp_Internal = 1;
>
> $t = new Net::Telnet();
> $t->open($host);
> $t->login($name, $pass);
>
> $e = Expect->exp_init($t);
>
> print $e "ls\r";
>
> $e->expect(60, $prompt);
That looks great ... I'll give it a shot.

A suggestion ... I think it may be helpful for others to put an example
like this in the Expect man page.

The doc says that exp_init takes a \*FILEHANDLE.
And it looks like to me that Net::Telnet returns an object.
Even now I don't understand why this works ... so on my own I would never
have figured out this solution.

Just my 2c :)


> There's also a combo of the two, like you suggest, which is sort of a
> best of both worlds approach where you let the protocol specific lib do
> the dirty work, then use Expect afterwards.
In this particular case, since I have already written everything using
Expect, I think the right thing for me to do is only use Net::Telnet to
manage the raw connection ... as your example above.

In my quick read of Net::Telnet I saw that it generally uses the
prompt-string to determine when commands are done. Cisco routers change
the prompt string depending upon what kind of 'mode' you are in. That made
me think that Expect was more flexible.

Thanks to everyone for your help.


Adios,
Miguel

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Austin S. <te...@of...>]

On Fri, May 02, 2003 at 10:51:46AM +0200, Miguel wrote:
> That looks great ... I'll give it a shot.
> 
> A suggestion ... I think it may be helpful for others to put an example
> like this in the Expect man page.
> 
> The doc says that exp_init takes a \*FILEHANDLE.
> And it looks like to me that Net::Telnet returns an object.
> Even now I don't understand why this works ... so on my own I would never
> have figured out this solution.
> 
> Just my 2c :)

	Yeah, I agree, definitely an addition to he docs would be in order.
This will be a little weird, but I'll try a brief explanation anyway, which
will be inaccurate enough that Randal Schwartz would skin me for saying it,
but here goes:

	First part is that perl has a symbol table which uses "globs", which
are what things are named, basically. They are a separate variable type in
perl, that holds the other variable types in them that have the same name. They
are tagged by having a * in front of them, like *foo.

	For example:

*foo is the glob named 'foo'.
$foo is a scalar variable.
${ *foo } (or $*foo) is the scalar contained by the glob *foo.
$foo and $*foo are exactly the same thing.
%foo is a hash
%*foo is that exact same hash.
@foo is an array, @*foo is that same array, etc.

	Filehandles are their own variable type, like a hash or a scalar,
but there is no syntax in perl for dealing with them directly. This is a
language deficiency, admitted even by Larry Wall. The workaround is to refer
to the glob that holds the handle, from which a builtin function will be smart
enought to extract and use the handle. Thus you can do something like:

fileno(*STDIN);

	Which perl is nice enough to let you use without having to use the
'*', like:

fileno(STDIN);

	and the builtin fileno() function is smart enough to extract the handle
from the glob. But if you want a _reference_ to the glob, you can't do \STDIN,
because that confuses perl. So you have to explicitly refer to it as \*STDIN.

	Still awake? Ok, so when you have some sort of IO object, it's really
a glob reference. In fact, you can do things like:

print *$net_telnet "I'm printing stuff to the Net::Telnet object's handle\r";

	The important thing is that $net_telnet is a glob reference where the
glob contains a filehandle. Thus \*FILEHANDLE and $net_telnet are the same
kind of creature even though they look completely different.

	I didn't really understand globs when I wrote the early versions of
Expect, and some of the very crufty style choices in the module reflect this.
But they work, and in general ain't broke. One of these days when I have
too much time on my hands I'll submit a massive cleanup.

	Austin

P.S. Am I really responsible for ${${*$self}{exp_Function}}{$escape_sequence}?

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Roland G. <RGI...@cp...>]

>>	You can Expect-ize a Net::Telnet object by doing something like
>>
>>$Expect::Exp_Internal = 1;
>>
>>$t = new Net::Telnet();
>>$t->open($host);
>>$t->login($name, $pass);
>>
>>$e = Expect->exp_init($t);
>>
>>print $e "ls\r";
>>
>>$e->expect(60, $prompt);
>>
> That looks great ... I'll give it a shot.
> 
> A suggestion ... I think it may be helpful for others to put an example
> like this in the Expect man page.


OK, if you can provide a running example, I'll be glad to include it in 
the FAQs... :o)

Roland

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Miguel <mt...@mt...>]

>> That looks great ... I'll give it a shot.
>>
>> A suggestion ... I think it may be helpful for others to put an
>> example like this in the Expect man page.
>
>
> OK, if you can provide a running example, I'll be glad to include it in
> the FAQs... :o)
>
Well, I have an example that runs, but it doesn't do the right thing :(

The behavior is the same as before ... some evil spirit is still doing me
the favor of linewrapping.

I am completely dumbfounded. Went back to a Linux box and confirmed that I
don't get the behavior there.

For now I'm sticking with the 'stty columns 250 ; telnet foo' solution.

Miguel

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Austin S. <te...@of...>]

On Fri, May 02, 2003 at 08:14:21PM +0200, Miguel wrote:
> >> That looks great ... I'll give it a shot.
> >>
> >> A suggestion ... I think it may be helpful for others to put an
> >> example like this in the Expect man page.
> >
> >
> > OK, if you can provide a running example, I'll be glad to include it in
> > the FAQs... :o)
> >
> Well, I have an example that runs, but it doesn't do the right thing :(
> 
> The behavior is the same as before ... some evil spirit is still doing me
> the favor of linewrapping.
> 
> I am completely dumbfounded. Went back to a Linux box and confirmed that I
> don't get the behavior there.
> 
> For now I'm sticking with the 'stty columns 250 ; telnet foo' solution.
> 

	Setting environment variables doesn't change the behavior of your
terminal window. As best I could tell, it is the local host which decides
when output wraps - the remote host just sends it raw, and the local terminal
decides when there's too much, so inserts a newline.
	Setting  columns would be an option in the stty() routine, but
'columns' isn't part of the POSIX terminal spec, so isn't supported by stty(),
which uses the POSIX library for terminal handling. Thus the ugly kludge.
	Net::Telnet may save you here because it doesn't filter through a
terminal at all. Come to think of it, you could probably just use
open2 to start telnet without a terminal, then use Expect on the filehandles
open2 returns.

	Anyway, that's probably as much talk about globs and terminals that
anyone can handle this week. :-)

	Austin

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Austin S. <te...@of...>]

On Thu, May 01, 2003 at 08:39:18PM +0200, Miguel wrote:
> I tried setting $exp->raw_tty(1) ... no joy
> 
> I tried $exp->spawn('COLUMNS=250 ; telnet foo') ... no joy ... although
> this does work from the command line
> 
> I tried $exp->spawn('TERM=dumb ; telnet foo') ... no joy ... although
> this does work from the command line
> 
> I didn't see anything in the man page

	Here's a bit of ugliness that should work:

$telnet = $exp->spawn('stty columns 250; telnet foo');

	though Roland's suggestion of using Net::Telnet is a good bet.

	Austin

Re: [Expectperl-discuss] Solaris horizontal linewrap problem

[Miguel <mt...@mt...>]

> 	Here's a bit of ugliness that should work:
>
> $telnet = $exp->spawn('stty columns 250; telnet foo');
Yes, seems to work. Thanks!


> 	though Roland's suggestion of using Net::Telnet is a good bet.
I like this solution better ... since I've already been bitten by
something that didn't port.

But I'm still scratching my head trying to figure out how to hook the
Net::Telnet object and the Expect object together :)

Adios,
Miguel