Open schinckel opened 4 years ago
(Ultimately, it would be amazing if you could have notifications appear on my local machine when I trigger them in a script on a remote machine, but I'm guessing that's way out of scope)
Hey, I'm running into this issue as well - have you found any workaround aside from not using terminal-notifier?
Not sure if this is still unsolved for folks...
In my scripts that generate notifications, I populate a variable when connected remotely, then filter on it before notification.
# set SESSION_TYPE if connected remotely
if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ]; then
SESSION_TYPE=remote/ssh
else
case $(ps -o comm= -p "$PPID") in
sshd|*/sshd) SESSION_TYPE=remote/ssh;;
esac
fi
[[ -z "$SESSION_TYPE" ]] && echo "non-ssh session - trigger notification"
Please check everything that applies to your issue:
To help us debug your issue please include:
When you ssh to a Mac that does not have a current UI session (ie, I restarted my Mac before going home from work, and started an ssh session from home), you can't use terminal-notifier as part of a workflow, because it just hangs.
I'm aware that there is "no point" in having a notification, because there is nowhere to view that notification. The problem I have is that the command stops executing, rather than throwing an exception.
I could have a workflow that just ignores the status code of the command, and continues.
In my case, I have a mercurial hook that posts a notification:
update.notifier = (/usr/local/bin/terminal-notifier -title Mercurial -subtitle 'Update successful' -contentImage ~/.mercurial.png -message "Parent revisions(s): $HG_PARENT1 $HG_PARENT2")
However, if I try to chain bash commands:
hg pull upstream && hg up && hg push --rev default
This fails to execute, because it stops when attempting to post the notification: and requires a Ctrl-C to regain control of my shell.
I think it should return a suitable error code when it is unable to connect to the session, rather than just print the error and wait: