Bitbar: Issues with "refresh" and "terminal" options

[cjbaar]

This is an extremely handy plugin for OSX. However, I am having some issues getting a few of the options to work. One is the "terminal=true/false" option. If I set it to false, to keep windows from cropping up, scripts never executed. I have tried several different executables, and tried supplying the full path, but nothing ever seems to run when using this option.
EXAMPLE: echo "Reset Wi-fi | bash='sudo /usr/local/bin/reset-wifi; exit' terminal=false"

The other option is refresh=true. It would be nice to have other options for refreshing, since some of my scripts (like connecting to a VPN) do not complete immediately. However, even for those scripts that do exit quickly, the refresh never seems to occur.
EXAMPLE: echo "Proxy On | bash='pkill -9 -f 127.0.0.1:12345; exit' refresh=true"

[iosdeveloper]

You're using the bash parameter wrong. It breaks when using terminal=false. Because you are using quite complex commands, I suggest you pass the path to your plugin to bash and an argument to param1 that you handle on top of your script, then exit. Check matryer/bitbar-plugins for examples on how to do this.

[cjbaar]

I'm not sure what is complex about them. Each line is only command. I just added the "exit" to keep from having a bunch of windows piling up, which is what I was hoping "terminal=false" would solve. Does this method help with the "refresh" issue as well? Thanks.

[iosdeveloper]

Well, bash expects a path to an executable and not the full command with arguments. Those have to be passed separately to param1 and so on if you don't want to use my suggestion.

[cjbaar]

I have changed the using bash='$0" param1=func, and added the appropriate logic at the top of the script. It still fails to run when terminal=false. What is required to prevent new windows from spawning every time a command runs? I do not see any other information on using this in the documentation.

[mm2270]

@cjbaar The process I use in my plugins looks something like the below, as a bare bones example

#!/bin/bash

## Two functions that can be called based on which param1 string gets passed back to the script
function doSomeFunction ()
{
<commands all go here that you want to run for this function>
}

function doSomeOtherFunction ()
{
<commands all go here that you want to run for this function>
}

## This case statement captures what was passed to param1 and decides which function to call
case "$1" in
    doSomeFunction)
    doSomeFunction
    ;;
    doSomeOtherFunction)
    doSomeOtherFunction
    ;;
    *)
    exit
esac

## Simple example of 2 menu items, which will run the script with the param1 string
echo "Menu item name 1| terminal=false bash=$0 param1=doSomeFunction"
echo "Menu item name 2| terminal=false bash=$0 param1=doSomeOtherFunction"

When either of the menus are selected, the $0 tells bash to run the same script that generates the menu, but inject param1 with the associated variable. It (re) runs the script and the case statement captures the param1 string passed to it (as $1) and in turn runs the embedded function, which runs whatever commands you want to run within it. Within the functions you can get about as complex as you want, so you're not limited to including it all in one line.

In practice, its usually a little more complicated than just the above, but it can be achieved this way, rather than sending an entire full command to to the bash function. It just works more reliably that way since you're really just telling it to run the script itself with special parameters instead of generating the menu. The terminal=false always works for me to prevent seeing Terminal windows.

The other advantage to doing this way is that if you need to call that same command or series of commands in more than one location, it's easy to do by simply passing the correct parameter string to the bash command. It keeps it all in one place for editing in case you have to edit the actual commands later.

Hope that helps.

[cjbaar]

Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.

[oleander]

The bash key requires an absolute path to a binary on your system when using terminal=false. Functions doesn't works.

On my phone right now so can't link to any prior discussions. Try searching for it here in the issues. I've explained why this is the case a few times. I also fixed it in my PR.

8 sep. 2017 kl. 03:21 skrev cjbaar [e-mail]:

Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[oleander]

Sorry, missed $0 in the example. Strange that it doesn't work as $0 should be expanded into an absolute path.

8 sep. 2017 kl. 03:21 skrev cjbaar [e-mail]:

Thanks @mm2270. I understand the concept of running via $0 from the examples, and have implemented my scripts as such. However, they still do not execute with terminal=false, so I end up launching windows all the time. Nor does refresh=true have any effect.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[jimniels]

FWIW I was trying to run the rm command silently and terminal=false wasn't working. After reading the above comment, I realized I was using it wrong:

I suggest you pass the path to your plugin to bash and an argument to param1

Here’s what I was doing that didn't work:

Refresh State | terminal=false bash="rm -f /path/to/file"

I had to point to the entire executable and then use params.

Refresh State | terminal=false bash=/bin/rm param1=-f param2=/path/to/file

While the README points this out, for some reason I didn't think it applied to "system" commands like rm. But it does. Shows how much I know.

Thanks to all for the feedback here.

[frakman1]

Is there a way to refresh the script from within the script without having to click on an item using the | bash=xxx syntax?