Ok, as everyone seems to be making comments about tcsh I will do the same.
First, shells seem to be like editors: heavily fought over. That however
does not give a good reason to make low-level remarks about tcsh.
> There are two general classes of problems in using csh or a
> derivative as your procmailrc's shell:
> 1. terminal-dependent commands in .cshrc that should be either
> placed in .login or wrapped in an if structure that skips them if
> the shell is not attached to a terminal;
This is not a problem confined to tcsh. Every shell executing startup
commands from somewhere has teh same problem. This includes everyone's
seem-to-be-favourite, bash.
> 2. csh's general problems as a scripting shell.
Perhaps. But using csh when there has been tcsh is a little behind the
times. There is a long article on the internet raving about csh - both
csh and that article are long obsoleted. In my experience, both tcsh
and bash suck in some places, but I don't want to waste time on details.
In my experience, the most problems with tcsh come from people who are
not very familiar with it. This is the case with every software and not
a tcsh-specific problem. This tcsh issue is valid for otehr shells too:
Fix #3: put your PATH for interactive logins into your in environment in your
~/.login and get it out of your ~/.cshrc.
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).
So again: blaming that sort of thing on tcsh is not on. Bash reads in
.bashrc too.
This snippet here
test -r $HOME/.home/setenv && source $HOME/.home/setenv
test -r $HOME/.home/set && source $HOME/.home/set
test -r $HOME/.home/alias && source $HOME/.home/alias
test -r $HOME/.home/bindings && source $HOME/.home/bindings
supports my point. Although equivalent, nobody with efficiency in
mind would run an external program (test) when there are fast internal
equivalents. The reason for the existance of "test" I take it is that
/bin/sh is so pathetic to not have an integrated equivalent. tcsh is
not meant to work the same as /bin/sh.
Summary of what I am saying: problems of stupid programs like procmail,
which can't even work with a non-/bin/sh shell, should not be blamed on
the shell. Unix-systems are meant to have different shells, or they'd
be called MS-DOS. And other not shell-related programs ought to work
with any shell or else take the flak.
Here another test:
tcsh> /bin/sh
$ cat rc
SHELL=/bin/sh
VERBOSE=yes
PATH=/bin:/usr/bin:/usr/local/bin
DEFAULT=./Mail/inbox
ORGMAIL=$DEFAULT
LOGFILE=./procmail.log
UMASK=076
LOG="$DEFAULT $ORGMAIL $SHELL $LOGFILE $PATH
"
$ $HOME/bin/procmail ./rc <m
procmail: Enforcing stricter permissions on "/var/mail/kuhlmav"
procmail: [17565] Mon Aug 17 10:19:41 1998
procmail: Assigning "PATH=/bin:/usr/bin:/usr/local/bin"
procmail: Assigning "DEFAULT=./Mail/inbox"
procmail: Assigning "ORGMAIL=./Mail/inbox"
procmail: Assigning "LOGFILE=./procmail.log"
procmail: Opening "./procmail.log"
$ cat procmail.log
procmail: Assigning "UMASK=076"
procmail: Assigning "LOG=./Mail/inbox ./Mail/inbox /bin/sh ./procmail.log
/bin:/usr/bin:/usr/local/bin
"
./Mail/inbox ./Mail/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: [17570] Mon Aug 17 10:21:16 1998
procmail: Notified comsat: "kuhlmav(_at_)4015:/var/mail/kuhlmav"
procmail is run from /bin/sh, and with SHELL=/bin/sh first in the resource
there is no reference to tcsh left. I had before deleted all env vars
except HOME. And yes, ./Mail exists and is writable. Still procmail
stuffs up - which is clearly procmails fault. If it happens that procmail
stuffs up because my login shell is tcsh then that is even more procmails
stupidity. I am not shifting shells because of procmail. So far tcsh has
done very well thank you. And under these circumstances I would be very
reluctant to install procmail system-wide as LDA.
I did not mean to attack anyone personally, the people on this list are
very qualified (and thanks again for all your replies), but to get the
blame to where it belongs.
'nuff time wasted. :-)
Volker