Re: use current folder name as argument to abitrary command
* Cameron Simpson <cs@xxxxxxxxxx> [2009-05-26 18:20 -0500]:
> On 25May2009 22:30, David J. Weller-Fahy
> <dave-lists-mutt-users@xxxxxxxxxxxxxxx> wrote:
[ ... snips ... ]
> | Brought a tear to my eye! I just spent ~30 minutes trying to trim
> | away the macro, but I have not been able to yet. I'm sure my
> | understanding of mutt's quoting levels is insufficient as of yet.
>
> You probably can't reduce it, given the order in which things need to
> happen.
Yep, I was coming to that conclusion.
[ ... snips ... ]
> | > because we need to construct a mutt-level ""-quoted string, and
> | > also it has to happen in the folder hook because we don't have
> | > the folder name before then.
>
> It has to happen inside the folder-hooks because it needs to be
> re-applied if you switch folders. Also, (if you didn't want to update
> on a folder change) I think I established by experiment that the main
> muttrc is sourced before opening your first folder, so you can't ask
> for the folder name then.
I should have been more specific. I understand why the folder-hook has
to be used, but don't quite get why the mutt-level ""-quoted string
can't come from something like the following (doesn't work).
#v+
folder-hook . 'push ":\\\`~/.mutt/listbox-to-email.pl\ $my_folder\\\`<enter>"'
#v-
I do not understand why the macro is required to force mutt to parse
that ""-quoted string, and now I'm wondering if there are any other
constructs which would allow the same level of parsing without defining
a macro... hrm. Methinks I need to read more of the source, manual, and
wiki to understand, but that may have to wait until I get more
round-tuits.
> BTW, something I may raise in another thread: the output of
> cs-mutt-per-folder (or whatever command you put in backticks there)
> _must_ be a single line of text. Mutt reads just the first line and
> closes the pipe, producing a Broken Pipe signal in the script and
> discarding following lines. So the script should produce:
>
> mutt-cmd; mutt-cmd; ...
That is odd, but workable. Also I found something to watch out for when
using this method: Make sure your script *always* produces a command
recognizable to mutt when run, otherwise the lack of a command will
cause an error. For example, when run in my =lists folder my particular
script does not emit anything. As a result, I receive a ': unknown
command' message on the status bar. No harm, but it can be prevented.
I used a "set wait_key\n" just to test, and it prevented the message.
Regardless, this works for me and I'll be using it from now on.
Thanks again!
--
dave [ please don't CC me ]