use Perl

• Thoughts (Score:2)

  by jdavidb (1361)

  I think this behavior is similar to what you would have had under TCL/Expect. Not that that's a good reason. :)

  Can't you expect eof? Under TCL/Expect, if you wanted to run a command that produced no output, you would do an expect eof with a long (or -1) timeout to wait until it ended.

  Are you using the scp command-line program? If so, doesn't it produce a progress bar that would give you some output to expect()? At first I didn't understand why you were using Expect, but then I read the docs and I se

  --
  J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Re:Thoughts (Score:2)

    by djberg96 (2603)

    Can't you expect eof? Under TCL/Expect, if you wanted to run a command that produced no output, you would do an expect eof with a long (or -1) timeout to wait until it ended.

    Ooooh - good idea. I'll give it a shot.

    doesn't it produce a progress bar that would give you some output to expect()?

    Not in quiet mode. Normally you would get a '#' sign, but I wasn't sure how portable, or reliable, it was to check for '#'.

    Still don't understand why you have to do soft_close() and hard_close().

    I don't have t
    • Re:Thoughts (Score:1)

      by jdavidb (1361)

      Still don't understand why you have to do soft_close() and hard_close().

      I don't have to. The docs indicate that soft_close() was the polite way to close and hard_close() was the impolite way so my implementation was arbitrary based on that.

      No, I mean I don't understand why you call those routines at all. Usually you would only have to call them if you were ending the command early. Once you get to the point of eof either close is redundant, I think.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Re:Thoughts (Score:2)

    by djberg96 (2603)

    Didn't work. Strangely, it seems to be getting a blank char sequence followed by a "\r\n" sequence. Here's a snippet of the verbose output:

    Sending 'password\n' to spawn id(3)
            Expect::print('Expect=GLOB(0x2fc558)', 'password^J') called at ./scpTest3.pl line 21
    Starting EXPECT pattern matching...
            Expect::expect('Expect=GLOB(0x2fc558)', 1, 'eof') called at ./scpTest3.pl line 31
    spawn id(3): list of patterns:
      #1: -ex `eof'
    
    spawn id(3): Does ` '
    match:
    
    • Re:Thoughts (Score:2)

      by jdavidb (1361)

      Okay, this is goofy, but it appears you can't just

      $exp->expect($timeout, 'eof')

      Otherwise, it tries to match the literal string 'eof' (hence the -ex in your verbose output). You actually have to use the arrayref syntax to expect(). The arrayref syntax is

      $exp->expect($timeout, [pattern => code], [pattern => code], ...)

      So you can do

      $exp->expect($timeout, ['eof' => sub { exit }])

      I tried leaving out the => sub { exit } and it didn't seem to work, although I seem to have w

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Re:Thoughts (Score:2)

        by jdavidb (1361)

        Ah! Found out that I only need the => sub { } on special things like eof because they use special code that didn't take the possibility of not specifying a coderef into account.

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Re:Thoughts (Score:2)

        by djberg96 (2603)

        Yeah, that's better, but it's still getting "\r\n" and not eof anyway, so it's a moot point. Besides, I still have to deal with it via a timeout value (right?) so no matter what, your only option currently is to *guess* how much time you need to complete the operation.

        The fundamental flaw with Expect.pm (and perhaps expect in general?) is that it kills its own children before letting them finish. Perhaps there was a reason for this, or perhaps they never counted on anyone performing an op that didn't re
        • Re:Thoughts (Score:2)

          by jdavidb (1361)

          You can specify an unlimited timeout. It's hidden in the docs somewhere. Use undef instead of a value. In the original TCL/Expect, it was -1. (Had trouble finding it in the docs back then, too, as some of my old programs attest.)

          Here's my code to scp a file from my machine to its own /tmp directory:

          #!/usr/local/bin/perl5.6.1
          
          use warnings;
          use strict;
          
          our $password = "hello";
          
          use Expect;
          
          my $exp = Expect->spawn("scp file.xls minako:/tmp");
          $exp->expect(2, "Password: ");
          $exp->send("$pa

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
• Fix (Score:2)

  by jdavidb (1361)

  Boy, you go to great lengths to get someone to install your module. :)

  I installed Net::SCP::Expect and tinkered with it a bit. I was able to reliably duplicate the problem by attempting to scp the largest file on my machine to my /tmp directory. I made the following changes, and it seemed to fix the problem:

  --- Expect.pm.orig Mon Apr 29 15:14:48 2002
  +++ Expect.pm Wed Jun 5 12:28:00 2002
  @@ -37,7 +37,7 @@
  _auto_yes => $arg{auto_yes} || 0,
  _timeout => $arg{timeout} ||

  --
  J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Re:Fix (Score:2)

    by djberg96 (2603)

    Sweet, sweet, SWEET!!!! Works like a charm. Setting the timeout_err to undef isn't going to work because of the " || 1 " in the constructor. I changed it to " || undef ". Perhaps, I should allow a literal string 'undef' for that option, and then deal with it in the constructor as appropriate.

    Thank you very much. Should I be irritated that I ultimately received the answer from you and not Roland? Hmm...nevermind. I may end up in the same boat some day. That, or he thought I was an annoying nit and
    • Re:Fix (Score:2)

      by jdavidb (1361)

      Should I be irritated that I ultimately received the answer from you and not Roland?

      Speaking as an active member of the expectperl mailing list, Roland sees a lot of FAQs asked many, many times. We also have a lot of people who are trying to learn Expect.pm before they learn Perl! (It doesn't help that some have never seen TCL/Expect, either.) It seems like every week there's someone trying to automate ssh in a way that indicates they would do better to try a different method than Expect (such as sys

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
• Oh? (Score:1)

  by RGiersig (3217)

  Sorry that my answer was not helpful. I thought that I'd pointed you to the cause of your problem, but maybe we had a misunderstanding. Anyway, Expect.pm *does* wait until EOF if told so. But it only waits until the given timeout expires, which was your problem.
  • Re:Oh? (Score:2)

    by jdavidb (1361)

    Perhaps a couple of FAQ entries would be in order. I'll draft and send to the mailing list.

    • My spawned process doesn't produce any output, and Expect.pm doesn't wait for it to end.
    • There's no way to reliably decide how long to set my timeouts; can't I make it unlimited?

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Re:Oh? (Score:1)

      by RGiersig (3217)

      Sure, if we could only get people to read them... ;-)

      Thanks, I'll put them in and also take a look at the 'eof' issue.
• TMTOWTDI (Score:2)

  by jdavidb (1361)

  Austin Shutz (the original author of Expect.pm, I think) offers this other way to do it:

  $exp->expect(undef);

  This will basically just wait until the command is done; expect() will return when it gets the eof. If you really needed to explicitly see the eof at that point, you could check the error string:

  if ($exp->error() =~ /EOF/) { ... }

  --
  J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers