On Aug 09 at 01:45, Udi Mottelo spoke:
On Thu, 8 Aug 2002, Hanspeter Roth wrote:
On Aug 08 at 10:17, David W. Tamkin spoke:
Then the cycles are wasted for procmail to scan for the characters and
possibly to fork an extra shell process that wasn't needed.
Thus as long as I quote properly is it an issue of performance?
Yes, but not only performance - The shell looking for the global
and user's startup files and run if needed; set the environment;
set agine the stdio files, check if you need prompt (!?!?) and so on
Depending on the shell one can set appropriate options to suppress
it.
It some times happens to me that I pipe twice into sed:
| sed 'session1' | sed 'session2'
You can use "-e" flag:
sed -e 'session1' -e 'session2'
I usually try to pass all commands with by -e. But it frequently
happens to me that one of the latter commands seems to have no
effect. Then I just pipe to another sed invocation and it works.
Or write the sed commands in file and call the file by "-f":
sed -f somesedcommands.sed
I could try whether this solves my problem above.
The "|" will force procmail to call the shell.
If I have only 5 messages a day on one recipe it makes probably no
big difference to avoid a shell invocation.
Should I set SHELL to light version of shell (/bin/ash or /bin/sh)
rather than something like bash?
I think that the gap is not so big. In some operating systems
The gap might be affected whether other initialization scripts
(.bash_env, .cshrc) are processed. But this might be handled by
setting appropriate shell flags (SHELLFLAGS).
But maybe also a shell with less features which checks for less in
it's environment is faster to invoke.
bash(1) and sh(1) are symbolic linked to the same one binary
This is probably the case on many Linux'. Then one could use ash
instead.
file. Anyway, sh(1) is very generic, standard (vanilla).
The original Bourne shell is sufficient for piping. No need for
aliases and the like. Thus on a system where /bin/sh is a _real_
Bourne shell it is probably best for procmail.
The "c family" like tcsh or csh are built for interactive session
and not recommended for batch mode or integration with other programs.
I have my own experience in this.
I occasionally use tcsh as an interactive shell. But I avoid using it
for scripts.
Take a rest and read the article with the name "Why Not Csh?" (:-)
or "Csh Programming Considered Harmful". Tom Christiansen covers
the csh(1) problems against sh(1) benefits (include bash, kash).
http://www.perl.com/pub/a/language/versus/csh.html
Thanks for the link.
I can work with my current shell setup. But I still haven't found my
final tuning.
-Hanspeter
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail