denisidoro Posted May 7, 2020 Share Posted May 7, 2020 navi An interactive cheatsheet tool for the command-line and Alfred.Download link and instructions: https://github.com/denisidoro/navi navi allows you to browse through cheatsheets (that you may write yourself or download from maintainers) and execute commands. Argument suggestions are prompted to you. Pros it will make you type less; it will spare you from knowing CLIs by heart; it will teach you new one-liners. It uses fzf, skim, or Alfred under the hood and it can be either used as a command or as a shell widget (à la Ctrl-R). This project was originally intended to be used in the terminal but I found out that it was quicker to call most actions via Alfred instead. yellowsoar and deanishe 2 Link to comment
deanishe Posted May 7, 2020 Share Posted May 7, 2020 This is a really good idea, but I had to edit the workflow quite a bit to make it useable. The workflow is fundamentally broken on my machine (navi: command not found) because I don't use bash. Sourcing ~/.bashrc does nothing. This is probably true of all new Macs (as well as many older ones) because zsh is now the default shell. So I replaced all calls to navi with $navi and set a workflow variable set to the full path to navi instead. I've also replaced the Terminal Command with a Copy to Clipboard action. When I'm looking up a shell command, 99% of the time, I want to paste it into my current shell (and possibly edit it before running), not start a new shell and run the command there unchanged. I've also added a Snippet Trigger, so I can call the workflow directly from my shell (the Alfred interface is nicer than the fzf one). Acidham 1 Link to comment
denisidoro Posted May 7, 2020 Author Share Posted May 7, 2020 @deanishe, thanks for the comments! 1) the `~/.bashrc` loading is to add binaries installed via Homebrew to your $PATH (assuming that you used Homebrew to install navi + Homebrew is configured for your bash session) 2) would you mind opening a PR? I'll gladly accept any improvements 3) given your use case, you'll probably be more interested in the shell widget: https://github.com/denisidoro/navi#shell-widget Link to comment
vitor Posted May 7, 2020 Share Posted May 7, 2020 If you’re the author of the original tool, why don’t you just bundle it in the Workflow? Link to comment
denisidoro Posted May 7, 2020 Author Share Posted May 7, 2020 What do you mean, @vitor? To bundle the `navi` binary with the workflow? That would work, but navi heavily relies on env vars and stuff, so you probably want to source `~/.bashrc` in both cases. And if you're going to source `~/.bashrc` then it's best to have navi installed globally because that will work in the terminal as well. Does that make sense? Link to comment
Acidham Posted May 7, 2020 Share Posted May 7, 2020 5 hours ago, deanishe said: This is a really good idea, but I had to edit the workflow quite a bit to make it useable. @deanishe did you PR the changes or can you share the WF with your mods? Link to comment
deanishe Posted May 7, 2020 Share Posted May 7, 2020 (edited) 4 hours ago, denisidoro said: 1) the `~/.bashrc` loading is to add binaries installed via Homebrew to your $PATH (assuming that you used Homebrew to install navi + Homebrew is configured for your bash session) I understand what your goal was. I was explaining why it doesn’t work and how I fixed it. As far as I can tell (please correct me if I'm wrong), the workflow doesn’t need to actually alter $PATH, it just needs to know where the navi binary is, in which case, sourcing shell dotfiles is overkill and also not guaranteed to work. Use /usr/local/bin/navi instead of just calling navi, or if you want to be friendly to users who didn't install it via Homebrew, add a workflow variable and use $navi. Sourcing dotfiles in a workflow if you don’t absolutely need to is generally a bad idea. You don’t know which shell the user uses, so there's a good chance you’ll source the wrong file. Some users will add [ -z "$PS1" ] && return at the top of their shell’s config file so it does nothing in non-interactive contexts, and others will include so much stuff in there that it takes a really long time to load, massively slowing down your workflow. 4 hours ago, denisidoro said: 2) would you mind opening a PR? I'll gladly accept any improvements I'll submit a PR that replaces the bashrc sourcing tomorrow. 4 hours ago, denisidoro said: 3) given your use case, you'll probably be more interested in the shell widget I have the shell widget, which outputs commands in the way I prefer, but like you, I also prefer the Alfred interface. So I changed my copy of the workflow to insert the command at the current cursor, like the shell widget does. Edited May 7, 2020 by deanishe Link to comment
deanishe Posted May 7, 2020 Share Posted May 7, 2020 (edited) 17 minutes ago, Acidham said: did you PR the changes or can you share the WF with your mods? Not yet. I’ll PR the changes for setting the right path to navi tomorrow. That’s a pure fix and doesn’t change the way the workflow actually behaves. I don't know whether @denisidoro is interested in changing the behaviour of the workflow (copying/pasting the command instead of or as an alternative to running it in a new shell). And if he is, the proper way to do it would be to make all the options available via modifiers, which I haven't done. That might require changing the Rust code, and Rust is strictly a read-only language for me. Edited May 7, 2020 by deanishe Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now