On Thu, 2015-02-05 at 01:21 -0700, LuKreme wrote: > > On Feb 5, 2015, at 1:03 AM, Bob Proulx <b...@proulx.com> wrote: > # /bin/sh > # PATH=/bin:/usr/local/bin echo $PATH && echo $PATH > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin > > Hm. That’s odd. > > Something else going on there. > Normally, setting any shell variable, including PATH, in a shell script only takes effect in that script. If you want it to affect child scripts, prefix it with 'export':
export PATH=/bin:/usr/bin:/usr/local/bin Another convention that might be having an effect is that programs that are included in packages installed with your UNIX/Linux package installer are normally placed in /bin or /usr/bin but programs installed by other methods (e.g. make; make install if the program was supplied as source should be placed in /usr/local/bin). I think CPAN installs of Perl programs normally do NOT end up in /bin or /usr/bin but I could be wrong about that. These possibilities are why you were asked to run 'which xxx' as a cron script, where xxx is a program that wasn't found by sa-update. If 'which' says 'not found, try running 'locate xxx': this will find the program (and any similar names) by searching a database which references the entire filing system. If it isn't installed or its database isn't up to date, "sudo find / -name xxxx" will do the same job but it will be much slower and doesn't match similar names. Martin
