expectperl-discuss — Discussions about Perl modules Expect.pm, IO::Tty and IO::Stty

[Expectperl-discuss] Perl, Expect under the Win2k.

[<ab...@en...>]

If anybody using Perl & Expect.pm under the Win2k, could you please give =
me recommendations on:
1. Which Perl to install :   Active Perl, CygWin .....
2. Any specifics on Expect.pm for Win2k?

I'm using Expect.pm for almost a year on Solaris and mostly happy with =
it, but I have to move some staff to Win2k environment and need advise.

Thanks in advance,=20

Alex Bourov.

RE: [Expectperl-discuss] Problems using expect module

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

>> chatlh!  bIbachHa'pu'!  DON'T DO THAT!
> 
>   Oh?  So now Damian's Lingua::tlhIngan is a prerequisite for
> Expect.pm?

No, I was just practising my klingon swearing...

Ha'DIbaH!  Hab SoSlI' Quch!

But maybe the next Expect version will be using 
Lingua::Romana::Perligata... ;-)

maj ram!

Ho'lanD
-- 
RGi...@cp...

RE: [Expectperl-discuss] Problems using expect module

[Blackstone, J. D. <jda...@ci...>]

> -----Original Message-----
> From: Roland Giersig [mailto:RGi...@cp...]
>
> chatlh!  bIbachHa'pu'!  DON'T DO THAT!

  Oh?  So now Damian's Lingua::tlhIngan is a prerequisite for Expect.pm?

  :)

jdb

Re: [Expectperl-discuss] Problems using expect module

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

> Also I have attached the higher version of the Io:Tty, IO:Pty and
> Expect Modules with this mail.
...
> <<IO-Tty-11.01.tar.gz>>

chatlh!  bIbachHa'pu'!  DON'T DO THAT!

The latest version is IO-Tty-1.02.tar.gz, why your attached tar file 
has 11.01, I can only guess: did you re-package it?

I appreciate that you are trying to be helpful, but the correct 
procedure is to point people to CPAN, where tehy can get the latest 
version.  Please stop sending software modules around, this is bad 
practice.

Roland
-- 
RGi...@cp...

Re: [Expectperl-discuss] Communicating with modem

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

> It's been awhile since I've worked with modems, but IIRC you need
> to stty('raw') the line before talking to the modem. In particular
> I think they don't like the default 'ICANON' setting.

Please note that you can do this directly from Expect, without getting 
stty involved:

  my $exp = new Expect;
  $exp->raw_pty(1);
  $exp->spawn($command, @parameters)
     or die "Cannot spawn $command: $!\n";

Roland
--
Ro...@Gi...

RE: [Expectperl-discuss] Problems using expect module

[Rogaski, M. A. <ro...@at...>]

> The error I'm getting when running the script is:
> Can't locate loadable object for module IO::Tty in @INC (@INC =
contains: =
/usr/local/freeware/perl/perl5.005_03/lib/perl5/5.00503/sun4-solaris=20
>

Greg,

You need to install IO::Tty.

http://search.cpan.org/author/RGIERSIG/IO-Tty-1.02/Tty.pm

Mark

--
[] Mark Rogaski                    "Computers save time like=20
[] AT&T Frame Relay Service           kudzu prevents soil erosion"
[] email: ro...@at...                          -- Al Castanoli
[] voice: 732-885-7534 fax: 732-885-7699
[] pager: 888-858-7243 pin 200853 or 20...@pa...=20

[Expectperl-discuss] Problems using expect module

[Greg D. <gd...@br...>]

I'm tyring to run a simple script to test if the expect module works, here
is the script:
 
#!/import/local/bin/perl
use Expect;
$c = Expect->spawn("/bin/telnet host");
 
 
The error I'm getting when running the script is:
Can't locate loadable object for module IO::Tty in @INC (@INC contains:
/usr/loc
al/freeware/perl/perl5.005_03/lib/perl5/5.00503/sun4-solaris
/usr/local/freeware
/perl/perl5.005_03/lib/perl5/5.00503
=/usr/local/freeware/perl/perl5.005_03/lib/
perl5/site_perl/5.00503/sun4-solaris
/usr/local/freeware/perl/perl5.005_03/lib/p
erl5/site_perl/5.00503 .) at
/usr/local/freeware/perl/perl5.005_03/lib/perl5/sit
e_perl/5.00503/IO/Tty.pm line 26
BEGIN failed--compilation aborted at
/usr/local/freeware/perl/perl5.005_03/lib/p
erl5/site_perl/5.00503/IO/Pty.pm line 7.
BEGIN failed--compilation aborted at
/usr/local/freeware/perl/perl5.005_03/lib/p
erl5/site_perl/5.00503/Expect.pm line 19.
BEGIN failed--compilation aborted at ./frontend_for_input_file line 2.
 
I'm using Perl v5.005_03 under Solaris 7, not sure on the Expect module
version.
 
Any ideas?
Thanks in advance
Greg

Re: [Expectperl-discuss] Communicating with modem

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

On Mon, Sep 23, 2002 at 12:32:45PM -0400, Hal Vaughan wrote:
> I'm using expect to dial up a remote system, retreive data, then log off.  
> Other perl scripts then process the data.
> 
> The problem is in communicating with my modem.  I've noticed that when I first 
> re-boot (and possibly other times, but I'm not sure), when I run this 
> program, I keep getting an endless string of ^H from the modem.  If, instead, 
> I run Minicom, then quit without sending the termination strings  (quitting 
> instead of a "regular" exit from the program), then run my perl programs, I 
> have no problem accessing the modem.
> 
> Is this an Expect problem, or is Minicom doing something in C that Perl 
> doesn't do?  I don't know C, but as best I can tell Minicom does some things 
> with ioctl (and perhaps more), but I have no clear idea what's going on.
> 
> Any ideas?
> 

	It's been awhile since I've worked with modems, but IIRC you need to
stty('raw') the line before talking to the modem. In particular I think they
don't like the default 'ICANON' setting.
	I think most of the time I've just spawned cu (comes w/ taylor uucp
package) rather than work with the modem directly anyway. It does locking
on the device, among other benefits. YMMV.

	Austin

[Expectperl-discuss] Communicating with modem

[Hal V. <ha...@th...>]

I'm using expect to dial up a remote system, retreive data, then log off.=
 =20
Other perl scripts then process the data.

The problem is in communicating with my modem.  I've noticed that when I =
first=20
re-boot (and possibly other times, but I'm not sure), when I run this=20
program, I keep getting an endless string of ^H from the modem.  If, inst=
ead,=20
I run Minicom, then quit without sending the termination strings  (quitti=
ng=20
instead of a "regular" exit from the program), then run my perl programs,=
 I=20
have no problem accessing the modem.

Is this an Expect problem, or is Minicom doing something in C that Perl=20
doesn't do?  I don't know C, but as best I can tell Minicom does some thi=
ngs=20
with ioctl (and perhaps more), but I have no clear idea what's going on.

Any ideas?

Thanks!

RE: [Expectperl-discuss] Expect and passwd

[Walls R. W C. 75 CS/S. <Rob...@HI...>]

Hey! Sleeping for 1 sec after the spawn seems to have fixed the problem.
Thanks!
 

-----Original Message-----
From: Austin Schutz [mailto:te...@of...]
Sent: Monday, September 09, 2002 12:34 PM
To: Walls Rob W Contr 75 CS/SCBS
Cc: 'Roland Giersig'; 'exp...@li...'
Subject: Re: [Expectperl-discuss] Expect and passwd


On Mon, Sep 09, 2002 at 12:17:41PM -0600, Walls Rob W Contr 75 CS/SCBS
wrote:
> I removed the explicitly added \n from the password ->send string.  Now
> debug reports Sending '1derful^J' to spawn id(3) instead of the
> '1derful\n\012' it was sending. However, the intermittent hang still
occurs.
> When things hang, Expect receives the password instead of 'New password'.
> That is:
> Waiting for new data ...
> 1derful
> 
> instead of:
> 
> Waiting for new data ...
> New password:
> It's like the answer arrives before the question is asked...

	Typically a well written password program, i.e. one that asks
for a password, should turn echoing off before printing the 'Password: '
prompt. Some programs, such as /bin/passwd included w/ redhat 6.2, send the
password prompt, and then flush the pty buffer as they set '-echo' on the
line.
This creates a race condition that may be experienced maybe 2-5% of the
time.
	I would first turn on $Exp_Internal and make sure you are expecting
a space after 'New password:', if one is sent. Once that is correct and you
are 100% sure you're matching the correct prompt, sleep(1) before
sending the password. That way you will give the program a chance to set
echoing off and get ready to receive the data well before you send it.

	Austin

Re: [Expectperl-discuss] Expect and passwd

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

On Mon, Sep 09, 2002 at 12:17:41PM -0600, Walls Rob W Contr 75 CS/SCBS wrote:
> I removed the explicitly added \n from the password ->send string.  Now
> debug reports Sending '1derful^J' to spawn id(3) instead of the
> '1derful\n\012' it was sending. However, the intermittent hang still occurs.
> When things hang, Expect receives the password instead of 'New password'.
> That is:
> Waiting for new data ...
> 1derful
> 
> instead of:
> 
> Waiting for new data ...
> New password:
> It's like the answer arrives before the question is asked...

	Typically a well written password program, i.e. one that asks
for a password, should turn echoing off before printing the 'Password: '
prompt. Some programs, such as /bin/passwd included w/ redhat 6.2, send the
password prompt, and then flush the pty buffer as they set '-echo' on the line.
This creates a race condition that may be experienced maybe 2-5% of the time.
	I would first turn on $Exp_Internal and make sure you are expecting
a space after 'New password:', if one is sent. Once that is correct and you
are 100% sure you're matching the correct prompt, sleep(1) before
sending the password. That way you will give the program a chance to set
echoing off and get ready to receive the data well before you send it.

	Austin

RE: [Expectperl-discuss] Expect and passwd

[Walls R. W C. 75 CS/S. <Rob...@HI...>]

I removed the explicitly added \n from the password ->send string.  Now
debug reports Sending '1derful^J' to spawn id(3) instead of the
'1derful\n\012' it was sending. However, the intermittent hang still occurs.
When things hang, Expect receives the password instead of 'New password'.
That is:
Waiting for new data ...
1derful

instead of:

Waiting for new data ...
New password:
(and THEN receiving the password from ->send)
It's like the answer arrives before the question is asked...

I tried chomping the input passwords, but that did no good.
I am using Term::ReadKey to input the password. Could there be some buffer
issues with just loading that module?
I hard coded the password string "1derful\n" and did not use ReadKey at all
and things seem to work consistently. 
I could get the password as an arg, but that puts the password on the
screen.
I could also use getc instead of ReadKey, but I don't know how to turn off
echo. I tried 
  system "stty cbreak </dev/tty >/dev/nul";
but that still echo'd.

Anyway, I am just trying to change system and Samba passwords at the same
time and do some other updates to files when I or my users change their
passwords.
Do you have any ideas on a better way to do this? I am sure it has been done
before, and I'm not too proud to use someone else's code!
Expect seems like the natural thing to use to glue things together, so maybe
you've seen something like this (many times?)
Thanks for the help.

-----Original Message-----
From: Roland Giersig [mailto:RGi...@cp...]
Sent: Thursday, September 05, 2002 1:48 AM
To: Walls Rob W Contr 75 CS/SCBS
Cc: 'exp...@li...'
Subject: RE: [Expectperl-discuss] Expect and passwd


> Sometimes it fails 1st then starts working and other times it works
> and them fails, if that makes any difference (or sense...)
...
> Sending '1derful\n\012' to spawn id(3)

OK, that was a subtle one: you are not chomping the entered password, 
so when you send it, it contains TWO \n.  passwd clears it's readline 
buffer before reading the password, but depending things beyond 
control, the second \n might or might not be in the buffer to be 
cleared.  If it's not cleared, the "Repeat password" prompt returns 
with an empty password, which clearly does not match the first one...

Just remove the "\n" from the send and it should work reliably.

Hope this helps,

Roland
-- 
RGi...@cp...

RE: [Expectperl-discuss] Expect and passwd

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

> Sometimes it fails 1st then starts working and other times it works
> and them fails, if that makes any difference (or sense...)
...
> Sending '1derful\n\012' to spawn id(3)

OK, that was a subtle one: you are not chomping the entered password, 
so when you send it, it contains TWO \n.  passwd clears it's readline 
buffer before reading the password, but depending things beyond 
control, the second \n might or might not be in the buffer to be 
cleared.  If it's not cleared, the "Repeat password" prompt returns 
with an empty password, which clearly does not match the first one...

Just remove the "\n" from the send and it should work reliably.

Hope this helps,

Roland
-- 
RGi...@cp...

Re: [Expectperl-discuss] Expect and passwd

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

> Anyway, most of the time everything works well, however sometimes the
> script just hangs (Expect waiting for passwd, I suppose)
> with "Waiting for new data (unlimited seconds)..."
> I stop the process and retry several times (using the same input) and
> it will eventually work.

OK, please provide the relevant sections of your scripts and debug 
output with $Expect::Exp_Internal=1 and I'll take a look at it.  Your 
OS and Expect version would also be helpful.

Sorry, but today my mind is too numb to read yours... :-)

Roland
-- 
RGi...@cp...

[Expectperl-discuss] Expect and passwd

[Walls R. W C. 75 CS/S. <Rob...@HI...>]

I am using the Expect module to talk to passwd and smbpasswd. (hmm..., how
original, right? :)
This particular script is run as root. I give it the username on the command
line and use Term::ReadKey to get the current password and the new password.
I am doing something similar for users to run and catch different strings,
but both scripts have the same trouble.

An EOF usually means that the original password could not be verified.
Catching "BAD PASSWORD" allows me to grep the reason for the error with
OBJECT->after().

Anyway, most of the time everything works well, however sometimes the script
just hangs (Expect waiting for passwd, I suppose) with "Waiting for new data
(unlimited seconds)..."
I stop the process and retry several times (using the same input) and it
will eventually work.

For passwd, I am catching:

  #1: -re `BAD PASSWORD'
  #2: -re `Changing password for'
  #3: -re `Retype new password:'
  #4: -re `passwd: all authentication tokens updated successfully'
  #5: -eof `'

and for smbpasswd, I am catching:

  #1: -re `New SMB password:'
  #2: -re `Retype new SMB password:'
  #3: -re `Password changed for user'
  #4: -eof `'

Any ideas on where the intermittent hang might be coming from ?


Rob Walls
75 CS/SCBS
Hill AFB, Utah 84056
DSN 777-2230
COM (801) 777-2230
rob...@hi...

Re: [Expectperl-discuss] ExpectPerl and Screen

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

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

Re: [Expectperl-discuss] returning to previously spawned expect session

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

On Fri, Aug 30, 2002 at 04:43:14PM -0700, Heidi Ng wrote:
> 
> Hi,
> 
> I have written a script which spawns an expect session and returns to it after doing some other stuff.  However, when I go back to the first expect session, it seems like I cannot talk to it anymore.
> 
> I tried doing a "print $session "stop\r";".  But nothing happened and the test got stuck.  Do you know if there is a timeout to a spawned expect session and what I can do to get around this problem?
> 

	There is no timeout, though some applications can time out, e.g.
telnetting to a cisco router, or using cu to dial out disagreeable modems.
	What program are you spawning? Would it be a reasonable likelihood
that that program would time out of its own accord?

	Austin

[Expectperl-discuss] returning to previously spawned expect session

[Heidi Ng <ng_...@ya...>]

Hi,

I have written a script which spawns an expect session and returns to it after doing some other stuff.  However, when I go back to the first expect session, it seems like I cannot talk to it anymore.

I tried doing a "print $session "stop\r";".  But nothing happened and the test got stuck.  Do you know if there is a timeout to a spawned expect session and what I can do to get around this problem?

Thanks,
Heidi



---------------------------------
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes

Re: [Expectperl-discuss] ExpectPerl and Screen

[Simon T. <si...@un...>]

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

[Expectperl-discuss] ExpectPerl and Screen

[Kevin S. <ke...@ne...>]

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";

RE: [Expectperl-discuss] Problem running in bg

[Anders W. <And...@ac...>]

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

Re: [Expectperl-discuss] Problem running in bg

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

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

Re: [Expectperl-discuss] Problem running in bg

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

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

Re: [Expectperl-discuss] Problem running in bg

[<ex...@ih...>]

On Tue, 27 Aug 2002 15:47:59 -0400
Jason Penney <jas...@su...> wrote:

> 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";

You haven't said what you want to do and maybe
it doesn't matter.  But if you describe your goal there
might be a better path toward the goal.

Have you looked at "screen"? (ask google)

> 
> 
> % ./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
> 

RE: [Expectperl-discuss] Problem running in bg

[Anders W. <And...@ac...>]

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...