Re: Command expansion
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/pgp0.pgp Description: PGP signature
Re: Command expansion
* Rocco Rutte [EMAIL PROTECTED] [2002-03-27 16:35:14 +0100]: Hi, On Wed, Mar 27, 2002 at 07:18:15:AM -0500 David T-G wrote: ...and then Rocco Rutte said... 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 $signature is of type path. You can use a pipe there right now, but the behaviour is different. Mutt uses the output as the signature not as a path to a file to load. The change you want would break this behaviour or at least bring in some inconsistencies. Nicolas
Re: Command expansion
Hi, On Mon, Apr 01, 2002 at 03:13:16:PM -0500 David T-G wrote: Rocco, et al -- ...and then Rocco Rutte said... By the way, I find myself wondering how you tell mutt to not quote blank lines as you have here. Or do you have an editor startup command that changes all '^ $' to '' for you? The answer is: Vim. I'm using it for quite a few weeks and I tend to really love it. It does also repair broken subjects, removes the last '(was: ...)' in a subject line... Quite comfortable. % Haven't tried it, but it should do, yes. But it looks like hack. If you So what if it looks like a hack? If you look at it that way, most scripts and have of everyone's muttrc file will probably be hacks; after all, a hack -- particularly in this sense -- is putting things together in new and interesting ways. Yes, but there are ugly and more elegant hacks. The more elegant ones do not look so helpless. Cheers, Rocco. msg26496/pgp0.pgp Description: PGP signature
Re: Command expansion
Rocco -- ...and then Rocco Rutte said... % % Hi, Hello! % % On Mon, Apr 01, 2002 at 03:13:16:PM -0500 David T-G wrote: % Rocco, et al -- % ...and then Rocco Rutte said... % % By the way, I find myself wondering how you tell mutt to not quote blank % lines as you have here. Or do you have an editor startup command that % changes all '^ $' to '' for you? % % The answer is: Vim. I'm using it for quite a few weeks and I tend to Ah. That makes sense. I just couldn't figure out how you would have managed to break mutt like that :-) % really love it. It does also repair broken subjects, removes the last % '(was: ...)' in a subject line... Quite comfortable. Yes, vim is great! % % % Haven't tried it, but it should do, yes. But it looks like hack. If you % % So what if it looks like a hack? If you look at it that way, most % scripts and have of everyone's muttrc file will probably be hacks; after % all, a hack -- particularly in this sense -- is putting things together % in new and interesting ways. % % Yes, but there are ugly and more elegant hacks. The more elegant ones do % not look so helpless. Hmmm... Well, I'll give you that, but I don't think that changing the codebase is the elegant solution, either ;-) % % Cheers, Rocco. HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26497/pgp0.pgp Description: PGP signature
Re: Command expansion
Hi, On Mon, Apr 01, 2002 at 09:38:46:PM +0200 Nicolas Rachinsky wrote: * Rocco Rutte [EMAIL PROTECTED] [2002-03-27 16:35:14 +0100]: [...] So, as I said, a general solution. Sounds nice, at least to me. But $signature is of type path. You can use a pipe there right now, but the behaviour is different. Mutt uses the output as the signature not as a path to a file to load. I know. And in all other cases except $signature it is a path to a file and not that the output. And I thought of changing this behaviour. The change you want would break this behaviour or at least bring in some inconsistencies. If a change is usefull I don't mind completely breaking other things up. If just every configuration variable of type 'path' with a pipe as the last character would make mutt to use the output of the command should leave most configurations working. Cheers, Rocco. msg26498/pgp0.pgp Description: PGP signature
Re: Command expansion
Hi, On Tue, Mar 26, 2002 at 03:02:31:PM -0500 darren chamberlain wrote: I think if you \ the backticks, they will be evaluated when the variable is read, and not when the config is read. So, instead of: set record=`date +'%Y-%m-%d-%H:%M'` use something like: set record=\`date +'%Y-%m-%d-%H:%M'\` Untested. :) Think so. Doesn't work. It is evaluated at all. Rocco msg26243/pgp0.pgp Description: PGP signature
Re: Command expansion
Hi, On Tue, Mar 26, 2002 at 03:29:58:PM -0500 David T-G wrote: % The problem is the following: if I would type fast enough to send a few % dozen mails a minute, I wanted to be abled to include the date and time Heh. And you talk about not wanting to spam! :-) You're lucky. I'm too tired to type fast enough. ;-) In general, if you set your config inside single quotes, it will be evaluated at execution time (when you send the email or invoke the hook or whatever) rather than read time (when you start mutt or reread your muttrc file). The following doesn't work, too: set record='`date +/tmp/%H%M%S`' 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. You can see more on this if you search the archives for send-hook and uptime; this typically comes up when people want their x-uptime headers to be accurate to the time of the email rather than the time of the mua initialization. I'll have a look at the archive. But using hooks is not what I want. Just setting the variable. IIRC that would be a short section; if anything, perhaps just a note that says ... and you can only do this pipe thing on the $signature variable unless you see us talk about pipes on another variable. Yepp. Well, a while back I had this problem and (temporarily) solved it by using a hook which sources another file containing a my_hdr command. This special file was not sourced anywhere else. Seemed to work. ... and I thought that some more generall solutions would be interesting. Rocco msg26245/pgp0.pgp Description: PGP signature
Re: Command expansion
Rocco, et al -- ...and then Rocco Rutte said... % % Hi, Hello! % % On Tue, Mar 26, 2002 at 03:29:58:PM -0500 David T-G wrote: % % The problem is the following: if I would type fast enough to send a few % % dozen mails a minute, I wanted to be abled to include the date and time % % Heh. And you talk about not wanting to spam! :-) % % You're lucky. I'm too tired to type fast enough. ;-) *grin* % % In general, if you set your config inside single quotes, it will be % evaluated at execution time (when you send the email or invoke the hook % or whatever) rather than read time (when you start mutt or reread your % muttrc file). % % The following doesn't work, too: % % set record='`date +/tmp/%H%M%S`' Hmmm... Oh, I get it -- $record is only parsed once, so it will only be set once, no matter what. % % 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. 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... % % You can see more on this if you search the archives for send-hook and % uptime; this typically comes up when people want their x-uptime headers % to be accurate to the time of the email rather than the time of the % mua initialization. % % 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. Of course, you'd probably only want to do this from within a folder-hook or a special muttrc file. % % IIRC that would be a short section; if anything, perhaps just a note that % says ... and you can only do this pipe thing on the $signature variable % unless you see us talk about pipes on another variable. % % Yepp. % % Well, a while back I had this problem and (temporarily) solved it by % using a hook which sources another file containing a my_hdr command. % This special file was not sourced anywhere else. Seemed to work. Yeah; I'd go that route with the send-hook above and see how it works. % % ... and I thought that some more generall solutions would be % interesting. Interesting, to be sure, but someone has to want to code it :-) % % Rocco HTH HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26253/pgp0.pgp Description: PGP signature
Command expansion
Hi, I send this to the user's list and not to developer's because I do not want to 'spam' anybody. The problem is the following: if I would type fast enough to send a few dozen mails a minute, I wanted to be abled to include the date and time in the file I specify by the 'record' variable. Using `date`. But `date` is only expanded on startup. Pipes may not be used. So that all mails would end up in the same file the with time mutt read the config file. And permanently re-reading the config file is ugly. Just wondering if there's a mechanism to tell mutt to expand it everytime the value of a variable is used. Maybe by allowing pipes to be used more often or even generally? If not the documentation should be changed since it mentions the use of a pipe for the 'signature' variable. This may let people expect, that it works in other variables of type 'path', too. Which is not the case. At least a note should be inserted, that this for this variable only (just for the stupid ones ;-). I thought of dividing the 'path' type into one dynamic and on static. The dynamic ones would allow pipes generall whereby the static don't. Just a thought. Any ideas, opinions, comments? Rocco msg26191/pgp0.pgp Description: PGP signature
Re: Command expansion
Quoting Rocco Rutte [EMAIL PROTECTED] [Mar 26, 2002 14:55]: The problem is the following: if I would type fast enough to send a few dozen mails a minute, I wanted to be abled to include the date and time in the file I specify by the 'record' variable. Using `date`. But `date` is only expanded on startup. Pipes may not be used. So that all mails would end up in the same file the with time mutt read the config file. And permanently re-reading the config file is ugly. I think if you \ the backticks, they will be evaluated when the variable is read, and not when the config is read. So, instead of: set record=`date +'%Y-%m-%d-%H:%M'` use something like: set record=\`date +'%Y-%m-%d-%H:%M'\` Untested. :) (darren) -- All is fear in love and war.
Re: Command expansion
Rocco -- ...and then Rocco Rutte said... % % Hi, Hello! % % I send this to the user's list and not to developer's because I do not % want to 'spam' anybody. I think that -users is a good place for it. % % The problem is the following: if I would type fast enough to send a few % dozen mails a minute, I wanted to be abled to include the date and time Heh. And you talk about not wanting to spam! :-) % in the file I specify by the 'record' variable. Using `date`. But `date` % is only expanded on startup. Pipes may not be used. So that all mails % would end up in the same file the with time mutt read the config file. % And permanently re-reading the config file is ugly. Right. % % Just wondering if there's a mechanism to tell mutt to expand it % everytime the value of a variable is used. Maybe by allowing pipes to be % used more often or even generally? In general, if you set your config inside single quotes, it will be evaluated at execution time (when you send the email or invoke the hook or whatever) rather than read time (when you start mutt or reread your muttrc file). You can see more on this if you search the archives for send-hook and uptime; this typically comes up when people want their x-uptime headers to be accurate to the time of the email rather than the time of the mua initialization. % % If not the documentation should be changed since it mentions the use of % a pipe for the 'signature' variable. This may let people expect, that it % works in other variables of type 'path', too. Which is not the case. At % least a note should be inserted, that this for this variable only (just % for the stupid ones ;-). Hmmm... Not a bad idea, I suppose, but this functionality is only for signature, so that's a special case. % % I thought of dividing the 'path' type into one dynamic and on static. % The dynamic ones would allow pipes generall whereby the static don't. % Just a thought. IIRC that would be a short section; if anything, perhaps just a note that says ... and you can only do this pipe thing on the $signature variable unless you see us talk about pipes on another variable. % % Any ideas, opinions, comments? HTH HAND % % Rocco :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26204/pgp0.pgp Description: PGP signature
