No immediate ideas, but all bash type shells (bash ash dash csh/tcsh etc) have -x and -v switches that produce voluminous trace output, before (-v) and after (-x) line execution, showing variable substitution and path expansion. This might help narrow it down. Adding a specific 'trace' invocation to the tar command might get even more detail specifically related to how tar resolves the gzip path.
-- - tony "I come from the nowhere, I go to the noplace, und here I am!" Aladdin and His Wonderful Lamp (Popeye, 1939) On Thu, Oct 4, 2012 at 11:47 PM, Russell Johnson <[email protected]> wrote: > Earlier today, I finished editing a script for backups. Parts of this > script have been working for months, and now they are failing. Things like > tar, gzip, ls, and grep, are now reporting as "no such file or directory". > As I said, these commands in my script have worked for months. Now, the > exact same commands are failing. It acts like a path issue, and I haven't > made any changes to the environment on this box. > > Specifically, this line: > > tar zcpf ${archiveDir}/dbdumps${DATE}.tar.gz . > > results in 'tar (child): gzip: Cannot exec: No such file or directory' > > gzip is always in the path. > > And, if I run; > > # which gzip > > I get: > > /bin/gzip > > If I run the tar command from the command line, it works. If I run the > script, as the same user, from the console, it fails. If the script runs > from cron (the desired place to run it), it fails. > > Any ideas? > > Russell Johnson > [email protected] > > > > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
