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.
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.
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.
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!
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.
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).
"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.
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.
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.
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.
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...
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.
The usual reaction is :mindblown: :)