Jump to content

bash script workflow artificially serialized


Recommended Posts

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

Link to comment

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?

Link to comment

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.

Link to comment

 

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 :)

Link to comment

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
Link to comment
  • 2 weeks later...

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...

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...