Volker Kuhlmann wrote,
| In my experience, the most problems with tcsh come from people who are
| not very familiar with it.
Absolutely. The same can be said of almost everything else, including
automobiles and firearms.
| Because .login (supposed to contain basic important system setting) is
| read in before .cshrc (to contain not so important user customisation),
| using .login is basically a farce in my opinion. Putting teh contents
| of .login into .cshrc with an approprite if .. endif makes that
| work. However, not executing the .login part inside .cshrc when the shell
| is not interactive is no good solution either because often I have good
| reason for my non-interactive uses to have the same environment as my
| interactive ones (wrt PATH etc).
No one said that everything in .login should be skipped when the shell is not
interactive, just those things that depend on an interactive shell or on a
terminal, like stty calls. Setenv statements, for example, are rarely a
problem.
| So again: blaming that sort of thing on tcsh is not on. Bash reads in
| .bashrc too.
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.
Now, why do we never see that question from bash or ksh users? How do bash
and ksh users know that stty commands belong in .profile and not in .bashrc
or .kshrc? It's clearly a matter of better instruction, not of anything
intrinsic to the shell. 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.
At any rate, that was why your log showed the PATH from your .cshrc and not
that from your .procmailrc. When you switched from "echo $PATH >> file" to
LOG="$PATH<newline>" you saw the path from .procmailrc.
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.
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
writable as demonstrated by the success of a recipe that explicitly saves to
$DEFAULT, I'm still stumped.