in reply to scp progress logging

I've become convinced that the nifty progress info doesn't get created when I invoke scp from a script, probably because scp has a call to isatty. Any quick and dirty way to tap into the progress info?

I've seen those types of programs when trying to make progressbars for various apps run from Tk. One of the things I've had success with, is running the program thru IPC::Open3, and watching the output on the filehandles. A sneaky trick is NOT to open the program itself with IPC::Open3, but open a "/bin/bash". Then print to the STDIN FH , your scp command (don't forget a newline :-) ). Then you should be able to read the STDOUT and STDERR that would be appearing in the bash shell. Regex that output for your progress data.

There are a few variations on this trick, like try a piped-open instead of IPC::Open3. Maybe

open(FH, "/bin/bash -c $scp_string 2>&1 |");
It should provide you with "hours of keybanging fun" while you find the right combination. :-)

I'm not really a human, but I play one on earth. flash japh

Replies are listed 'Best First'.
Re^2: scp progress logging
by egilchri (Novice) on Mar 16, 2006 at 15:44 UTC
    Neither of those two methods worked, so I started playing around with IO::Pty. I reason that this is all about tricking scp into thinking it's being invoked from a tty, and I gather that's what a pseudo tty is. The following script executes successfully, but I don't know how to get access to the progress info, if it is indeed going anywhere. Plus, I really don't need/want the thing to exec, since I'd rather that my program waited for the command to return, before proceeding.
    #!/usr/bin/perl use IO::Pty; my $cmd = "scp"; my @args = ("-v", "big.tar", "egilchri\@other_machine:"); &do_cmd ($cmd, @args); sub do_cmd { my ($cmd,@args) = @_; my $pty = IO::Pty->new or die "can't make Pty: $!"; defined (my $child = fork) or die "Can't fork: $!"; return $pty if $child; POSIX::setsid(); my $tty = $pty->slave; close $pty; STDIN->fdopen($tty,"<") or die "STDIN: $!"; STDOUT->fdopen($tty,">") or die "STDOUT: $!"; STDERR->fdopen(\*STDOUT,">") or die "STDERR: $!"; close $tty; $| = 1; exec $cmd,@args; die "Couldn't exec: $!"; }
      Yeah, it sounds like you are pretty close. Here is a snippet (from unknown origin) that may help get the output from the pty. Maybe you can figure out how to combine your scripts?
      #!/usr/bin/perl -w # Description: Fool a process into # thinking that STDOUT is a terminal, when in fact # it may be a file or a pipe. This can be useful # with programs like ps and w on linux... which # will trunc their output to the width of the # terminal, and, if they cannot detect the terminal # width, use a default 80 columns. Wouldn't it be # nice to say "ps -aux | grep etcshadow", and get # output that looks like when you just say "ps # -aux"? Well, that's the idea. use warnings; use strict; use IO::Pty; die "usage: ptyexec command [args]\n" unless @ARGV; my $pty = IO::Pty->new; my $slave = $pty->slave; open TTY,"/dev/tty" or die "not connected to a terminal\n"; $pty->clone_winsize_from(\*TTY); close TTY; my $pid = fork(); die "bad fork: $!\n" unless defined $pid; if (!$pid) { # $slave->close(); open STDOUT,">&=".$pty->fileno() or die $!; exec @ARGV; }else{ $pty->close(); while (defined (my $line = <$slave>)) { print $line; } } #cleanup pty for next run $pty->close();

      I'm not really a human, but I play one on earth. flash japh