Re: use current folder name as argument to abitrary command
* Noah Sheppard <nhsheppard@xxxxxxxxxx> [2009-05-02 01:56 -0500]:
> On Fri, May 01, 2009 at 11:28:39PM -0500, David J. Weller-Fahy wrote:
> > Right now everything works except from never gets set. I thought
> > this might be because of the timing (source happening before the
> > link is created), so I added a 0.5 second sleep after "list-from"
> > generation. Adding the sleep did not fix the problem from never
> > gets set because the source command runs before the shell finishes
> > creating the link, but I'm not sure.
>
> Hmm, I implemented a similar thing, and it worked correctly (thanks
> for suggesting the whole using a script to write a mutt command to a
> file and then sourcing it, since I hadn't gotten that far before).
You're welcome, I'm glad it works for you. My initial attempt was to
have a script which would use the filename of the script as the input,
then create a link to that script which was named "=lists.mutt-users"
(or whatever the mailbox is). That seemed overly complicated, though
neat, so I dropped that for command-line parameters.
My mutt runs on a debian install under VirtualBox which is running on a
Vista Host. That said, my theory is that mutt is going fast enough that
the file is not available in time for mutt to source it on my
installation. Not sure what to do if that's the case, though.
Here's my "mutt -v" output just in case there's something screwy. I'm
following HEAD on a personal install of mutt.
#v+
Mutt 1.5.19 (2009-04-28)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 2.6.26-2-686 (i686)
ncurses: ncurses 5.7.20090404 (compiled with 5.7)
libidn: 1.12 (compiled with 1.12)
hcache backend: GDBM version 1.8.3. 10/15/2002 (built Aug 27 2008
09:23:18)
Compile options:
-DOMAIN
+DEBUG
+HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL
-USE_FLOCK
-USE_POP +USE_IMAP -USE_SMTP
+USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS
+HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME
-CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
+HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE
ISPELL="/usr/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="Maildir"
PKGDATADIR="/home/dave/usr/mutt"
SYSCONFDIR="/home/dave/usr/etc"
EXECSHELL="/bin/sh"
-MIXMASTER
To contact the developers, please mail to <mutt-dev@xxxxxxxx>.
To report a bug, please visit http://bugs.mutt.org/.
#v-
> As I said, this works for me, and I don't have any timing issues
> either. I'm curious, why the "push <enter-command>" at the beginning
> of the last folder hook up above?
I was trying to make the source happen later in the sequence of events.
My theory was that pushing the source command onto the stack would force
mutt to wait until after running the shell command to perform the
source. This does not work (unfortunately), although it does force the
source to happen later in the sequence of events.
> I never knew whether mutt ran hooks in parallel or one after the
> other. Was it just a hunch you had that mutt doesn't wait for one
> hook to complete before moving on to another, or do you have some
> documentation which indicates this? I checked the mutt documentation
> but did not see anything to that end.
First, I tried your example and my_revdir did not contain the folder
name, although all the individual steps functioned as advertised. I
ended up simplifying it a bit by not changing the shell, and simply
including that as the text of the <shell-escape> command (that way I
don't have to worry about reseting the shell).
The timing idea is a hunch based on a specific behavior I can still
reproduce. Using the following muttrc commands.
#v+
# previously discussed
folder-hook . "set my_oldrecord=\$record"
folder-hook . "set record=^"
folder-hook . "set my_curdir=\$record"
folder-hook . "set record=\$my_oldrecord"
# save the state of wait_key
folder-hook . "set my_wait_key=\$wait_key"
# turn off wait_key
folder-hook . "set wait_key=no"
# run command to create file to source
folder-hook . "push <shell-escape>\"~/.mutt/muttecho.sh \$my_curdir\"<enter>"
# set wait_key to saved state
folder-hook . "set wait_key=\$my_wait_key"
# source the file
folder-hook . "push <enter-command>\"source ~/.mutt/muttintest\"<enter>"
#v-
And the following muttecho.sh file.
#v+
[ -e ~/.mutt/muttintest ] && rm ~/.mutt/muttintest
echo set my_revdir="$1" > ~/.mutt/muttintest
#v-
I get two results that I did not expect.
1) I get the "any key" prompt after the shell command executes.
2) my_revdir is not filled with the current folder name.
If I move the "set wait_key=\$my_wait_key" folder-hook below the source
hook, and leave the source hook untouched, then there is no change in
behavior. If I move the "set wait_key=\$my_wait_key" folder-hook so it
follows the source hook *and* change the source hook as follows.
#v+
folder-hook . "source ~/.mutt/muttintest"
#v-
Then I no longer get the "any key" prompt, but my_revdir is still not
filled with the current folder name. That establishes the wait_key is
being set to its saved state *before* the shell command is being
executed, which means mutt config statements are not necessarily
executed in order, which makes things a little more difficult. ;)
I also decided to confirm whether the source command is accomplished
differently depending on whether it is used directly or through the
<enter-command> function, and it is. Looking at the debug files, level
4, using the following command.
#v+
mutt -d 4 -f =lists.mutt-users
#v-
All other things being unchanged, and ensuring muttintest does *not*
exist when starting mutt, if I source without using <enter-command> then
at line 136 in the debug file the following lines occur.
#v+
Reading configuration file '/home/dave/.mutt/muttintest'.
/home/dave/.mutt/muttintest: No such file or directory
#v-
If I source using <enter-command> then at line 4629 in the debug file
the following lines occur.
#v+
Reading configuration file '/home/dave/.mutt/muttintest'.
/home/dave/.mutt/muttintest: No such file or directory
#v-
The line in the debug files (available upon request) are not important
except to show the source is happening at different times depending on
whether <enter-command> is used or not.
At this point I'm stumped. I still have my patch which allows me to
export the current folder name to an environment variable every time a
folder is entered, which solves this problem quite handily, but I was
hoping a patchless solution would be forthcoming.
Regardless, if anyone has any ideas as to how to track down the
specifics of *why* it doesn't work on my machine, I'd appreciate any
pointers.
Regards,
--
dave [ please don't CC me ]