Unsure why this doesn't work
Closed this issue · 9 comments
$ oathtool --totp -b "SECRET_KEY" | pbcopy
$ pbpaste
123456
But using the same with icanhazshortcut doesn't seem to work. Any idea why this is? and how to fix it?
Thanks for creating this nifty tool! Super useful 👍
First of all make sure that you selected a shell which support piping (such as bash). You can do that under "Preferences" tab.
If that's not the case then i bet that this is a $PATH problem. Try to provide a full path to oathtool binary, you can find it by calling which oathtool in your terminal.
Whoa... Yes, it was a $PATH problem after all. Giving a full path worked! Is there a way to make ichs use the PATH set for a shell?
Closing this issue!
The shell you selected should load its configuration file every time it runs.
You can probably just select a shell that you use in your terminal (echo $SHELL should help with that). Otherwise, you should manually set the $PATH variable in your selected shell config (~/.bashrc for bash, ~/.zshrc for zsh, etc), like that:
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
Actually your question made me think that maybe i should introduce some sort of a "test run" functionality and show the command output. That should make everything much easier.
@navinpai starting from version 0.8.0 you can perform a test run from shortcut creation/editing dialog.
It works perfectly! And the new error message is so much more helpful
Thanks for the quick turnaround! 👍
Can you support .bash_profile? It's standard on OS X.
I have $HOME/bin in my $PATH, and set bash as the shell but I still have to type the full path to a command residing in $HOME/bin, in ICanHazShortcut's action field (eg. ~/bin/play).
> echo $PATH
> /Users/soulitude/bin:/usr/local/opt/openssl/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
It looks like it has something to do with interactive and non-interactive mode of the shell.
Running bash with -l makes it load .bash_profile. I'm not sure what is the best way to solve it, should i just provide a way to define shell arguments?
The usual convention is that .bash_profile will be executed at login shells, i.e. interactive shells where you login with your user name and password at the beginning. When you ssh into a remote host, it will ask you for user name and password (or some other authentication) to log in, so it is a login shell.
When you open a terminal application, it does not ask for login. You will just get a command prompt. In other versions of Unix or Linux, this will not run the .bash_profile but a different file .bashrc. The underlying idea is that the .bash_profile should be run only once when you login, and the .bashrc for every new interactive shell.
However, Terminal.app on macOS, does not follow this convention. When Terminal.app opens a new window, it will run .bash_profile. Not, as users familiar with other Unix systems would expect, .bashrc.
source: https://scriptingosx.com/2017/04/about-bash_profile-and-bashrc-on-macos/
Terminal.app always reads .bash_profile by default, be it login or interactive shell so, I assumed it to be default on OS X.
There are 3 options:
- Shell arguments would be a flexible option for all users.
- Provide a text box as the
Actionfield to actually be able to enter a path to a script or an actual multiline script. - Forget about it, I'll just enter the full path, not too big of an issue.
BTW, other apps with the same functionality of ICHS are also incapable of reading my $PATH. Shortcuts and Keyboard Maestro, at least provide option 2 so I can use:
#!/bin/bash
# /usr/local/bin is added when the script has dependencies there
export PATH=$HOME/bin:/usr/local/bin:$PATH
play
Thanks, that's some useful info here!
3 is not an option since you're the second person who stumbled upon this and i agree that this is confusing. Also, in-app help actually states the opposite :(
I think i'll go with the 1st one. I tried to hardcode it and it works totally fine with -l.
If you want to add anything on that topic please move to #26