The secret weapon of Bash power users | Hacker News Reader

The secret weapon of Bash power users

opensource.net

22 pointsBrajeshwar41 comments

When dealing with bash history, I find that too many people are still unaware of C-r (Ctrl+R or Command+R): press it and start typing unique bits of your past commands. If multiple commands match, cycle through them with repeated C-r presses.

The usual reaction is :mindblown: :)

That would be the emacs style key mappings, specifically mirroring isearch-backwards. I have no idea what the vim mapping for that would be.

And even more don't know how great FZF (Fuzzy Finder) is. When properly setup, Ctrl-R now shows a fuzzy search of your command history.

this feature has pretty much eliminated the use of aliases for me. So efficient

No longer do I need obscure abbreviated aliases for my common commands

I just type ctrl-r and enough characters of the command I need until the one I need bubbles up

It’s control+r on macOS too, one of the nicest things about macOS is that command and control are separate so they don’t interfere. So for example control+c in Terminal.app sends SIGINT, and command+c copies and there’s no ambiguity.

Thanks for the correction for Mac!

But honestly, one of the *worst* things about Macs is that Command and Control are separate, and there are no good keys to remap them to (there is only one Caps Lock), so you have to contort your fingers for an oft used combination.

But if you have autocomplete suggestions enabled in your modern shell (Zsh, Fish, Nushell), you don't even have to press C-r. Just type and it'll complete for you.

Even ignoring that those might not be built-in (at least for zsh), I can't imagine this matching unique part in the middle of a command from history without explicit action (that would be terrible UX).

And when you have multiple similar commands in your history that only differ somewhere in the middle, you don't want completion, you want searching.

For those cases you can type until it autocompletes one of those commands, then press the up arrow key to cycle through the variations of that match. I don't know about zsh, but it's the default for fish and nushell.

The example I have top of mind is something like

  aws codeartifact login --tool pip ...

and

  aws codeartifact login --tool npm ...

I can simply do "C-r pip" to get to the first and "C-r npm" to get to the second (or cycle through any other matches, or if I frequently had a few, maybe do "C-r tool npm"): your suggestion sounds much worse in comparison.

BTW emacs commands are the default in readline, thus in bash. They are ubiquitous in Mac text fields and buffers as well. Google docs too.

Those commands are so deeply wired in my brain (from contionuous use since the 70s) that I dodn't even notice when a program supports them -- it's when a program doesn't that I notice.

There's an option in gnome keyboard settings or gnome tweaks to enable the same in GNOME apps.. Though it's a bit more limited but ctrl-a ctrl-e etc are working!

Yup, I swear by vi mode

You can also use

    set -o vi

in your bashrc to enable it. I've used it for probably ~18 years now.

It also works with https://www.oilshell.org/ since we use GNU readline. Just 'set -o vi' in ~/.config/oils/oshrc

I am an ash user. ("Power user" is a term invented for users of TUI/GUI software.) I use ash as an interactive shell as well as a scripting shell. I prefer vi mode and libedit rather than readline. In ash, set -o vi is not necessary. set -V will do.

Offtopic, but I know from your HN comments that you're also a NetBSD user, working in text mode. Would you mind describing your NetBSD setup a bit? What kind of kernel modifications have you done, and IIRC you also use RAM disk, etc? Thanks if you take the time. I find your comments here on HN very interesting.

When I first started using NetBSD, audio did not work on the particular computer I was using. I made a simple edit to a kernel file and it worked. I no longer try to use NetBSD for audio; I'm interested in networking. I have learned to be patient about hardware support. As such, I am not making kernel modifications.

I always use a memory disk inserted with mdsetimage. Only some small edits to kernel configuration files.

https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arc...

I always boot from USB stick where possible. On RPi I boot from SD card.

I make custom userlands for the memory disk using crunchgen and makefs. Often I'll add a static tinysshd.

In the beginning, many years ago, I learned how to "bootstrap" a "diskless" system comprising what I need day-to-day in a userland without having to compile anything. Never seen this approach in any published tutorial. Basically, I used an INSTALL kernel and substituted the /rescue crunched binary for the limited "install" one.

I will either put a "complete" userland, i.e., with compiler, etc., e.g., as a cloop2 compressed image file on the USB stick, then mount it after boot, or I will chroot to an external drive containing a complete userland.

Where possible I rely solely on the computer's RAM as writable "disk" space.

There is never any data stored on the USB stick or SD card other than configuration files. The OS is read-only, immutable. The stick or card can be removed after boot.

Many thanks for replying! I am considering text-only NetBSD setup for an old machine, so your pointers are inspiring and useful. For almost a decade, I have tailored hyper-minimalist RAM-booted systems with Tiny Core Linux [1], a distro essentially built for this kind of use. But I've always been curious whether NetBSD would offer any advantages here, or a different kind of flexibility (and it also has excellent documentation).

Would be great to have a customized Unix that boots just as quickly as e.g. FreeDOS on 10+ year old hardware (in something like two seconds).

Thanks again for sharing your setup!

1: http://tinycorelinux.net/

"But I've always been curious whether NetBSD would offer any advantages here, or a different kind of flexibility (and it also has excellent documentation)."

I may be wrong on this as I have not kept up, but in the past the Linux kernel did not support the multiboot protocol. Whereas NetBSD kernel supports it. For example, I have booted NetBSD kernels using a FreeBSD bootloader. I wanted to be able to boot either NetBSD or FreedBSD kernels from the same USB stick. I liked to put multiple NetBSD kernels on the same stick and wondered about other OS kernels. This was before the container craze.

I think Linux will always be able to boot significantly faster. Although I have never considered NetBSD to boot "slowly". I think using NetBSD is really a matter of personal taste. "Advantages" are subjective. It does have _differences_ when compared to Linux. A coherent userland is obviously one. There are of course fewer cooks in the kitchen. And it is easier to track its development. There is sometimes interesting work like RUMP that was IMHO ahead of its time. There is the notion of "off by default", i.e., the project generally does not assume that the user wants or does not want something enabled/installed. (At least not traditionally.) It is up to the user to prepare and configure their own system. A benefit of this is that it can sometimes help with learning how NetBSD works. IME, Linux is generally quite different. Convenience is always a focus. Assumptions about users' wants and needs are the norm. Learning is generally not a goal.

Linux is obviously a very, very large community. NetBSD is relatively small.

When I look at the pre-packaged options for building custom Linux kernels and userlands, e.g., Buildroot, Yocto, etc., they seem far more complicated to me than using the NetBSD source tree. But I am probably biased.

And here is zsh-vi-mode https://github.com/jeffreytse/zsh-vi-mode

One of the best things I did and forgot was piping either current line or selection into an existing terminal session. Vim compact <<< vim as command buffer.

I used to work with someone who was in the habit of setting root's shell to vi-mode. if you're reading this A____, fuck you.

This sounds hilarious. I might have to start a campaign to take over as many internet facing boxes as possible and the only change I'll do is to set the root shell to vi-mode.

people who do that sort of thing want shooting

It's not a secret, and it's a feature available to all modern shells, not just BASH.

Can also put

set -o vi

in your .bashrc or .profile

cli is a lost art now

You’re not wrong. Asking someone to send their public ssh key then login to a shell over ssh works as well as FizzBuzz to identify the newbs and posers.

i got canned because i refused to install cpanel on our server for a fiverr dev the founder hired.

That hurts.

I tried to do the right thing. In the end that company was going to fail anyway

I have had “freelancers” ask for cPanel too. Sucks to get fired for that but you did the right thing.

Is cpanel that bad?

I mean, yeah, if you are a professional it’s a bad look to have to depend on a web GUI

It’s like being a valet and not being able to operate a manual transmission

exactly

Well yes, that's embarrassing for them, but I wouldn't consider it grounds for a hard refusal. Hiring cheap help is potentially decent business practice for low-stakes work. Refusal seems more appropriate if there was real damage from the software that raised it to an issue of professional ethics...

If they can't use the command line they suck. period.

I can't agree. Would you say the same for someone who was a pure designer? I doubt it. Would it suddenly become true if they picked up a little bit of admin-by-GUI on the side? Again, doubt it. But then how much technical skill can you have before the command-line-or-they-suck clause kicks in? It may have been true for the particular guy your previous boss hired, but it's unsupportable as a generalization.

Giving root permissions to a complex and opaque web GUI with a history of security problems seems bad.

While it’s possible to correctly secure cPanel, the skills needed to do that are the same as those needed to manage the server without it.

I would have walked out as well.

I've been using shells since 1989, and I still rarely remember ssh-copy-id exists, I guess that makes me a poser :(

TL;DR: vi keybindings are the secret weapon.

Reply on news.ycombinator.com