bash script workflow artificially serialized

[nesono]

Hi All,

 

I want to fire off MacVim with a keyword action and a shortcut for where to open MacVim, e.g.:

mvim d -> open MacVim in the folder ~/Downloads
mvim h -> open MacVim in the folder ~/
...

I wrote a case statement in bash like this:

MVIM=/usr/local/bin/mvim

case "{query}" in
  "h")
    cd ~/ && $MVIM
  ;;
  "d")
    cd ~/Downloads && $MVIM
  ;;
  *)
    echo "unknown directory specified"
  ;;
esac

And when I run (e.g., mvim d) it once works flawlessly. However, if I want to open a second window of MacVim by running e.g. 'mvim h' nothing happens until I close the first window. It feels like the calls are queued (or mvim is not detached from the shell and keeps the workflow open and blocks it).

 

Is this by design or could somebody give me a hint how to work around this?

 

Thanks in advance,

 

jochen

[jdfwarrior]

Hi All,

 

I want to fire off MacVim with a keyword action and a shortcut for where to open MacVim, e.g.:

mvim d -> open MacVim in the folder ~/Downloads
mvim h -> open MacVim in the folder ~/
...

I wrote a case statement in bash like this:

MVIM=/usr/local/bin/mvim

case "{query}" in
  "h")
    cd ~/ && $MVIM
  ;;
  "d")
    cd ~/Downloads && $MVIM
  ;;
  *)
    echo "unknown directory specified"
  ;;
esac

And when I run (e.g., mvim d) it once works flawlessly. However, if I want to open a second window of MacVim by running e.g. 'mvim h' nothing happens until I close the first window. It feels like the calls are queued (or mvim is not detached from the shell and keeps the workflow open and blocks it).

 

Is this by design or could somebody give me a hint how to work around this?

 

Thanks in advance,

 

jochen

 

What kind of action are you using for this? A keyword attached to what?

[rice.shawn]

So, run the workflow and then open a new terminal window.

 

Type `ps aux|grep mvim| grep -v grep`.

 

That should show you whether or not the Alfred process is still running; if it is, then Alfred probably won't launch another one because it's still waiting for the first one to finish. (This depends on how you set it up).

 

If this actually is the problem, then you can fix it by forking and disowning the process so that Alfred feels like his job is done and will move on to the next.

[nesono]

 

Type `ps aux|grep mvim| grep -v grep`.

 

That should show you whether or not the Alfred process is still running; if it is, then Alfred probably won't launch another one because it's still waiting for the first one to finish. (This depends on how you set it up).

 

If this actually is the problem, then you can fix it by forking and disowning the process so that Alfred feels like his job is done and will move on to the next.

 

Thanks for the answers! I am using a keyword with an argument to fire the script off.

ps did list only the macvim jobs (mvim is actually a shell script that fires off an Application.

Will mvim be actually part of the (workflow) executable when run? I though it all runs within

the context of Alfred.

 

Anyhow, I tried to disown the process nevertheless but it did not help.

I just added some logging (date print outs to the script) and it shows that the

workflow is not being called until the current mvim window has been closed.

 

I changed MVIM to be "open -a MacVim" (even though that does not what I want)

and the workflow ran every time I fired.

 

So the problem must be somewhere in the guts of the mvim script that comes

with home brew. Needs some further investigation though. Will keep you posted

and would be happy to hear new comments/ideas in the meantime

[deanishe]

It's not a problem with the mvim script, it's due to the way Alfred runs scripts. Alfred (correctly) doesn't consider a script finished while its STDOUT and/or STDERR are still open (i.e. there may still be some output to come), so to get Alfred to consider a backgrounded process finished, the process has to disconnect from or close STDOUT & STDERR:
 

MVIM=/usr/local/bin/mvim

case "{query}" in
  "h")
    cd ~/ && $MVIM > /dev/null 2>&1
  ;;
  "d")
    cd ~/Downloads && $MVIM > /dev/null 2>&1
  ;;
  *)
    echo "unknown directory specified"
  ;;
esac

[vitor]

Building (stylistically) on deanishe’s answer, you can shorten > /dev/null 2>&1 a bit by using &> /dev/null. As in

MVIM=/usr/local/bin/mvim

case "{query}" in
  "h")
    cd ~/ && $MVIM &> /dev/null
  ;;
  "d")
    cd ~/Downloads && $MVIM &> /dev/null
  ;;
  *)
    echo "unknown directory specified"
  ;;
esac

[deanishe]

That's much nicer. I can never remember where the & goes in the longer form…

[nesono]

Thanks guys, especially deanishe for pointing the file descriptor issue out. That was what I was missing.

For the record: I also had to modify the path variable to the ack script to use ack.vim - in case anyone uses

custom packages that need to invoke binaries from within vim...