Hi, On Wed, Mar 27, 2002 at 07:18:15:AM -0500 David T-G wrote: > ...and then Rocco Rutte said...
> % The following doesn't work, too: > % > % set record='`date +/tmp/%H%M%S`' > Oh, I get it -- $record is only parsed once, so it will only be set once, > no matter what. Exactly. > % What I thought of is that 'record' becomes a special type of 'path' > % allowing pipes. Appending '|' could cause mutt just to remember that > % string (instead of its expanded value) and evaluate it short before > % usuage. > Well, yeah, but that would require completely rewriting the code that > handles $record. Yes and no. It would not only affect $record. I try it onces more. What I thought of is functionality which would lead up this: *all* variables of type 'path' are handled different. If there's a pipe appended, mutt internaly stores the complete string at startup and doesn't expand anything. Before usage, that pipe has to be recognized so that not the string is used but the output of the command specified. After that assignment, the variable still has the same value as before because it would have to be left untouched. So, as I said, a general solution. Sounds nice, at least to me. But there're several cases or situations where this behaviour could cause real trouble. For example, if someone - as a mistake - appends a pipe to the $sendmail variable... what would happen? Right, nothing. Absolutely nothing. Because the command (the real sendmail) is executed and expected to return some output telling mutt where the binary is located. And you'll wait for that output till next reboot. As Sven said, mutt is not for everyone. So this, if implemented, could be left with just a warning in the manual. To avoid such mistakes, the 'path' type could be split up into two types. One allowing pipes (like $record, $signature,...) and one not allowing pipes *and* producing a parse error upon startup (for $sendmail, $inews, ...). I'm sure that I want pipes to be usable more generally. What I'm not sure about is wether trying to detect misconfiguration or not. > That would probably be welcomed, after all of the talk > of making fcc-save-hook able to save to a pipe so that a script can save > multiple copies of the message, but nobody has stepped up to *that* yet > and so I don't see it happening for this... Well, that's another different topic. Really nobody done this before? > % I'll have a look at the archive. But using hooks is not what I want. > % Just setting the variable. > That gives me an idea, though. You could > send-hook . 'set record="`date +/tmp/$H$M$S`"' > and then it *would* be repeatedly evaluated but not until the hook is > executed, and that should get you what you want. Haven't tried it, but it should do, yes. But it looks like hack. If you go upon such a level on a regular basis, saving multiple copies of outgoing messages is more than trivial, too. Just write a script saving to locations you want and finally handing the mail over to $sendmail. Done. > % ... and I thought that some more generall solutions would be > % interesting. > Interesting, to be sure, but someone has to want to code it :-) Sure. It would be done already if I had the skills. Mutt would even suck much less, if I had the skills. ;-) Rocco
msg26479/pgp00000.pgp
Description: PGP signature
