ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1 
Author Message
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Hello, all.  Recently, Tom made the deeply disturbing heretical statement:

  > You should probably just give up on perl for expect stuff.  
  >
  > Anyone caring to dispute this suggestion is welcome to provide an
  > expect-like module in perl5.  I mean a real one, fully portable,
  > delightfully elegant and easy to use.
  >
  > Failing that, use tcl -- and suffer.
  >
  > --tom
  > --

So, "caring to dispute this", since I just know Perl can be used simply and
easily to do expect-like stuff, with the much better Perl language support,
I'm providing the package I've been keeping up to date over the last
couple years, with modifications to address:

  "a real one"
  "fully portable"
  "delightfully elegant and easy to use"

The, "module in perl5", bit is open to discussion, as is all of it.  Comments
and suggestions are welcome.

-Eric

What:

  "Comm.pl", a successor to "chat2.pl", providing a high level interface to:

    - STREAM/UDP sockets
    - pseudo-tty control
    - Revamped "expect"-like functionality (plus "interact").
    - ioctl/stty terminal mode control

  other things:

    - Support for BSD & SVR4 flavors (so far, tested with SunOS4.x, Solaris2.x)
    - sample client/server and expect scripts

Why:

  - "chat2.pl" doesn't have SVR4 support.  People have been posted a
    lot with questions about getting SOCK_STREAM right, or how to get
    a pty.

  - The Expect pattern/action pair only confuses people the way that chat2
    emulated it.  A Perl "expect" should be simple; it should not be
    trying to execute code given as parameters; that's what the Perl
    interpreter is for.  Also, the TCL Expect program has a whole lot
    of stuff that we don't really need because it's available via other
    methods in Perl (i.e. "send_tty").

Issues:

  ----------------------------------------
  What should "expect" look like?
  ----------------------------------------

    - All a Perl expect function really needs to do is to look through
      input (non-blocking, without need for newlines) and return
      whether a pattern was found or not.

      I've changed the interface to:

        ( $match, $err, $before, $after ) =
                  &expect( $fh, $timeout, 'regexp1', 'regexp2' );

        die "expect failed, err($err), last seen($before)" if $err;

        $_ = $match ; SWITCH :
        {
          /regexp1/ && do { print $fh "something\n" ; next SWITCH };
          /regexp2/ && do { print $fh "other\n" ; next SWITCH };
          # default
        }
        # or if .. else; whatever you want.

      or for more simple situations:

        &expect( $fh, $timeout, 'regexp1' ) || die "regexp1 failed, err=$!";
        print $fh "something\n";
        &expect( $fh, $timeout, 'regexp2' ) || die "regexp2 failed, err=$!";
        print $fh "something else\n";

    - When something doesn't work right, people are often confused as to
      what is going wrong.  That's why I added the "$before" and
      "$after" variables, so people can [be encouraged to] see what's
      being read or discarded, and why their pattern isn't matching.

    - The "interact()" interface is:

        ( $match, $err ) = &interact( "optional string patterns for STDIN",...,
                        $Proc_pty_handle, "optional regex patterns", ... );

      I don't know how offensive it is to have $Proc_pty_handle be the
      delimeter between the string patterns and the regex patterns.  I
      wanted to provide triggers for both the user (STDIN) and the process
      ($Proc_pty_handle), and that seemed expedient.

    - Nit:  I wanted to be able to set $! from within "expect()" so
      that when the user used the short (!wantarray) form, I could
      still give error feedback.  I found that $! can only be set to
      valid values for "errno".  Then I found that I couldn't set and
      make it stick until the results had been evaluated by the
      caller.  Rats.

  ----------------------------------------
  Should it be a Perl5 module?  
  Does it need to be object oriented?  
  Abandon Perl4 support?
  ----------------------------------------

    I can't decide whether to abandon Perl4, yet.  Nothing about
    Comm.pl, as it is, really screams for Perl5 functionality, though
    it would be convenient to use "Exporter.pm", "Socket.pm", and array
    refs for "interact()".  I have a real bias toward Perl5, but I don't
    know whether the world shares it.  Speak up if you're using Perl4,
    and you can't upgrade for some reason.

  ----------------------------------------
  Portability?
  ----------------------------------------

    Pseudo-tty portability is a problem:  one version uses [some] BSD
    backward compatibility in Solaris, and the other version uses some
    scarey bit hacking, which might not be any more portable:

      # ptsname - not portable probably: assumes 14 bit minor numbers.
      # only a problem if it's less than 14bits, I think.
      print "rdev=$rdev\n";
      $rdev &= (1<<14) - 1;
      $slave = "/dev/pts/$rdev";

    The main problem being that Perl has no interface to ptm functions
    like "grantpt" and "ptsname".  Making a C linkable module seems
    like overkill.  Is there a POSIX standard for this, which could place
    it in the POSIX module?

    Perl5 does have a good socket module, which should be used, I guess,
    but it doesn't have Streams stuff like "I_PUSH", etc.  So, system
    dependencies will still have to live in the Comm.pl package.  

    This then gets back to the question of whether to write it as Perl5-only,
    or retain the current Perl4/Perl5 compatibility.

------------------------------------cut here------------------------------------

$HEADER = <<'EOF';

                        "Comm.pl"

This is a free library of IPC goodies.  There is no warrenty, but I'd
be happy to get ideas for improvements.


It's been tested with Perl4/Perl5 and SunOS4.x and Solaris2.3 - 2.5.
It's normally put into a file and "require"'d, but can also be simply
concatinated to the end of some other perl script.  If you do that, use:
        require "Comm.pl" unless defined &Comm'init;

A lot was borrowed from "chat2.pl"(Randal L. Schwartz), and then
diverged as its goals became generalized client/server IPC, support for
SVR4/Solaris, and to facilitate my "shelltalk" program.  Since then, I/we've
been using it for all sorts of stuff.

See the end of this file for example programs demonstrating usage.

Function summary:

  (Remember to use prefixes (i.e. "&Comm'init") for anything not exported.)
  (All file handles passed up from these functions are exported into the
  caller's package.)

  &Comm'init();             # Under normal circumstances, "require" will call init
                        # for you.

  &Comm'init(1.2);  # If first arg is numberic, it specifies a desired
                        # version for compatibility

  &Comm'init("funcname",...);     # Tell it to export specified function(s)

    # By default, init() will export these functions:
      open_port, open_listen, open_udp_port, open_proc ,
      send_to, recv_from, accept_it, select_it ,
      expect , interact ,
      close_noshutdown, close_it, stty_sane, stty_raw, stty_ioctl

    # If you don't want this to happen, you'll have to comment out the call
    # to "&init;" in this package.  Sorry.

  open_port :
  ---------

    # Open a STREAM socket connection to a host:
    $handle = &open_port($host, $port, $timeout);

  open_listen :
  -----------

    # Open a STREAM listen socket on your host:

    $handle = &open_listen( $port );

    # Or you can specify the $host if you need to listen on an address
    # other than:  `uname -n` (E.g. if you have a second ethernet)

    $handle = &open_listen( $host, $port );

  select_it :
  ---------

    # Give it a timeout and a list of handles, and it tells you which ones
    # have data ready (or some condition, like EOF).  It's called "select_it"
    # so it won't clash with "select".


  accept_it :
  ---------

    # Complement to "open_listen":

    ( $new_handle, $rem_host ) = &accept_it( $handle );

  open_proc :
  ---------

    # Set up a pseudo-tty, and start "$Command" running in it.

    ( $Proc_pty_handle, $Proc_tty_handle, $Proc_pid ) =
        &open_proc($Command);

  wait_nohang :
  -----------

    # Does a portable wait4/waitpid.  Used mostly internally.  Not exported.
    &Comm'wait_nohang;

  expect :
  ------

    # This function scans an input stream for a pattern, without blocking,
    # a la "sysread()".
    #
    # Patterns are scanned in the order given, so later patterns can contain
    # general defaults that won't be examined unless the earlier patterns
    # have failed.  Be careful of timing problems, however.  If you specify
    # a very general pattern later in the list, it might match undesireably
    # if a partial packet of data is received.  

    # $err can contain "TIMEOUT" or "EOF".  $before will contain anything
    # before $match, or everything seen if $err is set.  $after contains
    # everything discarded after $match.

    ( $match, $err, $before, $after ) =
                &expect( $fh, $timeout, 'regexp1', 'regexp2' );
    # or
    $match = &expect( $fh, $timeout, 'regexp1', 'regexp2', ... );

    # You can give it any file handle, but remember to pass the type glob,
    # so it can be used in a different package namespace:

    open(RDR, "somecommand|");
    # or
    &open3(WRT, RDR, ERR, 'somecommand' );
    ( $match, $err, $before, $after ) = expect( *RDR, 1, $pattern );

  interact :
  --------

    # This connects a process opened with "open_proc()" to the user via
    # STDIN, and allows them to "interact".
    #
    # You specify patterns to trigger return of control to your script, which
    # can be matched either in STDIN or the process file handle.  The
    # $Proc_pty_handle serves as a delimeter between string patterns for STDIN,
    # and regex patterns for $Proc_pty_handle.
    #
    # Any pattern matched
...

read more »



Wed, 25 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Hello, all.  Recently, Tom made the deeply disturbing heretical statement:

  > You should probably just give up on perl for expect stuff.  
  >
  > Anyone caring to dispute this suggestion is welcome to provide an
  > expect-like module in perl5.  I mean a real one, fully portable,
  > delightfully elegant and easy to use.
  >
  > Failing that, use tcl -- and suffer.
  >
  > --tom
  > --

So, "caring to dispute this", since I just know Perl can be used simply and
easily to do expect-like stuff, with the much better Perl language support,
I'm providing the package I've been keeping up to date over the last
couple years, with modifications to address:

  "a real one"
  "fully portable"
  "delightfully elegant and easy to use"

The, "module in perl5", bit is open to discussion, as is all of it.  Comments
and suggestions are welcome.

-Eric

What:

  "Comm.pl", a successor to "chat2.pl", providing a high level interface to:

    - STREAM/UDP sockets
    - pseudo-tty control
    - Revamped "expect"-like functionality (plus "interact").
    - ioctl/stty terminal mode control

  other things:

    - Support for BSD & SVR4 flavors (so far, tested with SunOS4.x, Solaris2.x)
    - sample client/server and expect scripts

Why:

  - "chat2.pl" doesn't have SVR4 support.  People have been posted a
    lot with questions about getting SOCK_STREAM right, or how to get
    a pty.

  - The Expect pattern/action pair only confuses people the way that chat2
    emulated it.  A Perl "expect" should be simple; it should not be
    trying to execute code given as parameters; that's what the Perl
    interpreter is for.  Also, the TCL Expect program has a whole lot
    of stuff that we don't really need because it's available via other
    methods in Perl (i.e. "send_tty").

Issues:

  ----------------------------------------
  What should "expect" look like?
  ----------------------------------------

    - All a Perl expect function really needs to do is to look through
      input (non-blocking, without need for newlines) and return
      whether a pattern was found or not.

      I've changed the interface to:

        ( $match, $err, $before, $after ) =
                  &expect( $fh, $timeout, 'regexp1', 'regexp2' );

        die "expect failed, err($err), last seen($before)" if $err;

        $_ = $match ; SWITCH :
        {
          /regexp1/ && do { print $fh "something\n" ; next SWITCH };
          /regexp2/ && do { print $fh "other\n" ; next SWITCH };
          # default
        }
        # or if .. else; whatever you want.

      or for more simple situations:

        &expect( $fh, $timeout, 'regexp1' ) || die "regexp1 failed, err=$!";
        print $fh "something\n";
        &expect( $fh, $timeout, 'regexp2' ) || die "regexp2 failed, err=$!";
        print $fh "something else\n";

    - When something doesn't work right, people are often confused as to
      what is going wrong.  That's why I added the "$before" and
      "$after" variables, so people can [be encouraged to] see what's
      being read or discarded, and why their pattern isn't matching.

    - The "interact()" interface is:

        ( $match, $err ) = &interact( "optional string patterns for STDIN",...,
                        $Proc_pty_handle, "optional regex patterns", ... );

      I don't know how offensive it is to have $Proc_pty_handle be the
      delimeter between the string patterns and the regex patterns.  I
      wanted to provide triggers for both the user (STDIN) and the process
      ($Proc_pty_handle), and that seemed expedient.

    - Nit:  I wanted to be able to set $! from within "expect()" so
      that when the user used the short (!wantarray) form, I could
      still give error feedback.  I found that $! can only be set to
      valid values for "errno".  Then I found that I couldn't set and
      make it stick until the results had been evaluated by the
      caller.  Rats.

  ----------------------------------------
  Should it be a Perl5 module?  
  Does it need to be object oriented?  
  Abandon Perl4 support?
  ----------------------------------------

    I can't decide whether to abandon Perl4, yet.  Nothing about
    Comm.pl, as it is, really screams for Perl5 functionality, though
    it would be convenient to use "Exporter.pm", "Socket.pm", and array
    refs for "interact()".  I have a real bias toward Perl5, but I don't
    know whether the world shares it.  Speak up if you're using Perl4,
    and you can't upgrade for some reason.

  ----------------------------------------
  Portability?
  ----------------------------------------

    Pseudo-tty portability is a problem:  one version uses [some] BSD
    backward compatibility in Solaris, and the other version uses some
    scarey bit hacking, which might not be any more portable:

      # ptsname - not portable probably: assumes 14 bit minor numbers.
      # only a problem if it's less than 14bits, I think.
      print "rdev=$rdev\n";
      $rdev &= (1<<14) - 1;
      $slave = "/dev/pts/$rdev";

    The main problem being that Perl has no interface to ptm functions
    like "grantpt" and "ptsname".  Making a C linkable module seems
    like overkill.  Is there a POSIX standard for this, which could place
    it in the POSIX module?

    Perl5 does have a good socket module, which should be used, I guess,
    but it doesn't have Streams stuff like "I_PUSH", etc.  So, system
    dependencies will still have to live in the Comm.pl package.  

    This then gets back to the question of whether to write it as Perl5-only,
    or retain the current Perl4/Perl5 compatibility.

------------------------------------cut here------------------------------------

$HEADER = <<'EOF';

                        "Comm.pl"

This is a free library of IPC goodies.  There is no warrenty, but I'd
be happy to get ideas for improvements.


It's been tested with Perl4/Perl5 and SunOS4.x and Solaris2.3 - 2.5.
It's normally put into a file and "require"'d, but can also be simply
concatinated to the end of some other perl script.  If you do that, use:
        require "Comm.pl" unless defined &Comm'init;

A lot was borrowed from "chat2.pl"(Randal L. Schwartz), and then
diverged as its goals became generalized client/server IPC, support for
SVR4/Solaris, and to facilitate my "shelltalk" program.  Since then, I/we've
been using it for all sorts of stuff.

See the end of this file for example programs demonstrating usage.

Function summary:

  (Remember to use prefixes (i.e. "&Comm'init") for anything not exported.)
  (All file handles passed up from these functions are exported into the
  caller's package.)

  &Comm'init();             # Under normal circumstances, "require" will call init
                        # for you.

  &Comm'init(1.2);  # If first arg is numberic, it specifies a desired
                        # version for compatibility

  &Comm'init("funcname",...);     # Tell it to export specified function(s)

    # By default, init() will export these functions:
      open_port, open_listen, open_udp_port, open_proc ,
      send_to, recv_from, accept_it, select_it ,
      expect , interact ,
      close_noshutdown, close_it, stty_sane, stty_raw, stty_ioctl

    # If you don't want this to happen, you'll have to comment out the call
    # to "&init;" in this package.  Sorry.

  open_port :
  ---------

    # Open a STREAM socket connection to a host:
    $handle = &open_port($host, $port, $timeout);

  open_listen :
  -----------

    # Open a STREAM listen socket on your host:

    $handle = &open_listen( $port );

    # Or you can specify the $host if you need to listen on an address
    # other than:  `uname -n` (E.g. if you have a second ethernet)

    $handle = &open_listen( $host, $port );

  select_it :
  ---------

    # Give it a timeout and a list of handles, and it tells you which ones
    # have data ready (or some condition, like EOF).  It's called "select_it"
    # so it won't clash with "select".


  accept_it :
  ---------

    # Complement to "open_listen":

    ( $new_handle, $rem_host ) = &accept_it( $handle );

  open_proc :
  ---------

    # Set up a pseudo-tty, and start "$Command" running in it.

    ( $Proc_pty_handle, $Proc_tty_handle, $Proc_pid ) =
        &open_proc($Command);

  wait_nohang :
  -----------

    # Does a portable wait4/waitpid.  Used mostly internally.  Not exported.
    &Comm'wait_nohang;

  expect :
  ------

    # This function scans an input stream for a pattern, without blocking,
    # a la "sysread()".
    #
    # Patterns are scanned in the order given, so later patterns can contain
    # general defaults that won't be examined unless the earlier patterns
    # have failed.  Be careful of timing problems, however.  If you specify
    # a very general pattern later in the list, it might match undesireably
    # if a partial packet of data is received.  

    # $err can contain "TIMEOUT" or "EOF".  $before will contain anything
    # before $match, or everything seen if $err is set.  $after contains
    # everything discarded after $match.

    ( $match, $err, $before, $after ) =
                &expect( $fh, $timeout, 'regexp1', 'regexp2' );
    # or
    $match = &expect( $fh, $timeout, 'regexp1', 'regexp2', ... );

    # You can give it any file handle, but remember to pass the type glob,
    # so it can be used in a different package namespace:

    open(RDR, "somecommand|");
    # or
    &open3(WRT, RDR, ERR, 'somecommand' );
    ( $match, $err, $before, $after ) = expect( *RDR, 1, $pattern );

  interact :
  --------

    # This connects a process opened with "open_proc()" to the user via
    # STDIN, and allows them to "interact".
    #
    # You specify patterns to trigger return of control to your script, which
    # can be matched either in STDIN or the process file handle.  The
    # $Proc_pty_handle serves as a delimeter between string patterns for STDIN,
    # and regex patterns for $Proc_pty_handle.
    #
    # Any pattern matched
...

read more »



Thu, 26 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1
   Tom Christiansen was quoted as saying:

Quote:
>  > You should probably just give up on perl for expect stuff.  

   Eric Arnold then states his case that it _can_ be done in Perl, and
he backs it up with code!  Later Eric makes the statement

Quote:
>    The main problem being that Perl has no interface to ptm functions
>    like "grantpt" and "ptsname".  Making a C linkable module seems
>    like overkill.  Is there a POSIX standard for this, which could place
>    it in the POSIX module?
>    Perl5 does have a good socket module, which should be used, I guess,
>    but it doesn't have Streams stuff like "I_PUSH", etc.  So, system
>    dependencies will still have to live in the Comm.pl package.  

   Both of these are very good points.  A few weeks back I was looking
for code which would allow a perl script to talk to the passwd program.
That's all I wanted it to do.  chat2.pl wasn't up to the task on
Solaris, and I couldn't find any other scripts.  So, I set out to write
my own.  I ran into several problems along the way, but with help from
perl people like you I was able to solve them.
   The result of my efforts is Term::Pty 0.1, a set of routines that are
as faithful as possible to the man pages for ptm and pts for creating a
pseudoterminal under Solaris 2.4.  It includes a dynamic module for
loading the grantpt, ptsname and unlockpt functions and making them
available to a perl script.
   Term::Pty is not a Swiss army knife.  It does only one thing and it
does it well for what I want it to do.  Your mileage may vary.  You are
welcome to use and modify to your heart's content.  I only ask that if
you use this code, please post useful products for other people to use.
There are no guarantees with this code, and any resemblance of this code
to actual working code is probably a coincidence.  It is not an example
of good Perl programming, etc.
   I would like to thank Tom Christiansen for chat2.pl which served as a
model for Term::Pty.  I'm sorry, Tom.  This code is not portable and
only works under Solaris 2.4, that I know of.  I would like to thank
Casper Dik who tracked down a rather {*filter*} bug where perl sets files
to be closed on fork causing grantpt to barf.  I'd like to thank Eric
Arnold for the copy of his pre-beta code which provided some examples.
It was a comment in his code that helped me solve the last problem.  I'd
like to thank Rajappa Iyer for his suggestions and sample code.
   I do not plan on developing Term::Pty any more.  It works, and I have
too many other things to do.  If you do not have experience with dynamic
modules in perl, you should take a look at using Eric Arnold's code
recently posted to this group, because I do not have the time to walk
you through the whole process.
   I have included all of the necessary files below.  I didn't wrap them
with anything so that everything would be readable.  Besides, they are
not too long.  You'll need to edit this file by hand and split it into the
individual files.  The general steps you'll want to take are

   1.   Go to the top level of the perl source code directory and
        create a ../ext/Term/Pty directory.
   2.   Move this file into that directory and split it into the files
        MANIFEST, Makefile.PL, Pty.pm and Pty.xs
   3.   perl Makefile.PL
   4.   make dynamic
   5.   make install

   The last two steps will be tedious.  I decided Pty should go under
Term, but there are no Term subdirectories in the appropriate places.  So,
you'll have to watch the error messages and create the appropriate Term
directories in the source directories and in the perl library
directories.  Then make it again.  Eventually you'll have made all of
the directories and all of the code will be moved to the right places.
   An alternative would be to change step 1 to create a ../ext/Pty
directory and then change all references to Term::Pty in the code to
Pty.  That should avoid the directory problems.  However, that doesn't
seem to fit as nicely in terms of function.
   Because I wanted I_PUSH to be a constant/function, I included stropts.h.

include and constant code from Pty.xs and define the constant directly in
Pty.pm.  However, an advantage is that all of those constants are
available for ioctls if a person wants them.  I also don't like
hardcoding things like that.
   Here is an example of how I use the code.

use Term::Pty;               # Used to talk to passwd
:
sub Change_Passwd
#
# Description:  Change the password for a user by talking to the
# password program through a pseudoterminal.  Start passwd with
# the name of the user, enter the new password twice and we're
# done.
#
{

   local $timeout = 5;   # Seconds to wait before timeout
   my $return;

   &Pty_Open(*PTY, "/usr/bin/passwd $uname");
   $return = &Pty_Expect(*PTY, $timeout, "New password:", "new");
   die "Password change failed" if $return ne "new";
   &Pty_Print(*PTY, "$pass\n");
   $return = &Pty_Expect(*PTY, $timeout, "password:", "verify");
   die "Password verification failed" if $return ne "verify";
   &Pty_Print(*PTY, "$pass\n");   # Slurp remaining output
   while (defined(&Pty_Expect(*PTY, $timeout, ".*", "extras"))) {}
   &Pty_Close(*PTY);

Quote:
}

   This next section contains the 4 files to be placed in the Pty
directory.

MANIFEST-------------------------------------------------

MANIFEST
Makefile.PL
Pty.pm
Pty.xs

Makefile.PL----------------------------------------------

use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
    'NAME'      => 'Term::Pty',
    'VERSION'   => '0.1',
    'LIBS'      => [''],   # e.g., '-lm'
    'DEFINE'    => '',     # e.g., '-DHAVE_SOMETHING'
    'INC'       => '',     # e.g., '-I/usr/include/other'
);

Pty.pm----------------------------------------------------

package Term::Pty;

# Site:     Concordia College, Seward, NE
# Date:     29-Sep-1995
# Author:   Russell Mosemann
#
# Description:  This package provides basic pseudoterminal
# functionality on Solaris 2.4 using perl5.  The calling program is
# able to open a master device and exec a command, wait for output
# using an expect-like call, print information to the pseudoterminal,
# and close the pseudoterminal.
#
# Usage:
#

#   *MASTER_HANDLE   The handle to be used for the master device.

# &Pty_Open(*PTY, "ls -l");
#

#   *MASTER_HANDLE   The handle of the master device.
#   $wait_secs       Number of seconds before a timeout if no
#                    patterns are matched in the input

#                    to the input from the master device.
#                    The pattern can be any legal perl pattern, and
#                    the action can be a bareword or command that
#                    can be evaluated; the result of the evaluation
#                    is returned.
#                    There are two predefined bareword patterns.  The
#                    default action is to return undef.
#                       "TIMEOUT"   return result of action on timeout
#                       "EOF"       return result of action on eof
# $result = &Pty_Expect(*PTY, 10, "*.bak", "\$'",
#                                 "TIMEOUT", "TIMEOUT",
#                                 "EOF", "EOF");
#
# &Pty_Print(*MASTER_HANDLE, $cmd);
#   *MASTER_HANDLE   The handle of the master device.
#   $cmd               Command to print to the pseudoterminal.
# &Pty_Print(*PTY, "This is a test.\n");
#
# &Pty_Close(*MASTER_HANDLE);
#   *MASTER_HANDLE   The handle of the master device.
# &Pty_Close(*PTY);
#

require Exporter;
require DynaLoader;
require AutoLoader;

use POSIX;
use Carp;
use strict qw(refs subs);

        ANYMARK
        FLUSHBAND
        FLUSHR
        FLUSHRW
        FLUSHW
        INFTIM
        I_ATMARK
        I_CANPUT
        I_CKBAND
        I_E_RECVFD
        I_FDINSERT
        I_FIND
        I_FLUSH
        I_FLUSHBAND
        I_GETBAND
        I_GETCLTIME
        I_GETEV
        I_GETSIG
        I_GRDOPT
        I_GWROPT
        I_LINK
        I_LIST
        I_LOOK
        I_NREAD
        I_PEEK
        I_PLINK
        I_POP
        I_PUNLINK
        I_PUSH
        I_RECVFD
        I_SENDFD
        I_SETCLTIME
        I_SETEV
        I_SETSIG
        I_SRDOPT
        I_STR
        I_STREV
        I_SWROPT
        I_UNLINK
        I_UNSTREV
        LASTMARK
        MORECTL
        MOREDATA
        MSG_ANY
        MSG_BAND
        MSG_HIPRI
        MUXID_ALL
        RMODEMASK
        RMSGD
        RMSGN
        RNORM
        RPROTDAT
        RPROTDIS
        RPROTMASK
        RPROTNORM
        RS_HIPRI
        SNDPIPE
        SNDZERO
        STR
        STRUIO_POSTPONE
        S_BANDURG
        S_ERROR
        S_HANGUP
        S_HIPRI
        S_INPUT
        S_MSG
        S_OUTPUT
        S_RDBAND
        S_RDNORM
        S_WRBAND
        S_WRNORM
        _I_BIND_RSVD
        _I_RELE_RSVD
);
sub AUTOLOAD {
    # This AUTOLOAD is used to 'autoload' constants from the constant()
    # XS function.  If a constant is not found then control is passed
    # to the AUTOLOAD in AutoLoader.

    local($constname);
    ($constname = $AUTOLOAD) =~ s/.*:://;

    if ($! != 0) {
        if ($! =~ /Invalid/) {
            $AutoLoader::AUTOLOAD = $AUTOLOAD;
            goto &AutoLoader::AUTOLOAD;
        }
        else {
            ($pack,$file,$line) = caller;
            die "Your vendor has not defined Term::Pty macro $constname, used at $file line $line.
";
        }
    }
    eval "sub $AUTOLOAD { $val }";
    goto &$AUTOLOAD;

Quote:
}

sub Pty_Open
{
# Description:  Open the master pseudoterminal device.  Set the file
# descriptor not to close on exec, because the grantpt() call forks
# and execs a privileged program to prepare the slave based on the
# file descriptor of the master.  Then unlock the slave, get its
# name and fork.  If we are the parent, save the pid of the child
# and erase the buffer.
#   If we are the child, close the stdin, stdout, and stderr.  Set
# our session ID because we are on our own, now.  Then open the
# ...

read more »



Thu, 26 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

I don't think that linking the TCL/Expect to Perl is useful.  When I
looked at the Expect man page, most of the Expect package deals with
providing stuff that is already accessible via Perl's nice integration
with Unix.  I.e. it has "sleep", logging features, special functions to
send to STDERR or /dev/tty or STDOUT, all of which are redundant with
respect to Perl, and therefore violate the "keep it simple" rule.

I really only identified two things that are crucial:

        expect()
        interact()

However, "send -h" is something not built into Perl.  It emulates a user's
slow and erratic typing.  It seems a little gimicky.  I think I can add
it easily enough if people really need it.

Also, I didn't really understand the need for "expect_before" and
"expect_after".  This seems like another case where I'd rather leave to
the user:


-Eric



Quote:


>>Hello, all.  Recently, Tom made the deeply disturbing heretical statement:

>>  > You should probably just give up on perl for expect stuff.  

>>So, "caring to dispute this", since I just know Perl can be used simply and
>>easily to do expect-like stuff, with the much better Perl language support,
>>I'm providing the package I've been keeping up to date over the last
>>couple years, with modifications to address:

>It looks like the need for getting a perl-based expect is hitting critical
>mass.  I asked about this earlier, and even found one of the perl
>porters who was planning on glueing libexpect.a to perl 5.  Turns out
>some of the fancier features like send -h will take some extra work to
>port.

>I'd really like to see a perl module that provides the many features
>of expect.  And we eventually should settle on one solution as a
>standard.  Should we start from a new code base like you've done, or
>try to borrow the expect code itself as I mentioned above?  Don Libes
>(the author of expect) seems to be interested in the idea of using
>expect from perl, though I imagine tcl will continue to be his favorite.
>He might could provide some insight on sharing the code.
>--
>Danny Faught -- Convex -- Operating System Demolitions Specialist
>"Everything is deeply intertwingled."  (Ted Nelson, _Computer Lib_)



Fri, 27 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Quote:

>Hello, all.  Recently, Tom made the deeply disturbing heretical statement:

>  > You should probably just give up on perl for expect stuff.  

>So, "caring to dispute this", since I just know Perl can be used simply and
>easily to do expect-like stuff, with the much better Perl language support,
>I'm providing the package I've been keeping up to date over the last
>couple years, with modifications to address:

It looks like the need for getting a perl-based expect is hitting critical
mass.  I asked about this earlier, and even found one of the perl
porters who was planning on glueing libexpect.a to perl 5.  Turns out
some of the fancier features like send -h will take some extra work to
port.

I'd really like to see a perl module that provides the many features
of expect.  And we eventually should settle on one solution as a
standard.  Should we start from a new code base like you've done, or
try to borrow the expect code itself as I mentioned above?  Don Libes
(the author of expect) seems to be interested in the idea of using
expect from perl, though I imagine tcl will continue to be his favorite.
He might could provide some insight on sharing the code.
--
Danny Faught -- Convex -- Operating System Demolitions Specialist
"Everything is deeply intertwingled."  (Ted Nelson, _Computer Lib_)



Fri, 27 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Quote:

>    Tom Christiansen was quoted as saying:
> >  > You should probably just give up on perl for expect stuff.  

>    Eric Arnold then states his case that it _can_ be done in Perl, and
> he backs it up with code!  Later Eric makes the statement

> >    The main problem being that Perl has no interface to ptm functions
> >    like "grantpt" and "ptsname".  Making a C linkable module seems
> >    like overkill.  Is there a POSIX standard for this, which could place
> >    it in the POSIX module?

> >    Perl5 does have a good socket module, which should be used, I guess,
> >    but it doesn't have Streams stuff like "I_PUSH", etc.  So, system
> >    dependencies will still have to live in the Comm.pl package.  

>    Both of these are very good points.  A few weeks back I was looking
> for code which would allow a perl script to talk to the passwd program.
> That's all I wanted it to do.  chat2.pl wasn't up to the task on
> Solaris, and I couldn't find any other scripts.  So, I set out to write
> my own.  I ran into several problems along the way, but with help from
> perl people like you I was able to solve them.
>    The result of my efforts is Term::Pty 0.1, a set of routines that are
> as faithful as possible to the man pages for ptm and pts for creating a
> pseudoterminal under Solaris 2.4.  It includes a dynamic module for
> loading the grantpt, ptsname and unlockpt functions and making them
> available to a perl script.

Sigh. I don't suppose many people know the one about London Buses but
roughly paraphrased it goes something like "You wait for ages for a
Pty module to come along and then two turn up at once!"

I recently added this to the Module List (to be posted on the 10th):

5) Networking, Device Control (modems) and InterProcess Communication

Name           DSLI  Description                                  Info
-----------    ----  -------------------------------------------- -----
Ptty           adcf  Pseudo terminal interface functions          NI-S  +


(I've CC'd this to Nick).

It's a pity that you didn't announce the fact that you were working
on this either here or on perl5-porters so we could have avoided the
duplication of effort. Sigh.

Quote:
>    Term::Pty is not a Swiss army knife.  It does only one thing and it
> does it well for what I want it to do.

It looks quite comprehensive.

Quote:
> This code is not portable and only works under Solaris 2.4, that I know of.

I _think_ Nick's module has been tested on a copule of other platforms.

Quote:
>    I do not plan on developing Term::Pty any more.  It works, and I have
> too many other things to do.

Okay. Can we agree then that Nick will 'own' the Pseudo Terminal
Interface pumpkin and consolidate your code into his if/where applicable?

Let's, at the very least, agree an interface to pty management.

Quote:
> Russell Mosemann     Concordia College      Voice: (402) 643-7445
> Computing Center     Seward, NE 68434       Fax:   (402) 643-4073

Tim.


Fri, 27 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1
I'm attempting to get the comm2 package working uder IRIX 5.3, and it
uses the /usr/lib/pt_chmod program to fiddle with a pty, but that
program doesn't exist under IRIX, and I can't find a man page for
it under Sol5.4...  can anyone shed some light on this?

If it works, comm2 could be the greatest thing since sliced bread,
except for maybe ptk :-0

thanks,

-nate

--

 System Administrator            http://www.vis.colostate.edu/info/staff/nate
 CSU Computer Visualization Lab  "The torch of chaos and doubt --
 (970) 491-1578                   this is what the sage steers by." -Chuang Tzu



Mon, 30 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Quote:

>I'm attempting to get the comm2 package working uder IRIX 5.3, and it
>uses the /usr/lib/pt_chmod program to fiddle with a pty, but that
>program doesn't exist under IRIX, and I can't find a man page for
>it under Sol5.4...  can anyone shed some light on this?

pt_chmod is used to safely change the owner/rights of a pty.
It gets called by shelltool and xterm, for instance. You can see
what it does by trussing either as superuser (provided you can
do that ;-)

For you convenience, here is some of the output from truss (I've
deleted dynamic linking stuff, etc.):

23823:  execve("/usr/lib/pt_chmod", 0x08046CF4, 0x080478D8)  argc = 2
23823:  sysconfig(_CONFIG_PAGESIZE)                     = 4096
...
23823:  open("/etc/group", O_RDONLY)                  = 3
23823:  fxstat(2, 3, 0x080476C8)                        = 0
23823:  brk(0x0804F920)                                 = 0
23823:  ioctl(3, TCGETA, 0x0804769C)                    Err#25 ENOTTY
23823:  read(3, " r o o t : : 0 : r o o t".., 8192)   = 354
23823:  lseek(3, 0xFFFFFF38, SEEK_CUR)                  = 154
23823:  close(3)                                        = 0
23823:  getuid()                                        = 0 [0]
23823:  ioctl(5, I_STR, 0x08047874)                     = 0
23823:  fxstat(2, 5, 0x080477EC)                        = 0
23823:  access("/dev/pts/5", 0)                               = 0
23823:  chown("/dev/pts/5", 0, 7)                     = 0
23823:  ioctl(5, I_STR, 0x08047878)                     = 0
23823:  fxstat(2, 5, 0x080477F0)                        = 0
23823:  access("/dev/pts/5", 0)                               = 0
23823:  chmod("/dev/pts/5", 0620)                     = 0
23823:  lseek(0, 0, SEEK_CUR)                           = 5932
23823:  lseek(0, 0, SEEK_CUR)                           = 5932
23823:  _exit(0)

pt_chmod is called with the pty number, "5" in this case.
--


| 300,000 km per second.                             | s-/+ n+ h f* g+ w+ t+  |
| It's not the law, it's a challenge!                | r+ !y                  |



Mon, 30 Mar 1998 03:00:00 GMT  
 ANNOUNCE: Comm.pl, a new expect/chat2.pl pkg, Beta1

Quote:

>Okay. Can we agree then that Nick will 'own' the Pseudo Terminal
>Interface pumpkin and consolidate your code into his if/where applicable?

   Be my guest.  I would be flattered.  Keep us posted on the
development.

Russell Mosemann     Concordia College      Voice: (402) 643-7445
Computing Center     Seward, NE 68434       Fax:   (402) 643-4073



Wed, 01 Apr 1998 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. ANNOUNCE:chat3-a1.pl is chat2.pl + logging facilities

2. Need info on expect() of Comm.pl...

3. Using Perl's Expect like from Comm.pl

4. expect:autoexpect::Comm.pl:??

5. Comm.pl to simlate expect does not work on hp

6. Comm.pl to simlate expect does not work on hp

7. Comm.pl for expect with pgp

8. chat2.pl and expect's interact

9. Expect Processing / Chat2.pl help?

10. Chat2.pl, ftp.pl, etc

11. chat2.pl, hget.pl and socket.ph problems

12. socket.ph, ftp.pl and chat2.pl error found for Solaris and Irix

 

 
Powered by phpBB® Forum Software