felixhageloh / uebersicht

ˈyːbɐˌzɪçt

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add `localnode` to `run`'s $PATH

MynockSpit opened this issue · comments

Adding localnode to the spawned process's $PATH would allow us to write resilient "server-side" node scripts. This is currently possible, but you have to explicitly reference local node in the shebang.

To avoid the XY problem, the context here is that I want my widget to be able to prompt Notifications. You can do that with osascript/bash, but you can't provide a callback (i.e. what happens when you click them). However, you can do this with a node script (using node-notifier). So ideally, I'd be able to write a node script uses it. But to trigger it, I need to use run. run's spawned instance doesn't know where to find node (b/c it's not on the $PATH), so I need to find it myself.

My script ended up looking like this:

// my-script.js
#!/usr/bin/env /Applications/Übersicht.app/Contents/Resources/localnode

... node code

You make sure it's marked as executable (chmod +x ./myscript.js) trigger it by doing run(./my-script.js) and it works! But it's not ideal. There are three totally optional ways to make it more ideal, and I wanted to get input to see what your opinions are.

  1. Make using localnode easier (e.g. add localnode to the path, so your hashbang can be this: #!/usr/bin/env localnode). This means the amount of changes would be pretty low -- a several line change to the command_server.coffee to set the PATH, and that the server can set the PATH dynamically, so that no matter where the app is, the PATH is correct.
  2. Provide a whole new route to trigger node scripts. (e.g. node('./myscript.js')). This would let us remove the quirks of needing to write an executable node file entirely, but the changes would be more invasive
  3. Provide a whole new route for triggering notifications. Most of the time you shell out to run, you probably don't want node, so maybe users would use a notification() trigger more?

I favor (1), mainly b/c of its simplicity to write and its power. (2) is better, but would take more thought and is less extensible (if, say, we add something else to the path, we'd probably want to make a new route too.)

Thoughts?