LuKreme wrote: > Bob Proulx wrote: > > The syntax "variable=value command" is a /bin/sh syntax which sets the > > variable for just that command. In the above sa-update would get the > > PATH setting. But then && terminates that command. > > I’m actually not positive that is the case.
I am positive. :-) But please do work through the case and verify it for yourself. Learning how this works is a fundamental part of the system. > The && syntax chains the commands into a dependent chain (sa-update > only triggers if sa-update succeeded and sa-spamd restart only > triggers if both previous commands succeeded, so it would certainly > make sense that some state like setting variables is > preserver. Haven’t tested this, but it’s pretty trivial. > > # /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. Yes. Something else is going on. :-) The $variable syntax in your above is expanded by the shell *before* the command is executed. Both of the echo $PATH are showing you the shell's value of it and not the value that you are trying to set before it. You can never set a variable for the shell process and then have the parent shell expand it. 'var=foo echo $var' will never produce a useful result. There is a little used command 'printenv' that isn't very useful normally but for just this case can be just the right tool to print the environment variable value without the shell. $ export var ; var=foo ; var=bar printenv var && printenv var bar foo Then one last thing of note here. PATH is a special shell variable. PATH in /bin/sh is an automatically exported by the shell. One must explicitly export other variables but PATH is already an exported variable. > > The next two commands sa-compile and sa-spamd would not get PATH set > > differently for them. Is that important to you? > > No idea. I don’t know about the internals of sa-compile. I can’t think of any > reason it could need gpg though. I thought the issue being discussed was that locally installed components installed in /usr/local and system installed components installed in /usr and my skimming of the problem was that PATH needed to include /usr/local/bin so that it would find locally installed components for all of the tools? No? > > # The default vixie-cron PATH is "/usr/bin:/bin", overriding the > > environment. > > PATH="/usr/local/bin:/usr/bin:/bin:/usr/games” > > That does seem better (well, minus /usr/games) That was just an example. In my I always add "/home/rwp/bin:/usr/local/bin:/usr/bin:/bin" so that I get my $HOME/bin commands too. (Note can't use $HOME because vixie-cron isn't the shell and doesn't expand variables like that so for the vixie-cron setting must use fully expanded paths.) > > Then PATH will be set for all commands started from that crontab. > > > > Personally I prefer to use a file /etc/cron.daily/spamassassin which > > then calls all of the individual programs. The /etc/cron.daily is a > > directory of scripts (not crontabs) where each script is run once > > daily one after the other. Since that is a script you can set PATH in > > that script and again it would be set for all subsequent invocations. > > That also sound good, but my crontab is actually quite > simple. Sa-update, portsnap, and some deleting aging emails. If you are often in the habit of using cron with your /usr/local (which is perfectly fine!) then I would definitely add that to the PATH for all of your crontab commands. It just makes sense to me. The alternative is to always run a script wrapper around anything you want to do. That is also a really good way to do things. Then you can set any variable such as PATH that you need in the script wrapper. Bob
