Re: Looking to get lucky again with another expect question.
On 7/25/2011 1:48 PM, Steven W. Orr wrote: > I'm writing a pile of python code. There's a lot of remote execution going on > using ssh or the paramiko interface in python. Either way, I discovered a > startling nuance: > ... > #! /usr/bin/expect -- > spawn something > interact > > It's that middle line I don't know how to craft. > > Anyone? > > TIA > > Gentlemen, I thank you. I got the expect line I was looking for and I didn't know about the -t (or its paramiko equiv) to boot. :-) -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Looking to get lucky again with another expect question.
On Mon, Jul 25, 2011 at 1:48 PM, Steven W. Orr wrote: > The general solution would be to run an > expect script that would simply act as a passthrough to guarantee that > whatever I run would think it had a tty, and would therefore be line buffered > by default instead of fully buffered. I know it would look something like > this: > > #! /usr/bin/expect -- > spawn something > interact > > It's that middle line I don't know how to craft. I think you want: eval spawn $argv as the middle line. This should work most of the time -- you'll have to be careful of quoting since this will "eat" a layer of quotes. I think an even more general-purpose method would be to use the -t flag of ssh (if you're calling it directly) or something like paramiko.Channel.get_pty(). -Brian ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Looking to get lucky again with another expect question.
Try the -t option to force pty allocation? ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Looking to get lucky again with another expect question.
I'm writing a pile of python code. There's a lot of remote execution going on using ssh or the paramiko interface in python. Either way, I discovered a startling nuance: * When I run programs remotely which are shell scripts (bash), they behave like they are interactive, i.e., the output is line buffered. * When I run programs written in other languages, I see no output at all until the program finishes. Right now, the programs that I remotely execute are either bash or python. For the bash code, it is desirable that the line buffered output be maintained. For the python code, I added an option to the remote execution interface that says, "Run which on the remote side to get the pathname of the command, and then instead of running the command, run python -u pathname_of_command instead". The -u causes the python program to run unbuffered. But, this is not a general solution. The general solution would be to run an expect script that would simply act as a passthrough to guarantee that whatever I run would think it had a tty, and would therefore be line buffered by default instead of fully buffered. I know it would look something like this: #! /usr/bin/expect -- spawn something interact It's that middle line I don't know how to craft. Anyone? TIA -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/