Re: mutt vacation-list issue


----- Original Message -----
From: "jd" <jd@xxxxxxxxxxx>
Newsgroups: comp.unix.sco.misc
To: <distro@xxxxxxx>
Sent: Wednesday, March 28, 2007 7:43 PM
Subject: Re: mutt vacation-list issue




On Wed, 28 Mar 2007, brian@xxxxxxxxx wrote:

Quoting jd <jd@xxxxxxxxxxx>:



On Wed, 28 Mar 2007, Jean-Pierre Radley wrote:

jd typed (on Wed, Mar 28, 2007 at 11:09:06AM -0700):
|
|
| On Tue, 27 Mar 2007, Jean-Pierre Radley wrote:
|
| >
| >Ditch the version of deliver.vacation I sent in my last message.
|
| Why not ditch the whole thing and use procmail. There are vacation
| receipes available on the web. Why re-invent the wheel?

Why should I use 'procmail' when 'deliver' (with its own vacation
template script) works perfectly well, and existed years before the
wheel known as 'procmail' was (re-)invented?

Because there are procmail recipes that do EXACTLY what you are trying
to
do and are available to anyone who can use Google? For example:

http://www.clarkconnect.com/wiki/index.php?title=Howtos_-_Procmail_Vacation_Auto-Reply_Recipe

This one allows a system-wide procmail recipe, which sends auto-replies
only if the user creates a certain file in his/her home directory. The
text of the message is taken from that file. It also has extra
capability
to avoid mail loop problems.

Did you buy a new car when you ashtrays filled up?

OK, I'm totally puzzled. Why spend time trying to hack a script that does
not work properly (that's what the original post stated) when there are
working solutions already available?

Apparently, to some people, there is some value in using crufty old tools,
when there are better solutions available, but I just don't see it. I do
subscribe to the "if it ain't broke don't fix it" philosophy, but in this
case, the starting point was broken and in need of fixing. The quickest
solution would likely have been the installation of procmail.

So, let me ask you: if it costs more to fix your car than to buy an
equivalent new car, do you fix your old one? This is not like caring for
a classic car, this is about providing a service to your clients in the
most efficient manner, or don't you care about this?

Another thought for you: Usenet provides a resource for many people, don't
you think that if someone had no existing vacation solution and wanted to
install something that discussing alternatives has value?

But finally: I really don't see why the suggestion of a WORKING technical
alternative should be met with an ad-hominem attack.

The point is, the deliver script just uses things that are already on every
sco box out of the box. No installation. It's always valuable to be able to
get jobs done completely within the least common denominator if you can.
It's more efficient, if less fun, than telling the customer you need to
install something new and cooler. When you need a new or more sophisticated
feature that simply isn't available, fine, then the overhead becomes worth
it. But if as appeared to be the case here, the deliver script simply needed
a little bugfix or tweak, I say it was smarter to do that.

But... then again, I still write cgi scripts in, and do pretty much
everything other than actual application coding, in ksh and awk instead of
perl. By now I finally admit the main original arguments against doing
everything in perl no longer applies, which was: I worked on lots of old sco
boxes (as in, several xenix boxes even), and they had neither perl, nor any
painless way to get it, but the very oldest still had ksh88 and awk. (and so
did the few solaris, freebsd, linux, one hpux, one aix,...) Today all boxes
have perl.
The cpu/ram expence of loading a large interpreter like perl just to do
trivial things that could be done with shell builtins and awk, etc...(heck
I see people using perl just to do what cut does!) also mattered on those
old boxes, but while the discrepency is still true today, really doesn't
hurt much today.
So I have to admit theres no special reason to avoid perl anymore except
maybe for embedded or appliance developers, and even there theres an
argument for perl if one perl binary can take the place of all the rest.
Busybox pretty well proves that point I think.

Even though I understand above enough to have just written it, I still just
can't make myself not care about efficiency, and no matter how you dice it,
throwing out an established working thing, which your consultant, who you
pay a lot per hour, is many years fully familiar with, in favor of a brand
new question mark (where is a procmail binary for sco? how do you use it?
will it work with mmdf? does it have any dependancies like expecting a
certain shell (bash), will sco's suid/euid/shell/child-process behaviour
which differs from linux be a problem? will it need a big pain in the ass
library package download? will I need to do unhygenic things to make room on
my small root fs for said library update pack?etc etc etc), is just not
practical unless you need something only available that way, or you
consciously wish to explore the new possibilities and choose to take on the
overhead of the change. BTW, before you dismiss the fud-sounding list of
possible gotchas, every one of those are things I've actually run up against
for real and had to spend considerable time dealing with. And surely I
haven't managed to hit the last software integration problem yet either.

My response was intended to be neither attack nor ad-hominim.
It was merely devoid of all but the point. In my delusions of smartitude I
might even wish to say, efficient.

Brian K. White brian@xxxxxxxxx http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

.

Relevant Pages

  • Re: mutt vacation-list issue
    ... There are vacation ... |>>Because there are procmail recipes that do EXACTLY what you are trying to ... Why spend time trying to hack a script that does ... alternative ways to fix any problem, ...
    (comp.unix.sco.misc)
  • Re: Connecting to oracle from perl
    ... > I'm piping from procmail to perl where I want to connect to an oracle ... The problem is that this isn't working when I call the script from ... It is often a problem for cronjobs with oracle databases to not set ...
    (comp.lang.perl.misc)
  • Connecting to oracle from perl
    ... I'm piping from procmail to perl where I want to connect to an oracle ... The problem is that this isn't working when I call the script from ...
    (comp.lang.perl.misc)
  • 2005-11-20 [de.comp.lang.perl.cgi] FAQ
    ... Programmiersprache Perl in CGI-Scripten. ... Wo gibt es Dokumentation über Perl und CGI? ... Hilfe zum Programm perldoc kann man mit 'perldoc perldoc' ... Mein Script läuft nicht bei meinem Provider. ...
    (de.comp.lang.perl.cgi)
  • 2005-11-20 [de.comp.lang.perl.cgi] FAQ
    ... Programmiersprache Perl in CGI-Scripten. ... Wo gibt es Dokumentation über Perl und CGI? ... Hilfe zum Programm perldoc kann man mit 'perldoc perldoc' ... Mein Script läuft nicht bei meinem Provider. ...
    (de.comp.lang.perl.cgi)