On Sat, Dec 11, 2010 at 10:52:16PM -0500, Jeffrey J. Kosowsky wrote:
> Jeffrey J. Kosowsky wrote at about 22:46:20 -0500 on Saturday, December 11,
> 2010:
> > As some of you may know, I have been successfully adding perl script
> > to the machine config files.
> >
> > However, I just noticed that if I add a system command using
> > backquotes, then I get an error of form:
> > dump failed: Can't read PC's config file: Couldn't open
> /etc/BackupPC/pc/mymacine.pl.pl: Bad file descriptor
> >
> > or of form:
> > dump failed: Can't read PC's config file: Couldn't open
> /etc/BackupPC/pc/consult.pl: No such file or directory
> >
> > However, whether or not the error appears seems to depend on what perl
> > statements follow the backquoted command. In particular, having a
> > 'print' statement follow or even just a '1;' stops the error. But
> > having a 'variable = undef' statement causes the error to show.
> >
> > This seems weird. Any idea what might be going on here?
> > I assume it must be setting some type of variable or return value or
> changing
> > something in the stack that signals that the sourcing of the config script
> failed.
>
> OK. Here is some more info.
> The error occurs if:
> 1. There is a backquoted system command
> 2. The last statement in the config file evaluates to 'undef' (no
> matter how many other statements there seem to be between the system
> command and the final statement)
Well required/do'ed files usually have a
1;
at the end of the file to allow the import mechanism to succeed and it
looks like that also works in your case. Having the evaluated file
result in undef is an error (see perlfunc require which makes
reference to do and eval) which ends with:
The file must return true as the last statement to indicate
successful execution of any initialization code, so it's
customary to end such a file with "1;" unless you're sure it'll
return true otherwise. But it's better just to put the "1;", in
case you add more statements.
what backquoted command are you using? Is it assigned to a variable?
Does it return output that is interpreted as true. Since the
successful exit status from a successful shell command is 0, that
could become the final result of the eval'ed file and hence your
issues. `...` is a perl op and I am not quite sure what it returns but
the above seems plausible.
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
