| |||||||||||||
Reports of procmail's death are not terribly exaggeratedReports of procmail's death are not terribly exaggeratedPosted Nov 25, 2010 3:08 UTC (Thu) by Tara_Li (subscriber, #26706)Parent article: Reports of procmail's death are not terribly exaggerated
What is up with this whole move to having a whole *language* to write a config *data* file in? While it certainly makes it easier for the project programmers - all *they* have to do is just execute the config file, it definitely makes it harder for the users, who, well, if they wanted to write programs, they'd be programmers and not users.
And I'm still *VERY* fuzzy on what the advantage of all this stuff is over keyword = value config files - don't start with the XML crap, either, it's mostly a longer version of keyword = value...
(Log in to post comments)
Reports of procmail's death are not terribly exaggerated Posted Nov 25, 2010 4:27 UTC (Thu) by jamesh (guest, #1159) [Link]
Because the configuration files for these mail filters _are_ programs. Granted they have a limited command set and control structures, and the procmail filtering language is a bit bizarre looking, but they are programs.
This isn't the same as using a full fledged programming language to parse a simple key/value configuration file.
Reports of procmail's death are not terribly exaggerated Posted Nov 26, 2010 16:40 UTC (Fri) by HelloWorld (guest, #56129) [Link]
I disagree, writing rules to sort emails has nothing to do with programming. Many MUAs today have graphical tools to build rules like that; is everybody using such an MUA a programmer? Clearly not.
Reports of procmail's death are not terribly exaggerated Posted Nov 26, 2010 21:32 UTC (Fri) by giraffedata (subscriber, #1954) [Link] writing rules to sort emails has nothing to do with programming. I wonder what your definition of programming is such that writing these rules isn't it. It seems to me that writing a procmail rule file involves the same skills and mental processes as, say, writing a Bash program, which I assume falls within your definition of programming. It's a matter of composing software to control a machine. In a company, it's probably the same person who does both. There is a continuum from programming to simple end use (setting the time zone on a computer isn't programming), and the line of demarcation is fuzzy, but coding the configuration files I see in the article fall well on the programming side of it in my opinion. If a graphical tool to build mail handling rules is complex enough, I would call that programming too. Programming doesn't have to be done in text (the original programming was done by plugging wires).
Reports of procmail's death are not terribly exaggerated Posted Nov 25, 2010 6:52 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] And I'm still *VERY* fuzzy on what the advantage of all this stuff is over keyword = value config files - don't start with the XML crap, either, it's mostly a longer version of keyword = value... Show the designers a keyword = value config file that is as powerful as a regexp while maintaining similar size, and I'm sure they'll be happy to adopt it. But for this specific application, you really need a full regexp engine to do what you want to do. It might be possible to improve readability a bit with some syntactic sugar, but that's a very tricky balancing act. It's very easy to bloat the syntax to the point that it loses readability. More generally, I share your dislike for overuse of XML but I understand it. XML is a fairly heavyweight solution, but it comes with some really nice tools that make it easy to read, write, and validate. I get the impression that people wind up using even when they might be better served with a lightweight keyword = value file because they want to be future proof- who knows if the config file might blow up into a monster in the future- and because they know and are used to working with the XML toolset.
Reports of procmail's death are not terribly exaggerated Posted Nov 25, 2010 13:44 UTC (Thu) by nix (subscriber, #2304) [Link]
Hell, not only do you need regexes, you need the ability to run arbitrary programs and make decisons based on their exitcodes, or, possibly, command-line output: allowing shell fragments, or something like them, works well here. You need the ability to do *multiple* things if a test passes or fails, which means you need conditionals and a block structure.
The syntax may be rebarbative, but procmailrc surely is a language.
Reports of procmail's death are not terribly exaggerated Posted Nov 25, 2010 11:33 UTC (Thu) by neilbrown (subscriber, #359) [Link]
I'm a big fan of keyword=value as well, but just that is never enough. My favourite example at the moment is udev - the rules files (/lib/udev/rules.d/) are essentially keyword=value sets, but they also allow GOTO="somewhere" and LABEL="somewhere". goto certainly has its place, but but keyword=value isn't that place.
You at least need some macroscopic structure. Sometimes [sectionname] (using the the config files used by samba and many others) is enough, but sometimes you really do what an hierarchical structure. And in that case, mimicking the structure of a programming language makes sense (though I would prefer to follow python myself).
... because really, there is no difference between the 'program' and the 'data' - they are both streams of bytes and both need to be interpreted by some machine...
|
|||||||||||||