What's a good way to handle this? Something along the lines of
"| IFS=' ' && exec `csh -cf 'echo ~ruck'`/bin/procmail -f- || exit 75
#ruck"
I asked for a good solution, and stated that the above didn't work for me.
BTW, it looks like the reason mine didn't work is that on this system,
the working directory, when .forward is processed, isn't $HOME and isn't
readable to an ordinary user like me and I guess csh expects it to be
readable -- csh complains ("getwd: can't stat ."). So I inserted a
"cd /" before the exec, and all is well now.
"| IFS=' ' && cd / && exec `csh -cf 'echo ~ruck'`/bin/procmail -f- || exit
75 #ruck"
Someone suggests to me by private email "don't use csh". I wouldn't
dare to incite a shell-religion war, but having read Tom Christenson's
(sp?) fine consideration of csh (title "10 reasons why csh is harmful" ?),
I don't disagree with that advice in general.
However, I need a feature (equivalent to gethome(user)) not found in sh.
It is found in modern shells bash, ksh, tcsh, etc., but those
generally might live in a directory (/usr/local/bin) not on the path as
it is known at that point. I could hardcode the path to
/usr/local/bin/bash to avoid using csh, but, ...
Anyway, in all the systems I use, a copy of csh is in a local
filesystem, whereas /usr/local/bin might well be NFS-mounted and
therefore potentially unavailable occasionally. I realize the same
comment could be made about my home directory, though. Sorry to
ramble.
Another correspondent suggested using ... exec ./bin/procmail ...,
on his system, a Linux, the working directory *is* the home directory at
the time .forward is processed -- but that is not the case with the
system I am working with.
$HOME would have been nicely user-neutral. It could have been
recommended to all procmail users who prefer to use their own copy of
procmail rather than their system's old v2.93 procmail.
Since HOME isn't set, and nothing else useful is set in the environment
in my situation, I would have to go to absurd lengths to create a
user-neutral .forward that does what I'm discussing -- I'd have to
massage the output of id(1) to get username, then continue as previously
discussed.
I appreciate your comments.
John Ruckstuhl