Back

@swordgeek

@nixCraft

So you're saying we should all be pressing kkkkk instead of to find where we typed ls?

@benlindsay @nixCraft Nah, you hit /ls.

(Yes, ctrl-R does the same in emacs mode.)

I guess what confuses me is that I find very few people who actually use emacs these days - admins use vi(m) and developers use an IDE and vi(m) in the terminal. So why do we default to command-line in emacs mode?

@swordgeek
@nixCraft

Ohhhh interesting I never thought of that! I'm a (kind of ex-) vim user and I have set editing-mode vi in my .inputrc but rarely use vim features in the command line. Didn't realize vim style search worked there! Gonna give that a try

@benlindsay @nixCraft Yeah, it's pretty great. You get full vi-style editing; search, movement commands, editing, pretty much the works.

I've been using it since I switched from csh to ksh (ksh88 on Solaris), back in the mid-'90s, then carried it forward to bash and on Macs now, zsh.

@natanielf I always make a typo and then hit backspace and type again and then it finds even older irrelevant stuff and have to hit Ctrl-C and start over again.

Holding down that up-arrow is much easier!

@nixCraft

@hvangalen @natanielf @nixCraft I have a feeling that allows you add more parameters to the search, especially when you have lots of similar lines in your history like so:

ping host1
ssh host1
telnet host1 80
ping host2
ssh host2
...
telnet host5 80

Searching for "ssh" might not give you the right one out 5 results. If you clear it with backspace and type "host2" it returns results with both "ssh" and "host2". I still need to confirm this.
Anyway, plenty more tips here:
https://www.digitalocean.com/community/tutorials/how-to-use-bash-history-commands-and-expansions-on-a-linux-vps

@georgeeyong I scanned that page and see things that I already knew.

HOWEVER I was totally unaware that one can hit Ctrl-R more than once to iterate all matches!

THAT IS A GAME CHANGER

@natanielf @nixCraft

@ljrk @Laukidh @ChurchHatesTucker @nixCraft @atuin that's brings way back. In ~/.local/bin I had wrapper shell scripts that would start the appropriate (custom) binaries based on the architecture and processor, so I could scp my ~/.local to the box and not need to worry about the local tools having the correct versions and run with the version I liked best. I had a cross compiler in my workflow to ensure that all the binaries stayed up to date with the latest versions of whatever tools I was working with.

My favourite one was after Solaris 7 came out and everyone was in our company was in love with pkill and pgrep, which wasn't available on the Linux versions we used at the time, I wrote a custom version that I would drag with me everywhere.

We had an assortment of devices we looked after, various flavour of Solaris, Linux, BSD and DEC UNIX.

@webhat @Laukidh @ChurchHatesTucker @nixCraft @atuin Awesome :D

Sounds like POSIX `getconf` as used in Solaris for backwards compatibility back to stone ages for importing `/usr/xpg4` or whatever was required into `$PATH`.

I also implemented a more featureful `head` and `tail` in `awk` for similar reasons. IIRC it was actually quite pleasant, surprisingly performant and of course architecture independent.

@Laukidh @webhat @ChurchHatesTucker @nixCraft @atuin Awesome! The only relevant script I currently have is a wrapper around `podman` that detects whether I'm currently in a toolbx
container or not and either spawns the binary on the host or directly... – gone are the times of weird quirks, although I still don't use bashisms in my scripts :'-)