Use $SUDO_ASKPASS if defined. Allows non-terminal sudo password prompts.
The sudo program checks this env var and uses it, but only if --askpass was given at the command line, or if it thinks there is no terminal. But the terminal detection is unreliable, so give it --askpass if there is an askpass program defined in the environment.
To try it, simply export SUDO_ASKPASS=/usr/bin/ssh-askpass before running tomb.
For me personally, this makes it possible to have a hotkey to run "pass" and "pass tomb" related commands. Without this patch, invoking via hotkey causes my window manager to lock up while waiting for a password on the VT where Xorg was started... and since it's locked up, I can't change to the VT to enter the data it's waiting for. So I have to log in via ssh from another host to recover it.
So, instead of locking up... now it can use a GUI askpass program.
Make sense! I had some doubts about the use of local for the askpass var inside a conditional branch, but it seems the scope is the whole function so should be OK. Thanks for your contribution!
Use $SUDO_ASKPASS if defined. Allows non-terminal sudo password prompts.
The sudo program checks this env var and uses it, but only if --askpass was given at the command line, or if it thinks there is no terminal. But the terminal detection is unreliable, so give it --askpass if there is an askpass program defined in the environment.
To try it, simply
export SUDO_ASKPASS=/usr/bin/ssh-askpass
before running tomb.For me personally, this makes it possible to have a hotkey to run "pass" and "pass tomb" related commands. Without this patch, invoking via hotkey causes my window manager to lock up while waiting for a password on the VT where Xorg was started... and since it's locked up, I can't change to the VT to enter the data it's waiting for. So I have to log in via ssh from another host to recover it.
So, instead of locking up... now it can use a GUI askpass program.