Jump to content
nesono

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

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

 

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...