Menu
▾
▴
expectperl-discuss
|
From: Anders W. <And...@ac...> - 2002-08-27 19:58:21
|
I've run into this as well. I've been able to work around it by start up a
plain-old sh and launching it from there. Very annoying, though.
anders
-----Original Message-----
From: Jason Penney [mailto:jas...@su...]
Sent: Tuesday, August 27, 2002 12:48 PM
To: exp...@li...
Subject: [Expectperl-discuss] Problem running in bg
Hi,
I'm trying to run my perl code in the background under Solaris (tried
under 5.6,7 and 9), but if I use Expect it hangs with "Suspended (tty
output)". I'm using perl 5.8.0.
Here's my test file:
#!/usr/bin/env perl
use Expect;
print STDERR "launching\n";
my $exp = Expect->new();
$exp->spawn("/sbin/sh");
print STDERR "launched\n";
% ./test.pl
launching
launched
% ./test.pl &
[3] 4179
% launching
[3] + Suspended (tty output) ./test.pl
Any help would be greatly appreciated!
Thanks,
Jay Penney
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Expectperl-discuss mailing list
Exp...@li...
https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
|
|
From: Jason P. <jas...@su...> - 2002-08-28 11:37:48
|
That seems to work, but does anyone know why? It's not an optimal
solution as this is an app that other's are using as well. I had been
running the same code fine under perl 5.6.1 with an older Expect.pm and
IO::Pty.pm.
Thanks!
Jay
Alexander Bourov wrote:
> Jason, I had the same effect on Solaris under ksh and bash.
> Try the same from the sh and it will work fine.
>
> -----Original Message-----
> From: Jason Penney [mailto:jas...@su...]
> Sent: Tuesday, August 27, 2002 12:48 PM
> To: exp...@li...
> Subject: [Expectperl-discuss] Problem running in bg
>
>
> Hi,
>
> I'm trying to run my perl code in the background under Solaris (tried
> under 5.6,7 and 9), but if I use Expect it hangs with "Suspended (tty
> output)". I'm using perl 5.8.0.
>
> Here's my test file:
>
> #!/usr/bin/env perl
>
> use Expect;
>
> print STDERR "launching\n";
> my $exp = Expect->new();
> $exp->spawn("/sbin/sh");
> print STDERR "launched\n";
>
>
> % ./test.pl
> launching
> launched
>
> % ./test.pl &
> [3] 4179
> % launching
> [3] + Suspended (tty output) ./test.pl
>
> Any help would be greatly appreciated!
>
> Thanks,
> Jay Penney
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Expectperl-discuss mailing list
> Exp...@li...
> https://lists.sourceforge.net/lists/listinfo/expectperl-discuss
|
|
From: Blackstone, J. D. <jda...@ci...> - 2002-08-28 13:24:25
|
> -----Original Message----- > From: Jason Penney [mailto:jas...@su...] > Sent: Wednesday, August 28, 2002 6:37 AM > To: Alexander Bourov; exp...@li... > Subject: Re: [Expectperl-discuss] Problem running in bg > > > That seems to work, but does anyone know why? It's not an optimal > solution as this is an app that other's are using as well. I > had been > running the same code fine under perl 5.6.1 with an older > Expect.pm and > IO::Pty.pm. > > Thanks! > Jay Did it change when you went to 5.8.0 then? You might report it to p5p, although at this point I don't think we have the behavior isolated down to the root of what's causing it. (Ideally someone with a lot of time would trace through the code in Expect.pm to find out where it happens, and build a minimal test case requiring no additional modules.) jdb |
|
From: Jason P. <jas...@su...> - 2002-08-28 14:21:23
|
Blackstone, J. David wrote: > >>-----Original Message----- >>From: Jason Penney [mailto:jas...@su...] >>Sent: Wednesday, August 28, 2002 6:37 AM >>To: Alexander Bourov; exp...@li... >>Subject: Re: [Expectperl-discuss] Problem running in bg >> >> >>That seems to work, but does anyone know why? It's not an optimal >>solution as this is an app that other's are using as well. I >>had been >>running the same code fine under perl 5.6.1 with an older >>Expect.pm and >>IO::Pty.pm. > Did it change when you went to 5.8.0 then? You might report it to p5p, > although at this point I don't think we have the behavior isolated down to > the root of what's causing it. (Ideally someone with a lot of time would > trace through the code in Expect.pm to find out where it happens, and build > a minimal test case requiring no additional modules.) I just rebuilt IO-Tty-1.02 and Expect-1.15 under a clean install of 5.6.1 and the same thing happens. It seems to happen somewhere during Expect::spawn. Jay |
|
From: Anders W. <And...@ac...> - 2002-08-28 14:28:50
|
In my case, I'm seeing the behavior with 5.6.1. It's been a while since I tracked it down, but I seem to remember that it ran into trouble in IO::Pty::make_slave_controlling_terminal. anders -----Original Message----- From: Blackstone, J. David [mailto:jda...@ci...] Sent: Wednesday, August 28, 2002 6:24 AM To: Jason Penney; Alexander Bourov; exp...@li... Subject: RE: [Expectperl-discuss] Problem running in bg > -----Original Message----- > From: Jason Penney [mailto:jas...@su...] > Sent: Wednesday, August 28, 2002 6:37 AM > To: Alexander Bourov; exp...@li... > Subject: Re: [Expectperl-discuss] Problem running in bg > > > That seems to work, but does anyone know why? It's not an optimal > solution as this is an app that other's are using as well. I > had been > running the same code fine under perl 5.6.1 with an older > Expect.pm and > IO::Pty.pm. > > Thanks! > Jay Did it change when you went to 5.8.0 then? You might report it to p5p, although at this point I don't think we have the behavior isolated down to the root of what's causing it. (Ideally someone with a lot of time would trace through the code in Expect.pm to find out where it happens, and build a minimal test case requiring no additional modules.) jdb ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Expectperl-discuss mailing list Exp...@li... https://lists.sourceforge.net/lists/listinfo/expectperl-discuss |
|
From: Roland G. <RGi...@cp...> - 2002-08-29 08:36:19
|
> It's been a while since I tracked it down, but I seem to remember > that it ran into trouble in IO::Pty::make_slave_controlling_terminal. IO-Tty and Expect now correctly handle the controlling terminal of the spawned process, that is, the spawned process runs in its own process group and gets the slave pty set as its controlling terminal (otherwise Expect wouldn't be able to handle password prompts). But this process group gets into the way of the shells job control. /bin/sh doesn't have job control, that's why the mentioned workaround works. Another way would be to use the utility 'nohup' (don't know, which system it is available on, I have it here on AIX) for putting commands into the background. It also handles the case that the background process would get a SIGHUP if the user logs out of the foregropund shell... Hope this helps, Roland -- RGi...@cp... |
|
From: Austin S. <te...@of...> - 2002-08-29 19:41:33
|
On Thu, Aug 29, 2002 at 10:35:30AM +0200, Roland Giersig wrote: > > It's been a while since I tracked it down, but I seem to remember > > that it ran into trouble in IO::Pty::make_slave_controlling_terminal. > > IO-Tty and Expect now correctly handle the controlling terminal of the > spawned process, that is, the spawned process runs in its own process > group and gets the slave pty set as its controlling terminal (otherwise > Expect wouldn't be able to handle password prompts). The spawned process needs its own session id, via setsid(). That sets the process to expect control chars from the newly created terminal. Process group affects how signals are processed - when a process is killed all the children in the process group are HUPped. Typically these are the same, but not so for expect. With expect you want the spawned process to have its own session id so it can get signals from the parent, but you want to leave the process group alone so when the parent process dies it takes the spawned children with it. Presumably if you didn't like the behavior you could run setpgrp() from the child, thus letting it remain when the parent dies. Well, as long as you didn't try to read from /dev/tty or STDIN after that. At least that's how it seemed to be working when I was monkeying with it. :-) Austin |
|
From: Blackstone, J. D. <jda...@ci...> - 2002-08-29 13:58:49
|
> workaround works. Another way would be to use the utility 'nohup'
> (don't know, which system it is available on, I have it here on AIX)
nohup is fairly universal. I know it's on Linux, Solaris, and
that-Alpha-UNIX-that-keeps-changing-its-name.
But if it's not around, you can always roll your own with Perl!
#!perl
$SIG{HUP} = 'IGNORE';
exec @ARGV;
I never realized you were on AIX. Cool.
jdb
|
|
From: Anders W. <And...@ac...> - 2002-08-29 14:47:27
|
I've tried using nohup (from bash), but it doesn't fix the problem. From what I've been able to find, this problem only exists on Solaris. I found a good description of the problem at http://archive.develooper.com/per...@pe.../msg61417.html <http://archive.develooper.com/per...@pe.../msg61417.html> -- this person seems to have tracked the problem down: Please consider the following minimal perl program: perl -MIO::Pty -e'$T=new IO::Pty;print ${*$T}{'io_pty_ttyname'};if(-t $T){print " is a tty\n";}else{print " is no tty\n";}' You would expect it to print "xxx is a tty" in _any_ case. In fact, it does not. IRIX64 6.5 : /dev/ttyq8 is a tty SunOS 5.6 : /dev/pts/11 is no tty Linux 2.2 (Redhat 7.0): /dev/pts/1 is a tty AIX 4.3 : /dev/pts/3 is a tty All of them are Perl 5.6 with current IO::Pty. Tty.xs seems to have to wade through pretty thick muck to implement OpenPTY (which is called by IO::Pty::new()). I guess something in there goes wrong. ************* end original bugreport ******************** This might be good or bad, the problem is that this behavior breaks Expect.pm. An Expect object inherits from IO::Pty. The function Expect::exp_stty() calls both POSIX::isatty() (which fails because its identical to -t) and IO::Stty::stty(). IO::Stty::stty() calls isatty() and a lot of terminal related stuff I don't really understand. Anyhow the first isatty() will kill Expect::exp_stty(). This is the reason I believe this is a bug: It breaks the Expect module. anders -----Original Message----- From: Roland Giersig [mailto:RGi...@cp...] Sent: Thursday, August 29, 2002 1:36 AM To: Anders Wallgren Cc: 'Blackstone, J. David'; Jason Penney; Alexander Bourov; exp...@li... Subject: RE: [Expectperl-discuss] Problem running in bg > It's been a while since I tracked it down, but I seem to remember > that it ran into trouble in IO::Pty::make_slave_controlling_terminal. IO-Tty and Expect now correctly handle the controlling terminal of the spawned process, that is, the spawned process runs in its own process group and gets the slave pty set as its controlling terminal (otherwise Expect wouldn't be able to handle password prompts). But this process group gets into the way of the shells job control. /bin/sh doesn't have job control, that's why the mentioned workaround works. Another way would be to use the utility 'nohup' (don't know, which system it is available on, I have it here on AIX) for putting commands into the background. It also handles the case that the background process would get a SIGHUP if the user logs out of the foregropund shell... Hope this helps, Roland -- RGi...@cp... |
|
From: Roland G. <RGi...@cp...> - 2002-08-29 15:03:07
|
Quoting Anders Wallgren <And...@ac...>: > I've tried using nohup (from bash), but it doesn't fix the problem. > From what I've been able to find, this problem only exists on Solaris. OK, I took a look at some nohup source code and indeed it only fixes SIGHUP, but not the problem with job control. Sorry for the false lead. > I found a good description of the problem at > http://archive.develooper.com/per...@pe.../msg61417.html > <http://archive.develooper.com/per...@pe.../msg61417.html> ... > IRIX64 6.5 : /dev/ttyq8 is a tty > SunOS 5.6 : /dev/pts/11 is no tty > Linux 2.2 (Redhat 7.0): /dev/pts/1 is a tty > AIX 4.3 : /dev/pts/3 is a tty I don't think this is the real reason. What this list shows is that the _master_ part of the pty might not be a tty, which is annoying (you have to set tty parameters via the slave fd) but no bug by itself. There might be a coincident that only Solaris shows this behaviour, but Solaris is different in many other ways too. The problem with background execution has to do with the controlling terminal and process groups, I'm sure about that. But I have no idea how to solve it within the realms of IO-Tty or Expect. [BTW, the latest IO-Tty and Expect versions do take into account that the master pty may not be a tty; also IO::Stty is now optional, so that bug report is obsolete.] Hope this clarifies somewhat. Roland -- RGi...@cp... |
|
From: Anders W. <And...@ac...> - 2002-08-29 15:07:22
|
Fair enough. I'm happy to help sort this out -- I would really like to get past this problem. anders -----Original Message----- From: Roland Giersig [mailto:RGi...@cp...] Sent: Thursday, August 29, 2002 8:02 AM To: Anders Wallgren Cc: 'Blackstone, J. David'; 'Jason Penney'; 'Alexander Bourov'; 'exp...@li...' Subject: RE: [Expectperl-discuss] Problem running in bg Quoting Anders Wallgren <And...@ac...>: > I've tried using nohup (from bash), but it doesn't fix the problem. > From what I've been able to find, this problem only exists on Solaris. OK, I took a look at some nohup source code and indeed it only fixes SIGHUP, but not the problem with job control. Sorry for the false lead. > I found a good description of the problem at > http://archive.develooper.com/per...@pe.../msg61417.html > <http://archive.develooper.com/per...@pe.../msg61417.html> ... > IRIX64 6.5 : /dev/ttyq8 is a tty > SunOS 5.6 : /dev/pts/11 is no tty > Linux 2.2 (Redhat 7.0): /dev/pts/1 is a tty > AIX 4.3 : /dev/pts/3 is a tty I don't think this is the real reason. What this list shows is that the _master_ part of the pty might not be a tty, which is annoying (you have to set tty parameters via the slave fd) but no bug by itself. There might be a coincident that only Solaris shows this behaviour, but Solaris is different in many other ways too. The problem with background execution has to do with the controlling terminal and process groups, I'm sure about that. But I have no idea how to solve it within the realms of IO-Tty or Expect. [BTW, the latest IO-Tty and Expect versions do take into account that the master pty may not be a tty; also IO::Stty is now optional, so that bug report is obsolete.] Hope this clarifies somewhat. Roland -- RGi...@cp... |
|
From: Anders W. <And...@ac...> - 2002-08-29 20:02:45
|
If I remember correctly, it never makes it out of the call to spawn, so I
can't do that.
anders
-----Original Message-----
From: Austin Schutz [mailto:te...@of...]
Sent: Thursday, August 29, 2002 12:53 PM
To: ex...@ih...
Cc: exp...@li...; jas...@su...
Subject: Re: [Expectperl-discuss] Problem running in bg
On Thu, Aug 29, 2002 at 09:23:20AM -0700, ex...@ih... wrote:
> >
> > print STDERR "launching\n";
> > my $exp = Expect->new();
> > $exp->spawn("/sbin/sh");
> > print STDERR "launched\n";
> > % ./test.pl
> > launching
> > launched
> >
> > % ./test.pl &
> > [3] 4179
> > % launching
> > [3] + Suspended (tty output) ./test.pl
> >
Have you tried reading from the tty to see if that wakes sh up?
i.e.:
$exp->spawn("/sbin/sh");
$exp->expect(undef,'$ ');
print STDERR "launched\n";
Austin
-------------------------------------------------------
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
|
|
From: Kevin S. <ke...@ne...> - 2002-08-30 07:22:09
|
Has anyone tried to control screen with expect?
I would like to get a perl prog to start a screen
Then run an app and disconnect.
Then at some time later (possibly weeks) connect to the screen and issue
commands to the prog running in the screen, with the possibility of
stoping (ctrl-c) and restarting the app in the same screen process
screen -C "command" does not work as screen exits when the command exits
this is the basic outline and fails miserably
#!/usr/bin/perl -w
use strict;
use Expect;
my $screen="/usr/bin/screen";
my @args=("-S","bob");
my $app=Expect->spawn($screen,@args);
#unless ($app->expect(10,-re,"\$")){
# print "did not get prompt\n";
# exit;
#}
print "got prompt\n";
sleep 1;
$app->print("echo hello\r");
#unless ($app->expect(10,"$ARGV[1]")){
# print "did not get text back\n";
# exit;
#}
print "closing\n";
$app->print("\001\003");
unless ($app->expect(10,"screen is terminating")){
print "did not detach\n";
}
print "done\n";
|
|
From: Simon T. <si...@un...> - 2002-08-30 07:59:08
|
Hello Kevin,
> Has anyone tried to control screen with expect?
>
> I would like to get a perl prog to start a screen
> Then run an app and disconnect.
>
> Then at some time later (possibly weeks) connect to the screen and issue
> commands to the prog running in the screen, with the possibility of
> stoping (ctrl-c) and restarting the app in the same screen process
>
> screen -C "command" does not work as screen exits when the command exits
I remember screen!
Here is a quick script that seemed to work for me. (Well at least it is able
to spawn "screen", get the help screen and then exit gracefully). If "screen"
allows you to disconnect and leave programs running, then I suppose that
you'll be able to do this via expect also.
As an aside, Don Libes' "Exploring Expect" is a great reference for the (TCL)
expect. It includes a fabulous script called "dislocate" (described at page
384) that does exactly what you want.
Someone may have already implemented this via the perl Expect, in which case
"screen" would not be required at all.
Hope this helps.
Regards,
Simon Taylor
#!/usr/bin/perl -w
use strict;
use Expect;
my $screen="/usr/bin/screen";
my @args=("-S","bob");
my $app=Expect->spawn($screen,@args);
$app->log_stdout(1);
$app->log_user(1);
unless ($app->expect(10,-re,"\$")){
print "did not get prompt\n";
exit;
}
print "got prompt\n";
$app->print("\ca?");
unless ($app->expect(10,"Press Space for next page; Return to end")) {
print "did not see help screen\n";
exit;
}
print "got help prompt\n";
$app->print("\r"); # #Exit from help screen
$app->hard_close();
print "done\n";
exit;
--
Unisolve Pty Ltd - Melbourne, Australia
+61 3 9568 2005
|
|
From: Austin S. <te...@of...> - 2002-09-01 08:53:05
|
On Fri, Aug 30, 2002 at 05:56:11PM +1000, Simon Taylor wrote: > As an aside, Don Libes' "Exploring Expect" is a great reference for the (TCL) > expect. It includes a fabulous script called "dislocate" (described at page > 384) that does exactly what you want. > Just FYI, I don't think anyone's ever bothered to write Perl equivalents to the many handy expect tools included w/ the Tcl expect. If it ain't broke, etc. Seems like a Perl equivalent for autoexpect that writes Perl code might be handy. Maybe one of these days when I have too much free time... Austin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X