For my purposes, it would be extraordinarily helpful if, in the
next release, the -file option for the "inc" command would accept
as its argument some sort of magic token which would serve to
represent stdin. (By tradition, in many other programs this is
most often represented by a single dash.)
I am willing to roll up my sleeves and hack together this small
enhancement, if nobody else is and if it is generally considered
to be a useful addition.
Separately and additionally, I would also greatly benefit from
the addition, to the "inc" command, of a new option which would
cause "inc" to do what it does normally but _without_ making any
modification to the user's current $HOME/Mail/context file (i.e.
_not_ changing the current folder).
As with the other requested enhancement above, I am also willing
to develope a patch for this if no one else wishes to do so and
if there is agreement that the new fuinctionality would be useful.
To clarify why I am requesting these specific enhancements, I
suppose that I should explain what I am doing, so I shall.
I use the Postfix mail server, and in conjunction with that, I use
procmail as the local delivery agent.
I am signed up for many mailing lists, including this one, which
I do not actually read on a routine basis, but which I like to
archive locally using appropriately named MH folders that reside
underneath my own ~/Mail directory.
Of course, as far as the MH system is concerned, the proper way to
place a new message into a folder is the "inc" command. But "inc"
requires that the message be grabbed either after it has already
been delivered to the user's onw local maildrop file or else that
it come from a named file. This creates a sort-of impeadance
mismatch with the way that procmail wants to do things. It just
wants to pass the message file to some other command via stdin.
Also, of course, each time "inc" runs it diddles the user's
$HOME/Mail/context file to point to the folder/directory where the
nes message is being refiled, regardless of whether the user desires
this behavior or not.
The above facts have led me to kludge together my own solution for
the two problems I've described. Basically, I've created a small
shell script that I call "inc-stdin" which does everything necessary
to effectively do an "inc" on whatever file is supplied via stdin,
and which also effectively negates any diddling that the inc command
does to the user's $HOME/Mail/context file as well, after the "inc"
has been done. Here is my inc-stdin script. As I say, I am well
aware that this is utterly kludgy:
=========================================================================
#!/bin/sh
cat > /tmp/inc-stdin.$$
if [ -f $HOME/Mail/context ]; then
mv $HOME/Mail/context $HOME/Mail/context.save
inc -file /tmp/inc-stdin.$$ $*
mv $HOME/Mail/context.save $HOME/Mail/context
else
inc -file /tmp/inc-stdin.$$ $*
rm -f $HOME/Mail/context
fi
rm -f /tmp/inc-stdin.$$
=========================================================================
(Note that the above script expects to be supplied with one command line
argument, and that should be the name of teh MH folder/directory into
which the message supplied in stdin should be INCluded.)
With the above command installed into a directory that is part of my $PATH,
I can then put code like the following into my ~/.procmailrc file:
:0
* List-Id:.*nmh-workers\.nongnu\.org
| inc-stdin +nmh-workers
The above three lines direct procmail to notice all incoming e-mail messages
that would normally be delivered to my personal maildrop file, and then
take each one of those and instead of delivering them to my personal
maildrop file, sending them each instead, via the stdin channel, to my
litte "inc-stdin" script, which then dutifully files the message to
whatever folder was given as the first command line argument when the
inc-stdin script was invoked.
So anyway, the above is the kludge that I hacked together, some long time
ago now, which allows me to use nmh together with procmail to locally
archive various mailing lists that I am subscribed to.
Obviously, if I had the two small additional features in the "inc" command
that I have requested above, I could entirely do away with my silly little
"inc-stdin" script... and things would probably also be more reliable than
they are now. (As it is now, I have nothing in place to prevent two or
more instances of my little inc-stdin script from running at the same
time, and this can and does occasionally result in Bad Consequences
because of the lack of atomicity.)
Please let me know if my two suggested functional enhancements described
above sound useful, and/or if someone else is willing to hack them into
the source code, or if I should take a whack at it myself.
Thanks for reading.
Oh! And if anybody wants to suggest a less kludgy way of doing what I am
trying to do, then by all means, please do enlighten me.
Regards,
rfg
P.S. This is not really meant as a criticism, but to my way of thinking,
the inability of "inc" to accept input via stdin is not terribly consistant
with the general philosophy of UNIX generally, specifically the part of
the philosophy that says that whereever possible, each command should do
one small thing, and it should be possible, generally, to string them
together via command line pipes in order to effectively composite
bits of functionality together. In short, there really should be some
way to induce "inc" to accept input via stdin.
Also and separtely, as I've tried to illustrate above, that little extra
final bit of "inc" functionality, where it (helpfully?) diddles the user's
$HOME/Mail/context filer is... well... as the old saying goes, one man's
junk is another man's treasure... and vise versa. For me, what *I* most
desire is the ability to _disable_ and _turn off_ this functionality in
the "inc" command.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers