* Noah Sheppard <nhshepp...@taylor.edu> [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-...@mutt.org>. 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 ]
