On Feb 5, 2008 10:22 AM, <[EMAIL PROTECTED]> wrote:
> I am using perl alarm within a script and having an issue. I want to
> access a host by first trying rsh and if that fails use ssh. I can
> get the command to run with only one of the commands but when I add
> both it fails. I must be missing something simple
>
>
> Here is the info:
> Part of script
> .... else { $cmd="perl -e 'alarm(5);exec
> qq/${rdist} -cR \$srcdir $ENV{host}:\$destdir ||${scp} -pr \$srcdir
> $ENV{host}:\$destdir/'"; }
>
> Error I get
> Bareword found where operator expected at -e line 1, near "qq//usr"
> syntax error at -e line 1, near "qq//usr"
> Bareword found where operator expected at -e line 1, near "/bin/scp"
> (Missing operator before p?)
> Execution of -e aborted due to compilation errors.
>
> I have already set the rdist variable and have even tried to specify
> the rdist path.
>
What is this script part of? Are you spawning one perl process from
within another? If so, why? Or are you spawning a perl process from a
shell script? Again, if so, why? Using perl to call perl doesn't make
sense. Using the shell to call perl doesn't make sense most of the
time, either. So your first step, here, should be figure out how to
get 'perl -e' out of $cmd.
Aside from adding unnecessary complexity, the source of your problem
is that Perl and the shell have different quoting conventions, and
using the `perl -e'system($var)'` paradigm, aside from being logically
convoluted, also passes all of your variables through both Perl and
the shell at least twice--since your one argument approach to
system/exec invokes the shell. By the time qq/${rdist}...gets back to
perl again, the qq// is no longer being recognized as a perl operator.
You could (possibly) get around thisby adding another layer or two of
perl and shell escapes for the bits you want to save, but rewriting it
to pass the commands directly to system will be a lot cleaner, and
easier.
It will also expose some of the problems that haven't surfaced yet.
For instance: alarm(5) isn't doing anything, here, because you exec
immediately afterwards. The only things that survive the exec are
valid commands after "exec" the shell can execute. Also, the idiom
(assuming your shell is bash) for your rsh/scp test would be something
along the lines of 'exec qq/[ ${rdist} -cR \$srcdir
$ENV{host}:\$destdir ] || [ ${scp} -pr \$srcdir $ENV{host}:\$destdir
]/'. That begs the question, of course, of why you save your rsh and
scp commands in shell variables, but your directories in perl
variables. You could save yourself a lot of trouble by just doing
something like:
system("$ENV{rdist} -cR $srcdir $ENV{host}:$destdir") or
system("$ENV{scp} -pr $srcdir $ENV{host}:$destdir");
You can get a ${rdist} the same way you're getting at ${host}--that
is, though the %ENV hash. Also, make sure you're paying attention to
the differences between exec() and system(). testing for the success
of exec is redundant. By the time the test would run, perl has already
exited.
A better question, though, is: why aren't you using the CPAN modules
that already exist for these tasks?
HTH,
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.downloadsquad.com http://www.engatiki.org
values of β will give rise to dom!
