John Rouillard wrote at about 14:50:10 +0000 on Monday, December 13, 2010: > 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.
Thanks - ALL very helpful! Thanks! However, I guess what I still don't understand is why it's ok with ending with something evaluating to 'undef' UNLESS I have an earlier backquoted system call. In other words: 1. backquoted system call but ends in something evaluating to true -> OK 2. no bacquoted system call & ends in 'undef' -> OK 3 backquoted system call & ends in 'undef' -> Get error In either case, since as you point out the file is do'ed, it may make sense as a default to end it in "1;" always (i.e., perhaps this should be added to the standard configuration. ------------------------------------------------------------------------------ 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/
