The blame lies not in the shell but in the shell's proponents. This list
frequently sees questions about strange error messages complaining about not
having a terminal. Invariably they come about because (1) the user has
$SHELL set to csh, tcsh, or ntcsh; (2) there is a recipe whose action line
includes one or more characters from $SHELLMETAS, so it invokes a shell when
it is used; and (3) the user's .cshrc contains an stty call or something else
that requires a terminal.
Sorry but I have to disagree. The blame lies with procmail and its
documentation. Obviously, procmail is programmed with the assumption
that the login shell is a sh derivative. This assumption is a) not very
nice, and b) not stated in the otherwise very good documentation. Of
course a user can set SHELL to tcsh. If then procmail is too stupid to
hack it, it ought to say so clearly, and the above mentioned questions
of people using tcsh will disappear from this list. One could also be
nice and point out pitfall (3) mentioned above in the procmail docs. It
is customery to have terminal configuration in .login. If it is shifted
to .cshrc it should be properly surrounded by if .. endif. Perhaps it is
not customary to configure the terminal in .bashrc (where else then? -
only a rhetorical question), but that is no reason to blame it on tcsh.
Now, why do we never see that question from bash or ksh users?
Because procmail was programed to work with those only. Had it been
programmed to work with tcsh only the questions would come the other
way round.
Likewise, bash and ksh users are taught to define
and export PATH in .profile, so our per-shell startup files would not have
clobbered the PATH set in .procmailrc the way your .cshrc did.
My .cshrc only setenvs the environment when it is a login shell (shell
level 1). Obviously procmail runs a login shell. As I said earlier,
there are good reasons for setting a full PATH independently whether the
shell is interactive or not. So, when procmail executes programs with
SHELL=tcsh, PATH is set to the tcsh defaults. That may or may not be
desirable, depending on the individual case. No problem with that and
avoidable (run tcsh with -f). Nice if it was in the procmail docs.
But then, the PATH getting clobbered is not the point here (just a
side-effect I didn't realise until 2 people pointed it out).
It did not take care of your original problem and was not intended to; it
was the answer to your ancillary question of why the wrong $PATH was logged.
Yes, and thanks for it again :-)
Also thanks David for your knowledgable comments to Gregory's suggestions,
and thanks Gregory for your suggestions to which I do not need to reply
as well.
As to your original problem that mail that falls off the end of your rcfile
skips $DEFAULT and goes straight for $ORGMAIL, even though $DEFAULT is quite
No it does not go for $ORGMAIL either. $ORGMAIL = $DEFAULT as the log confirms.
writable as demonstrated by the success of a recipe that explicitly saves to
$DEFAULT, I'm still stumped.
me too. :-( (I hope this does not turn out to be extremely embarrassing
for me...)
You know, it shouldn't, but I wonder what would happen. Volker's situation
is so danged anomalous that I wouldn't place any bets. I'm really curious to
know whether that would somehow make it work.
It is a strange situation. Volker, can you try this, just to see what
will happen?
Ok, I tried to set MAILDIR and then DEFAULT relative to it, but still
no difference.
cat rc2
SHELL=/bin/sh
VERBOSE=yes
PATH=/bin:/usr/bin:/usr/local/bin
MAILDIR=$HOME/t/procmail/Mail
DEFAULT=inbox
ORGMAIL=$DEFAULT
LOGFILE=./procmail.log
UMASK=076
LOG="$DEFAULT $ORGMAIL $SHELL $LOGFILE $PATH
"
env
[not abbreviated!]
HOME=/home/users/pg/kuhlmav
PWD=/home/users/pg/kuhlmav/t/procmail
/bin/sh -c "$HOME/bin/procmail ./rc2 <m"
procmail: [18844] Mon Aug 17 16:46:04 1998
procmail: Assigning "PATH=/bin:/usr/bin:/usr/local/bin"
procmail: Assigning "MAILDIR=/home/users/pg/kuhlmav/t/procmail/Mail"
procmail: Assigning "DEFAULT=inbox"
procmail: Assigning "ORGMAIL=inbox"
procmail: Assigning "LOGFILE=./procmail.log"
procmail: Opening "./procmail.log"
cat Mail/procmail.log
procmail: Assigning "UMASK=076"
procmail: Assigning "LOG=inbox inbox /bin/sh ./procmail.log
/bin:/usr/bin:/usr/local/bin
"
inbox inbox /bin/sh ./procmail.log /bin:/usr/bin:/usr/local/bin
procmail: Locking "/var/mail/kuhlmav.lock"
procmail: Assigning "LASTFOLDER=/var/mail/kuhlmav"
procmail: Opening "/var/mail/kuhlmav"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/mail/kuhlmav.lock"
From procmail-request(_at_)informatik(_dot_)rwth-aachen(_dot_)de Sun Aug 16
17:43:02 1998
Subject: Re: Problem with username
Folder: /var/mail/kuhlmav 803
procmail: Notified comsat: "kuhlmav(_at_)2409:/var/mail/kuhlmav"
It works if I append a
:0:
$DEFAULT
to rc2.
Just our of curiosity, I should go to the sysops and see whether I can
change my login shell... And don't get me wrong, I still think procmail
is a very good piece of software, but I also think that its shell handling
(if that turns out to be the problem) is less than satisfactory.
Volker