One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time.
In zsh this is configured with
bindkey "^[OA" up-line-or-beginning-search # Up
bindkey "^[OB" down-line-or-beginning-search # Down
Heh. I've done this since forever, but I use PgUp and PgDn so I can retain the original meaning of the up arrow key.
Once you start using CTRL+r, you may find that you never reach for up arrow again.
I'm familiar with ctrl-r, but I still very much like the up-arrow behavior described by that commenter.
There is a difference, I believe. Doesn't Ctrl+r do a substring search instead?
And once you want to one-up this look into fzf.
And once you get tired of fzf and want something better, you reach for https://atuin.sh.
Completely transformed all of my workflows
From the atuin.sh website
> Sync your shell history to all of your machines
I think of my shell history as very machine specific. Can you give some insights on how you benefit from history sync? If you use it.
Same, I find shared history not very useful.
However what I do find useful is eternal history. It's doable with some .bashrc hacks, and slow because it's file based on every command, but:
- never delete history
- associate history with a session token
- set separate tokens in each screen, tmux, whatever session
- sort such that backward search (ctrl-R) hits current session history first, and the rest second
Like half my corporate brain is in a 11M history file at this point, going back years.
What I would love is to integrate this into the shell better so it's using sqlite or similar so it doesn't feel "sluggish." But even now the pain is worth the prize.
That feature is entirely optional and disabled by default. Atuin stores your shell history locally in a sqlite db regardless of whether you choose to sync it. I thought fzf was fast, but atuin makes it look slow by comparison.
One thing I do is configure my keyboard so that "modifier+{ijkl}" mimicks the inverted T arrows key cluster. So there's never a need for me to reach for the arrow keys. And {ijk} makes more sense than vi's {hjkl} and is faster/more logical/less key fingers travel. The nice thing is: as I do this at the keyboard level, this works in every single map. "modifier" in my case is "an easily reachable key in a natural hand position on which my left thumb is always resting" but YMMV.
I set that up years ago and it works in every app: it's gorgeous. Heck, I'm using it while editing this very message for example.
And of course it composes with SHIFT too: it's basically arrow keys, except at the fingers' natural positions.
> life-changing
For further life-changing experience... add aliases to .bash_aliases
alias gph='history | grep --colour -i '
alias gpc='grep --colour -Hin '
#if gnu time is installed
alias timef='/usr/bin/time -f "tm %E , cpu %P , mem %M" '
I've got many like these I copied from various people over the years.
One I came up and that I use all the time:
alias wl='wc -l'
I use it so much I sometimes forget it's not stock.
Did this many years ago (but with bash) -- life changing is an apt way of saying it.
Here's the Bash commands for this in case anyone is looking for them
Using the terminal becomes much more cozy and comfortable after I activate vim-mode.
A mistake 3 words earlier? No problem: <esc>3bcw and I'm good to go.
Want to delete the whole thing? Even easier: <esc>cc
I can even use <esc>v to open the command inside a fully-fledged (neo)vim instance for more complex rework.
If you use (neo)vim already, this is the best way to go as there are no new shortcuts to learn and memorize.
This reminds me of an excerpt from an old Emacs manual:
. . . if you forget which commands deal with windows, just type @b[ESC-?]@t[window]@b[ESC].
This weird command is presented with such a benevolent innocence as if it's the simplest thing in the world.
I think the better advice for command-line editing would be to set up the mouse.
> This weird command is presented with such a benevolent innocence as if it's the simplest thing in the world.
I think it's a question of context and familiarity. To a vim user, like me and, I assume, ahmedfromtunis, their examples do indeed seem simple and natural. Presumably, to an emacs user, the example you quote (if it's quoted literally—I don't use emacs and can't even tell) is just as natural, and assuming some comfort with emacs is presumably OK in a manual for the software!
> assuming some comfort with emacs is presumably OK in a manual for the software!
How do you get familiar with the software, if the manual expects you to be an expert in it already?
By reading introductory material.
Not sure if it did at the time, but today emacs comes with a tutorial. You’re not expected to learn it by starting on page 1 of the manual.
I've been a (n)vim user for 20+ years now, but I hate vi-mode in the shell. However if I feel that I need to do a complex command, I just do ctrl-x+e to open up in neovim (with EDITOR=nvim set). I find it a good middle ground.
It’s strange. I have heard this from lots of others too. I think I am an anomaly here. I can’t live without shell vi mode
I'm the same and in my opinion this is the best of both worlds. Taking the time to learn some of the regular (emacs-style) shortcuts is one of the best investments I've ever done. Even just CTRL+Y and the likes.
edit: And of course, CTRL+R, the best time saver of all
Huh. I don’t use vi-mode for more than jumping to the beginning or end of a line, which I like a lot.
It really shines for navigating history. <esc>/ searches history the same way as the editor search function
I'm a vim user but in the shell I use Ctrl-a and Ctrl-e to get to the beginning and end. If I need more editing I use Ctrl-x Ctrl-e to hop into vim.
C-a and C-e are your friend.
You mean, like the “home” and “end” buttons?
Yeah but those are so far away, i have to hunt for them every time
[deleted]
Agree.
I WANT to love it - and if I was only ever working on one, or a small number of systems that I was the only one working on I’d probably do it. I’m ALL about customizing my environment.
However ssh into various servers through the day (some of which are totally ephemeral), and having to code switch my brain back and forth between vim mode and emacs mode in the shell would just slow me down and be infuriating each time I connect to a new box.
I've been a vim/nvim casual user for the past year or two, and I still feel as if I'm slightly less proficient in it for the amount of time that I put into it.
I really need to get around to playing with it more. I just hope that especially now with genAI that it's not too late for learning it further.
> <esc>cc
Doing control+o in insert mode temporarily places you into normal mode so that you can execute one normal-mode command, and then go back to insert mode again--no need to hit 'i' again.
So, instead of '<esc>cc', '<c-o>S'.
The vim version is much easier, if you ask me: 3 strokes, 2 keys and 0 combinations.
The one you suggest however requires 4 strokes (ctrl then o then shift then s), 4 keys (ctrl, o, shift, s) and 2 combinations.
The "cc" sequence deletes the line and switches automatically to insert mode. To forgo the switch, the sequence then becomes "dd".
Maybe I have my bash/readline vi mode configured specially to do this, but if I want to delete the entire line and type a new one (from anywhere in that line), I do something simpler than either of these alternatives:
<esc>S
Esc exits insert mode (of course) and capital S erases the line and puts you in insert mode at column 0 (just like in (n)vim, right?).
Like I said, maybe I configured that? But 'S' is standard vim-stuff... (I'm not able to double check my config at the moment).
[Edit: right after hitting submit I realized that my way is perhaps "arguably" simpler because I do have to hit shift to get capital S. So I'm also hitting three keys...]
<c-o>S is also a vim sequence. The equivalent readline/emacs is <c-e><c-u> or <c-a><c-k>, or just <c-u> or <c-k> if you're already at the end/start of the line.
Oh wow I didn't know about this, thank you. The underlying feature is called "readline vi-mode" for folks who want to search more about it.
<esc>3bcw
What is your keyboard layout? This looks like a crime against humanity on a regular qwerty kb.
I use qwerty and azerty, and in both I never felt typing the sequence was any harder than typing any other regular word. Generally speaking, I prefer sequential "shortcuts" then multikey bindings.
Instead of esc, type ctrl [
Does it help a lot? You've still got a three to type which is a crime, plus some letters, only to move 3 words. My typing skills are not great, but that sounds like an awful lot of work(?)
If I hit CTRL + ARROW_LEFT 3 times, I am done a lot faster I guess. But I am open to learn, do people really use that and achieve the goal significantly faster?
I think it’s a difference in how people think. I can’t remember hotkeys. It just doesn’t compute. But with vim style bindings it’s much closer to writing a sentence. `3`, number of times, `b`, beginning of word, `c`, change, `w`, word. Yea it’s a lot. I cannot explain why it’s simpler for me to learn that than emacs style bindings but it is.
I don’t love vi-mode, but I’ll address your comment.
Many people these days, including yours truly, have caps-lock mapped to ctrl if held or esc if tapped. That’s good ergonomics and worth considering for any tech-savvy person.
Instead of the 3b I would type bbb (because I agree with you that typing numerals is a pain).
So (caps lock)bbbcw isn’t bad. It’s better than it looks, because if you’re a vim user then it’s just so automatic. “cw” feels like one atomic thing, not two keypresses.
And importantly, it doesn’t involve any chords.
The <esc>v has been such a lifesaver at times when having to execute/modify super complex commands!
I love this, from a comment on the article:
He had in his path a script called `\#` that he used to comment out pipe elements like `mycmd1 | \# mycmd2 | mycmd3`. This was how the script was written:
```
#!/bin/sh
cat
```
A similar trick:
#!/bin/sh
$*
that's my `~/bin/noglob` file, so when I call a zsh script from bash that uses `noglob`, it doesn't blow up.
Yes! That one's going in my $PATH. Such a useful use of cat!
What does it provide over
mycmd1 #| mycmd2
Theirs "turns off" one element of a pipeline; yours turns off everything after a certain point.
This will output the stdout of mycmd1:
mycmd1 #| mycmd2 | mycmd3
This will output the stdout of mycmd3:
mycmd1 | \# mycmd2 | mycmd3
Can you explain to me why either of these is useful?
I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.
Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.
Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.
As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
I can imagine a pipeline where intermediate stages have been inserted to have some side effect, like debug logging all data passing through.
CTRL + W usually deletes everything until the previous whitespace, so it would delete the whole '/var/log/nginx/' string in OP's example. Alt + backspace usually deletes until it encounters a non-alphanumeric character.
Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...
In my terminal it's the exact opposite – Alt-Backspace deletes to the previous space, whereas Ctrl-W deletes to the last non-alphanumeric (such as /). I'm using fish shell in an Alacritty terminal.
Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend.
> Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend.
Fun fact: despite having absolutely no menu entry for it, and I believe not even a command available with Ctrl+Shift+P, Vscode supports Ctrl+Shift+T to re-open a closed tab. Discovered out of pure muscle memory.
It's a normal command called "View: Reopen Closed Editor".
Set $WORDCHARS accordingly. In your case, remove / from $WORDCHARS.
Ctrl-Shift-T usually brings that tab right back at least
> Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...
This hurts.
Also, for the shell, if you do C+w, you can "paste" it back using C+y. Assuming you have not removed that configuration.
Not a fan of the LLM-flavoured headings, and the tips seem like a real mixed bag (and it'd be nice to give credit specifically to the readline library where appropriate as opposed to the shell), but there are definitely a few things in here I'll have to play around with.
One thing I dislike about brace expansions is that they don't play nicely with tab completion. I'd rather have easy ways to e.g. duplicate the last token (including escaped/quoted spaces), and delete a filename suffix. And, while I'm on that topic, expand variables and `~` immediately (instead of after pressing enter).
Readline is close enough to being part of bash that it’s not really inaccurate to call these all shell features imo.
As someone who works mostly in WSL and has to use PS occasionally, it really reduces the overhead of the context switch.
One trick I use all the time:
You're typing a long command, then before running it you remember you have to do some stuff first. Instead of Ctrl-C to cancel it, you push it to history in a disabled form.
Prepend the line with # to comment it, run the commented line so it gets added to history, do whatever it is you remembered, then up arrow to retrieve the first command.
$ long_command
<Home, #>
$ #long_command
<Enter>
$ stuff_1
$ stuff_2
<Up arrow a few times>
$ #long_command
<home, del>
$ long_command
In zsh you can bind "push-line-or-edit". In bash and all readline programs, you can approximate it with C-u followed by C-y (i.e. cut and paste). My history is still full of '#' and ':' (csh trauma) prefixed command-lines like you described though ...
Fwiw, in Bash, alt-shift-3 will prepend the current command with # and start a new command.
More generally, it's alt-#. On an ISO (e.g. UK) keyboard layout, shift-3 isn't a hash.
With ctrl+r, if you press it twice, it will autofill the search with whatever you last searched for. pressing it more will go back through the history. Been using that a lot recently when doing docker stuff. ctrl+r, type the container name, keep going until I get the compose build command. ctrl+r, ctrl+r, repeat until the log command. Then I can just mash ctrl+r to get the build and log commands. Ctrl+r is your friend. ctrl+r
Make sure to add fzf + shell integration for maximum Ctrl+r goodness.
Also worth reading the intro to fzf search syntax.
The $ and bang and exact search are neat, but the bit at the bottom as to why `gadd` or `gas` is a better search for `git add something` than something with full words and spaces is a revelation when first using fzf.
I've been using a lot of key combinations and I wasn't aware of these two, and I really think these are awesome additions to handling the console. Thank you for showing me. I've only been using it for 22 years, but I haven't come across these :D
`CTRL + U and CTRL + K
CTRL + W`
What I like about these key combinations is that they are kind of universal. A lot of programs on Linux and Mac support all these key combinations out of the box. And that's like a game changer in productivity, especially jumping to the start or the end of the line or jumping forward and backward per word is making working only with the keyboard so much more nice. And in editors together so AVY, you can even get a faster flow of jumping around.
Regarding history: I have a function in my ZSH config which excludes certain things from the history. Especially things that can break stuff when my sausage fingers CTRL-R the wrong thing
Something like this:
# Prevent certain strings from appearing in the history
# Anything starting with a leading space is ignored
# Anything containing "--force" or "whatever" is ignored
function zshaddhistory() {
emulate -L zsh
if ! [[ "$1" =~ "(^ |--force|whatever)" ]] ; then
print -sr -- "${1%%$'\n'}"
fc -p
else
return 1
fi
}
> cd -: The classic channel-flipper. Perfect for toggling back and forth.
And not only cd. Gotta love 'git checkout -'
The '-' shortcut is weird. In 'git commit -F -', the '-' is actually /dev/stdin.
`-` is the traditional shell way to refer to stdin/stdout (as with your git commit example) but also the traditional way to refer to the last directory you were in (as with git checkout/switch).
You would never pipe the output of a command to `cd` so the `-` shortcut couldn't be helpful to cd as-is. So rather than invent yet another shortcut to memorize for `cd` they reused the existing one which otherwise would be redundant, which I appreciate at least.
But git is simply being consistent with the shell to further reduce the cognitive complexity of reusing shell commands you're used to in analogous git contexts.
- is a pretty standard idiom for using stdin/stdout instead of a named file that you can find in many commands. I don't think it conflicts with the cd/checkout usage though as there the argument normally does not refer to a file so having - mean stdin/stdout doesn't make sense.
[deleted]
What confuses me is that Ctrl+Y "yank" means the opposite of what it means in Vim. Certainly does not help with keeping my sanity.
The utility of $_ is often voided by tab-completion in the subsequent command, at least in bash. You won't know what it contains, which makes it dangerous, unless you first check it in a way that also carries it forwards:
printf %s\\n "$_"
There's one thing you need to only think about once, and has the potential to save you a ton of time: profile your ZSH startup time!
Stuff like NVM or Oh My ZSH will add a few seconds to your shell startup time.
I can recommend powerlevel10k with instant prompt enabled.
if you care about perf, fnm is better/faster/cleaner than nvm. (also, mise is able to manage "all the things", not just node)
IME omzsh slowness usu relates to overloading it w plugins, which I've never found a need for...
My favourite QoL improvement to any shell I use is to improve the history function(Ctlr+R)I personally like https://github.com/cantino/mcfly
Maybe not a shell trick per-se but I have been a very big fan of zoxide. It can jump around your common directories. If you have a ~/workspace/projects and you are anywhere and type `cd projects` it will take you to that directory. I never realized how much I got hooked onto it, until I used a system without it.
I'd advise against using sudo !! though since it adds the command to history and then it's very easy to accidentally trigger, running some undesired command as root without any prior confirmation. IMO pressing up, Ctrl-A and typing "sudo " isn't much longer but saves you from running unknown commands as root by accident
i never found !! useful at all when i can just use up arrow to get the entry i want. it becomes more interesting when you can recall older commands, but then too i prefer search because i want to verify what command i am going to run.
and i only use sudo to open a root shell. never to run anything directly. i don't want normal and root commands mixed in the same history.
i could keep sudo commands out of the history, but then i don't have any history for stuff done as root.
with tmux i can switch terminals easily, so i am also not tempted to run things as root that i shouldn't despite having a root shell open.
> i want to verify what command i am going to run.
shopt -s histverify
shopt -s histreedit
i dont know why they are not the default.
Prepend your command with a space and now your command is not saved in the history.
That depends on the shell configuration.
On bash, you can achieve this by setting HISTCONTROL=ignorespace but that's not the default.
I have a bash key binding, Ctrl+Y, that prepends sudo to the current command and submits it. I also don't use sudo-rs. No one has died yet.
Decades ago, i used a small dns host. I wanted to switch a personal site and they just couldn't get the final step of the transfer to work. A ton of "try now" emails spanning several weeks.
Then one day, I was trying to setup MySQL on a personal Linux machine, and it wouldn't let me use my "standard password" for the admin account. I knew I could just use a different one, but I really wanted to know what the problem was. Took a long time, and I don't remember how I figured it out, but I eventually tracked it to the password ending with '!!'.
It took a while to put it together, and I never confirmed with the dns host support it's what fixed the issue but, I changed my password there, tried the transfer again, and it worked without any help from support. I suspect my plaintext password played some part in a script used in the transfer process, and was outputting the previous command in place of the !! I wish I had asked them if that was it, but if it was, they would have to admit to having my plain text password, or lie about it.
set -o vi
<esc> puts you into vi mode at the cli prompt with all the semantics of the editor.
These carpal tunnel riddled hands can’t be bothered to reach for ctrl or alt let alone arrow keys.
I didn't know the `ALT + .` trick to repeat the last argument, but what is even more neat (and not mentioned in the article) is that it cycles through your history. At least it does in my shell.
A much larger base for ksh (as a pdksh descendent) is Android. OpenBSD is a tiny community in comparison, although Android has acquired code directly from OpenBSD, notably the C library.
The vi editing mode is always present in ksh, but is optional in dash. If present, the POSIX standard requires that "set -o vi" enable this mode, although other methods to enable it are not prohibited (such as inputrc for bash/readline), and as such is a "universal trick."
The article is relying on some Emacs mode, which is not POSIX.
$_ is not POSIX if I remember correctly.
History in vi mode is easier, just escape, then forward slash (or question mark) and the search term (regex?), then either "n" or "N" to search the direction or its reverse.
I've seen a lot of people who don't like vi mode, but its presence is the most deeply standardized.
My header on top of every script
#!/usr/bin/env bash
set -eEuo pipefail
# shellcheck disable=SC2034
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
#######################################################
Wait... Most of my shell scripts have zero unused variables: I prefer to comment them if I may need them later on.
Why do you disable SC2034?
I don't think not having unused variables prevent me from doing things in my scripts!?
I understand if it's a preference but SC2034 is basically one of my biggest timesavers: in my case unused variables are typically a bug. Except, maybe, ANSI coloring variables at the top of the script.
Undo:
Ctrl + _ (Ctrl + underscore)
it did not work for me in putty, so i added ctrl-x + ctrl-u too:
bind '"\C-x\C-u": undo'
bind '"\C-_": undo'
Something that should be mentioned is starting a command with a space doesn't add it to your history in most shells, really useful for one-off commands that you don't want cluttering your history.
Also, increase your `$HISTSIZE` to more than you think you would need, there have been cases where it helped me find some obscure command I ran like 3 years before.
HISTCONTROL=erasedups can also help keeping more obscure commands in your history, at the expense of context around commands.
[deleted]
> The “Works (Almost) Everywhere” Club
> The Backspace Replacements
Also known as "emacs editing mode". Funnily enough, what POSIX mandates is the support for "vi editing mode" which, to my knowledge, almost nobody ever uses. But it's there in most shells, and you can enable it with "set -o vi" in e.g. bash.
Vi mode is also available in Claude code and gemini-cli to give some recent examples, and a bunch of other places you might not expect it, as well the more obvious places where code is written.
Once you get used to it, it is painful to go back.
My biggest complaint about the fish shell is the lack of true vi mode. They attempt to emulate it and it works to some degree, but it's no comparison to readline's implementation.
You can always use Alt-E to open the command line in $EDITOR if you need more powerful commands. I find it better to use readline for small changes and jumping to vim for bigger ones.
Have you tried a recent version? An issue I opened about this years ago was finally closed, they claim it’s fixed now. I haven’t tried the purported fix, though.
And if you set `set editing-mode vi` in ~/.inputrc (readline configuration) you'll have it in even more places.
My favourite trick is either commenting out a whole command or placing a comment at the end of a command to make it easier to find in my persistent history (thanks eliben) [0], using the # character.
I tried this in zsh and it wasn't the default behaviour which immediately made me nope from the shell altogether, among all the other quirks. I've just been using bash for far too long to switch to something different.
Ctrl-r works well at searching character trigrams, which can include space. Trigrams without space work well with auto_resume=substring .
`| sudo tee file` when current user does not have permission to >file
I'm using bash for over 30 years and I still find new things. Nice.
great list but really overboard on the AI generated persona
Another useful "Emergency exit" is CTRL+Z which stops the process and cannot be intercepted.
It's often faster than hitting CTRL+C and waiting for process cleanup, especially when many resources are used. Then you can do e.g. `kill -9 $(jobs -p)` to kill the stopped tasks.
All of the keyboard-driven terminal signals can be intercepted; catching INT (^C) for cleanup is just more common than the others. Only KILL and STOP cannot be caught.
^Z sends TSTP (not STOP, though they have the same default behavior) to suspend; some programs catch this to do terminal state cleanup before re-raising it to accept the suspension. Catching it to do full backout doesn't make as much sense because the program anticipates being resumed.
^\ sends QUIT, which normally causes a core dump and is rarely caught. If you have core dumps disabled (via ulimit -c 0 or other system configuration) then you can often use it as a harder version of ^C; this is how I would tend to get out of ‘sl’ in places where I found it unwantedly installed.
ctrl-z pauses the process, it doesn't terminate. I think of z as in zombie as you can then run fg to bring it back from paused state or as you suggested kill in it for good
[deleted]
Never heard of instant truncate, nor `fc`, nor `Esc .`
Quite a few useful ones
Is it just me, or is it an LLM language? The article tries very hard to be correct but somehow lacks experience.
I've never used the majority of these tricks for decades, except for brace expansion, process substitutions, and complex redirections.
I knew many of these tricks, but learned many new tricks I didn't know and looks very useful (like you can do Ctrl-Y after an Ctrl-U, the 'reset' or 'disown' thing).
Regarding experience, I'm also struck by how many "experienced" engineers are just clueless with the keyboard.
> We’ve all been there.
Close tab.
I ought to migrate away from shell scripting and just keep the shell for interactive use. Unfortunately I have cursed myself by getting competent-ish with P. shell and Bash scripting. Meaning I end up creating maintenance headaches for my future self.
(Echoes of future self: ... so I asked an LLM to migrate my shell scripts to Rust and)
Anyway with the interactive shell stuff. Yeah the I guess Readline features are great. And beyond that I can use the shortcut to open the current line in an editor and get that last mile of interactivity when I want it. I don’t really think I need more than that?
I tried Vim mode in Bash but there didn’t seem to be a mode indicator anywhere. So dropped that.
Edit: I just tested in my Starship.rs terminal: `set -o vi`. Then I got mode indicators. Just with a little lag.
Need to see all the special things you've done this week/whenever?
$ history | grep "\#"
...
Makes for a definite return of sanity ..
I don’t keep history. Any commands I think will be useful, I save it in a script.
omg
>$ CTRL-R<specialthing>
I could kiss you.. this alone is amazing!
!?specialthing?
If you are feeling brave
http://atuin.sh adds a database to store history in and a custom app to use for lookup with added modes to help with searching.
Yes indeed, it is very fun to discover this if you don't know it already, it expands your understanding of your shell life immensely, doesn't it?
What I hate is that if you start a command with a space it is not recorded in the history. This happens often when copy+pasting commands. I know you can turn it off but still ... this drives me mad.
AFAIK that setting is opt-in, at least in Bash.
Yeah but some operating systems have HISTIGNORE in (or sourced from) their skeleton files.
I just open, agent in tui, and ask it to do what I want and make a plan, i read the plan edit it and run it.
Simple, no need to learn any commandline these days.
I used to use arch and all, and managed many big projects. I find little value in learning new tools anymore, just feed it docs and it generated working plan most of the time
Now I've moved to coding in Haskell, which i find suits me better than wasting my time with cli and exploring what options all these cli tools have.
I'm confused; how is writing a shell command (using shortcuts like those in the article!) "wasting time", but describing what you want to an LLM, having it make a plan, reading the plan, editing it, and running it is somehow not a waste of time?
You also mention there being "little value", when your proposed approach costs literal money in form of API/token usage (when using hosted models).
What is it like to be this proud of not learning the tools you use? Do you really think several paragraphs to an agent that may or may not be correct is the "easy" way compared to just checking the manual for the flag you want?
One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time.
In zsh this is configured with
Heh. I've done this since forever, but I use PgUp and PgDn so I can retain the original meaning of the up arrow key.
Once you start using CTRL+r, you may find that you never reach for up arrow again.
I'm familiar with ctrl-r, but I still very much like the up-arrow behavior described by that commenter.
There is a difference, I believe. Doesn't Ctrl+r do a substring search instead?
And once you want to one-up this look into fzf.
And once you get tired of fzf and want something better, you reach for https://atuin.sh.
Completely transformed all of my workflows
From the atuin.sh website
> Sync your shell history to all of your machines
I think of my shell history as very machine specific. Can you give some insights on how you benefit from history sync? If you use it.
Same, I find shared history not very useful.
However what I do find useful is eternal history. It's doable with some .bashrc hacks, and slow because it's file based on every command, but:
- never delete history
- associate history with a session token
- set separate tokens in each screen, tmux, whatever session
- sort such that backward search (ctrl-R) hits current session history first, and the rest second
Like half my corporate brain is in a 11M history file at this point, going back years.
What I would love is to integrate this into the shell better so it's using sqlite or similar so it doesn't feel "sluggish." But even now the pain is worth the prize.
That feature is entirely optional and disabled by default. Atuin stores your shell history locally in a sqlite db regardless of whether you choose to sync it. I thought fzf was fast, but atuin makes it look slow by comparison.
This can also be achieved with `.inputrc`:
That's a nice one.
One thing I do is configure my keyboard so that "modifier+{ijkl}" mimicks the inverted T arrows key cluster. So there's never a need for me to reach for the arrow keys. And {ijk} makes more sense than vi's {hjkl} and is faster/more logical/less key fingers travel. The nice thing is: as I do this at the keyboard level, this works in every single map. "modifier" in my case is "an easily reachable key in a natural hand position on which my left thumb is always resting" but YMMV.
I set that up years ago and it works in every app: it's gorgeous. Heck, I'm using it while editing this very message for example.
And of course it composes with SHIFT too: it's basically arrow keys, except at the fingers' natural positions.
> life-changing
For further life-changing experience... add aliases to .bash_aliases
I've got many like these I copied from various people over the years.
One I came up and that I use all the time:
I use it so much I sometimes forget it's not stock.Did this many years ago (but with bash) -- life changing is an apt way of saying it.
Here's the Bash commands for this in case anyone is looking for them
Using the terminal becomes much more cozy and comfortable after I activate vim-mode.
A mistake 3 words earlier? No problem: <esc>3bcw and I'm good to go.
Want to delete the whole thing? Even easier: <esc>cc
I can even use <esc>v to open the command inside a fully-fledged (neo)vim instance for more complex rework.
If you use (neo)vim already, this is the best way to go as there are no new shortcuts to learn and memorize.
This reminds me of an excerpt from an old Emacs manual:
This weird command is presented with such a benevolent innocence as if it's the simplest thing in the world.I think the better advice for command-line editing would be to set up the mouse.
> This weird command is presented with such a benevolent innocence as if it's the simplest thing in the world.
I think it's a question of context and familiarity. To a vim user, like me and, I assume, ahmedfromtunis, their examples do indeed seem simple and natural. Presumably, to an emacs user, the example you quote (if it's quoted literally—I don't use emacs and can't even tell) is just as natural, and assuming some comfort with emacs is presumably OK in a manual for the software!
> assuming some comfort with emacs is presumably OK in a manual for the software!
How do you get familiar with the software, if the manual expects you to be an expert in it already?
By reading introductory material.
Not sure if it did at the time, but today emacs comes with a tutorial. You’re not expected to learn it by starting on page 1 of the manual.
I've been a (n)vim user for 20+ years now, but I hate vi-mode in the shell. However if I feel that I need to do a complex command, I just do ctrl-x+e to open up in neovim (with EDITOR=nvim set). I find it a good middle ground.
It’s strange. I have heard this from lots of others too. I think I am an anomaly here. I can’t live without shell vi mode
I'm the same and in my opinion this is the best of both worlds. Taking the time to learn some of the regular (emacs-style) shortcuts is one of the best investments I've ever done. Even just CTRL+Y and the likes.
edit: And of course, CTRL+R, the best time saver of all
Huh. I don’t use vi-mode for more than jumping to the beginning or end of a line, which I like a lot.
It really shines for navigating history. <esc>/ searches history the same way as the editor search function
I'm a vim user but in the shell I use Ctrl-a and Ctrl-e to get to the beginning and end. If I need more editing I use Ctrl-x Ctrl-e to hop into vim.
C-a and C-e are your friend.
You mean, like the “home” and “end” buttons?
Yeah but those are so far away, i have to hunt for them every time
Agree.
I WANT to love it - and if I was only ever working on one, or a small number of systems that I was the only one working on I’d probably do it. I’m ALL about customizing my environment.
However ssh into various servers through the day (some of which are totally ephemeral), and having to code switch my brain back and forth between vim mode and emacs mode in the shell would just slow me down and be infuriating each time I connect to a new box.
I've been a vim/nvim casual user for the past year or two, and I still feel as if I'm slightly less proficient in it for the amount of time that I put into it.
I really need to get around to playing with it more. I just hope that especially now with genAI that it's not too late for learning it further.
> <esc>cc
Doing control+o in insert mode temporarily places you into normal mode so that you can execute one normal-mode command, and then go back to insert mode again--no need to hit 'i' again.
So, instead of '<esc>cc', '<c-o>S'.
The vim version is much easier, if you ask me: 3 strokes, 2 keys and 0 combinations.
The one you suggest however requires 4 strokes (ctrl then o then shift then s), 4 keys (ctrl, o, shift, s) and 2 combinations.
The "cc" sequence deletes the line and switches automatically to insert mode. To forgo the switch, the sequence then becomes "dd".
Maybe I have my bash/readline vi mode configured specially to do this, but if I want to delete the entire line and type a new one (from anywhere in that line), I do something simpler than either of these alternatives:
<esc>S
Esc exits insert mode (of course) and capital S erases the line and puts you in insert mode at column 0 (just like in (n)vim, right?).
Like I said, maybe I configured that? But 'S' is standard vim-stuff... (I'm not able to double check my config at the moment).
[Edit: right after hitting submit I realized that my way is perhaps "arguably" simpler because I do have to hit shift to get capital S. So I'm also hitting three keys...]
<c-o>S is also a vim sequence. The equivalent readline/emacs is <c-e><c-u> or <c-a><c-k>, or just <c-u> or <c-k> if you're already at the end/start of the line.
Oh wow I didn't know about this, thank you. The underlying feature is called "readline vi-mode" for folks who want to search more about it.
I use qwerty and azerty, and in both I never felt typing the sequence was any harder than typing any other regular word. Generally speaking, I prefer sequential "shortcuts" then multikey bindings.
Instead of esc, type ctrl [
Does it help a lot? You've still got a three to type which is a crime, plus some letters, only to move 3 words. My typing skills are not great, but that sounds like an awful lot of work(?)
If I hit CTRL + ARROW_LEFT 3 times, I am done a lot faster I guess. But I am open to learn, do people really use that and achieve the goal significantly faster?
I think it’s a difference in how people think. I can’t remember hotkeys. It just doesn’t compute. But with vim style bindings it’s much closer to writing a sentence. `3`, number of times, `b`, beginning of word, `c`, change, `w`, word. Yea it’s a lot. I cannot explain why it’s simpler for me to learn that than emacs style bindings but it is.
I don’t love vi-mode, but I’ll address your comment.
Many people these days, including yours truly, have caps-lock mapped to ctrl if held or esc if tapped. That’s good ergonomics and worth considering for any tech-savvy person.
Instead of the 3b I would type bbb (because I agree with you that typing numerals is a pain).
So (caps lock)bbbcw isn’t bad. It’s better than it looks, because if you’re a vim user then it’s just so automatic. “cw” feels like one atomic thing, not two keypresses.
And importantly, it doesn’t involve any chords.
The <esc>v has been such a lifesaver at times when having to execute/modify super complex commands!
I love this, from a comment on the article:
A similar trick:
that's my `~/bin/noglob` file, so when I call a zsh script from bash that uses `noglob`, it doesn't blow up.Yes! That one's going in my $PATH. Such a useful use of cat!
What does it provide over
mycmd1 #| mycmd2
Theirs "turns off" one element of a pipeline; yours turns off everything after a certain point.
This will output the stdout of mycmd1:
This will output the stdout of mycmd3:Can you explain to me why either of these is useful?
I've somehow gotten by never really needing to pipe any commands in the terminal, probably because I mostly do frontend dev and use the term for starting the server and running prodaccess
Pipelines are usually built up step by step: we run some vague, general thing (e.g. a `find` command); the output looks sort of right, but needs to be narrowed down or processed further, so we press Up to get the previous command back, and add a pipe to the end. We run that, then add something else; and so on.
Now let's say the output looks wrong; e.g. we get nothing out. Weird, the previous command looked right, and it doesn't seem to be a problem with the filter we just put on the end. Maybe the filter we added part-way-through was discarding too much, so that the things we actually wanted weren't reaching the later stages; we didn't notice, because everything was being drowned-out by irrelevant stuff that that our latest filter has just gotten rid of.
Tricks like this `\#` let us turn off that earlier filter, without affecting anything else, so we can see if it was causing the problem as we suspect.
As for more general "why use CLI?", that's been debated for decades already; if you care to look it up :-)
I can imagine a pipeline where intermediate stages have been inserted to have some side effect, like debug logging all data passing through.
CTRL + W usually deletes everything until the previous whitespace, so it would delete the whole '/var/log/nginx/' string in OP's example. Alt + backspace usually deletes until it encounters a non-alphanumeric character.
Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...
In my terminal it's the exact opposite – Alt-Backspace deletes to the previous space, whereas Ctrl-W deletes to the last non-alphanumeric (such as /). I'm using fish shell in an Alacritty terminal.
Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend.
> Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend.
Fun fact: despite having absolutely no menu entry for it, and I believe not even a command available with Ctrl+Shift+P, Vscode supports Ctrl+Shift+T to re-open a closed tab. Discovered out of pure muscle memory.
It's a normal command called "View: Reopen Closed Editor".
Set $WORDCHARS accordingly. In your case, remove / from $WORDCHARS.
https://unix.stackexchange.com/a/726014
For the bash people
source: https://superuser.com/questions/212446/binding-backward-kill...Ctrl-Shift-T usually brings that tab right back at least
> Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...
This hurts.
Also, for the shell, if you do C+w, you can "paste" it back using C+y. Assuming you have not removed that configuration.
Not a fan of the LLM-flavoured headings, and the tips seem like a real mixed bag (and it'd be nice to give credit specifically to the readline library where appropriate as opposed to the shell), but there are definitely a few things in here I'll have to play around with.
One thing I dislike about brace expansions is that they don't play nicely with tab completion. I'd rather have easy ways to e.g. duplicate the last token (including escaped/quoted spaces), and delete a filename suffix. And, while I'm on that topic, expand variables and `~` immediately (instead of after pressing enter).
Readline is close enough to being part of bash that it’s not really inaccurate to call these all shell features imo.
Speaking of readline, I recently found out PowerShell has a readline mode (https://learn.microsoft.com/en-us/powershell/module/psreadli...) and it works great.
As someone who works mostly in WSL and has to use PS occasionally, it really reduces the overhead of the context switch.
One trick I use all the time:
You're typing a long command, then before running it you remember you have to do some stuff first. Instead of Ctrl-C to cancel it, you push it to history in a disabled form.
Prepend the line with # to comment it, run the commented line so it gets added to history, do whatever it is you remembered, then up arrow to retrieve the first command.
$ long_command
<Home, #>
$ #long_command
<Enter>
$ stuff_1 $ stuff_2
<Up arrow a few times>
$ #long_command
<home, del>
$ long_command
In zsh you can bind "push-line-or-edit". In bash and all readline programs, you can approximate it with C-u followed by C-y (i.e. cut and paste). My history is still full of '#' and ':' (csh trauma) prefixed command-lines like you described though ...
Fwiw, in Bash, alt-shift-3 will prepend the current command with # and start a new command.
More generally, it's alt-#. On an ISO (e.g. UK) keyboard layout, shift-3 isn't a hash.
With ctrl+r, if you press it twice, it will autofill the search with whatever you last searched for. pressing it more will go back through the history. Been using that a lot recently when doing docker stuff. ctrl+r, type the container name, keep going until I get the compose build command. ctrl+r, ctrl+r, repeat until the log command. Then I can just mash ctrl+r to get the build and log commands. Ctrl+r is your friend. ctrl+r
Make sure to add fzf + shell integration for maximum Ctrl+r goodness.
Also worth reading the intro to fzf search syntax.
https://junegunn.github.io/fzf/search-syntax.
The $ and bang and exact search are neat, but the bit at the bottom as to why `gadd` or `gas` is a better search for `git add something` than something with full words and spaces is a revelation when first using fzf.
I've been using a lot of key combinations and I wasn't aware of these two, and I really think these are awesome additions to handling the console. Thank you for showing me. I've only been using it for 22 years, but I haven't come across these :D
`CTRL + U and CTRL + K CTRL + W`
What I like about these key combinations is that they are kind of universal. A lot of programs on Linux and Mac support all these key combinations out of the box. And that's like a game changer in productivity, especially jumping to the start or the end of the line or jumping forward and backward per word is making working only with the keyboard so much more nice. And in editors together so AVY, you can even get a faster flow of jumping around.
Regarding history: I have a function in my ZSH config which excludes certain things from the history. Especially things that can break stuff when my sausage fingers CTRL-R the wrong thing
Something like this:
> cd -: The classic channel-flipper. Perfect for toggling back and forth.
And not only cd. Gotta love 'git checkout -'
The '-' shortcut is weird. In 'git commit -F -', the '-' is actually /dev/stdin.
`-` is the traditional shell way to refer to stdin/stdout (as with your git commit example) but also the traditional way to refer to the last directory you were in (as with git checkout/switch).
You would never pipe the output of a command to `cd` so the `-` shortcut couldn't be helpful to cd as-is. So rather than invent yet another shortcut to memorize for `cd` they reused the existing one which otherwise would be redundant, which I appreciate at least.
But git is simply being consistent with the shell to further reduce the cognitive complexity of reusing shell commands you're used to in analogous git contexts.
- is a pretty standard idiom for using stdin/stdout instead of a named file that you can find in many commands. I don't think it conflicts with the cd/checkout usage though as there the argument normally does not refer to a file so having - mean stdin/stdout doesn't make sense.
What confuses me is that Ctrl+Y "yank" means the opposite of what it means in Vim. Certainly does not help with keeping my sanity.
The utility of $_ is often voided by tab-completion in the subsequent command, at least in bash. You won't know what it contains, which makes it dangerous, unless you first check it in a way that also carries it forwards:
printf %s\\n "$_"
There's one thing you need to only think about once, and has the potential to save you a ton of time: profile your ZSH startup time!
Stuff like NVM or Oh My ZSH will add a few seconds to your shell startup time.
I can recommend powerlevel10k with instant prompt enabled.
https://github.com/romkatv/powerlevel10k
good call
if you care about perf, fnm is better/faster/cleaner than nvm. (also, mise is able to manage "all the things", not just node)
IME omzsh slowness usu relates to overloading it w plugins, which I've never found a need for...
My favourite QoL improvement to any shell I use is to improve the history function(Ctlr+R)I personally like https://github.com/cantino/mcfly
Maybe not a shell trick per-se but I have been a very big fan of zoxide. It can jump around your common directories. If you have a ~/workspace/projects and you are anywhere and type `cd projects` it will take you to that directory. I never realized how much I got hooked onto it, until I used a system without it.
I'd advise against using sudo !! though since it adds the command to history and then it's very easy to accidentally trigger, running some undesired command as root without any prior confirmation. IMO pressing up, Ctrl-A and typing "sudo " isn't much longer but saves you from running unknown commands as root by accident
i never found !! useful at all when i can just use up arrow to get the entry i want. it becomes more interesting when you can recall older commands, but then too i prefer search because i want to verify what command i am going to run.
and i only use sudo to open a root shell. never to run anything directly. i don't want normal and root commands mixed in the same history.
i could keep sudo commands out of the history, but then i don't have any history for stuff done as root.
with tmux i can switch terminals easily, so i am also not tempted to run things as root that i shouldn't despite having a root shell open.
> i want to verify what command i am going to run.
shopt -s histverify
shopt -s histreedit
i dont know why they are not the default.
Prepend your command with a space and now your command is not saved in the history.
That depends on the shell configuration.
On bash, you can achieve this by setting HISTCONTROL=ignorespace but that's not the default.
I have a bash key binding, Ctrl+Y, that prepends sudo to the current command and submits it. I also don't use sudo-rs. No one has died yet.
Decades ago, i used a small dns host. I wanted to switch a personal site and they just couldn't get the final step of the transfer to work. A ton of "try now" emails spanning several weeks.
Then one day, I was trying to setup MySQL on a personal Linux machine, and it wouldn't let me use my "standard password" for the admin account. I knew I could just use a different one, but I really wanted to know what the problem was. Took a long time, and I don't remember how I figured it out, but I eventually tracked it to the password ending with '!!'.
It took a while to put it together, and I never confirmed with the dns host support it's what fixed the issue but, I changed my password there, tried the transfer again, and it worked without any help from support. I suspect my plaintext password played some part in a script used in the transfer process, and was outputting the previous command in place of the !! I wish I had asked them if that was it, but if it was, they would have to admit to having my plain text password, or lie about it.
set -o vi
<esc> puts you into vi mode at the cli prompt with all the semantics of the editor.
These carpal tunnel riddled hands can’t be bothered to reach for ctrl or alt let alone arrow keys.
I didn't know the `ALT + .` trick to repeat the last argument, but what is even more neat (and not mentioned in the article) is that it cycles through your history. At least it does in my shell.
A much larger base for ksh (as a pdksh descendent) is Android. OpenBSD is a tiny community in comparison, although Android has acquired code directly from OpenBSD, notably the C library.
The vi editing mode is always present in ksh, but is optional in dash. If present, the POSIX standard requires that "set -o vi" enable this mode, although other methods to enable it are not prohibited (such as inputrc for bash/readline), and as such is a "universal trick."
The article is relying on some Emacs mode, which is not POSIX.
$_ is not POSIX if I remember correctly.
History in vi mode is easier, just escape, then forward slash (or question mark) and the search term (regex?), then either "n" or "N" to search the direction or its reverse.
I've seen a lot of people who don't like vi mode, but its presence is the most deeply standardized.
My header on top of every script
Wait... Most of my shell scripts have zero unused variables: I prefer to comment them if I may need them later on.
Why do you disable SC2034?
I don't think not having unused variables prevent me from doing things in my scripts!?
I understand if it's a preference but SC2034 is basically one of my biggest timesavers: in my case unused variables are typically a bug. Except, maybe, ANSI coloring variables at the top of the script.
Undo:
it did not work for me in putty, so i added ctrl-x + ctrl-u too:
Something that should be mentioned is starting a command with a space doesn't add it to your history in most shells, really useful for one-off commands that you don't want cluttering your history.
Also, increase your `$HISTSIZE` to more than you think you would need, there have been cases where it helped me find some obscure command I ran like 3 years before.
HISTCONTROL=erasedups can also help keeping more obscure commands in your history, at the expense of context around commands.
> The “Works (Almost) Everywhere” Club
> The Backspace Replacements
Also known as "emacs editing mode". Funnily enough, what POSIX mandates is the support for "vi editing mode" which, to my knowledge, almost nobody ever uses. But it's there in most shells, and you can enable it with "set -o vi" in e.g. bash.
Vi mode is also available in Claude code and gemini-cli to give some recent examples, and a bunch of other places you might not expect it, as well the more obvious places where code is written.
Once you get used to it, it is painful to go back.
My biggest complaint about the fish shell is the lack of true vi mode. They attempt to emulate it and it works to some degree, but it's no comparison to readline's implementation.
You can always use Alt-E to open the command line in $EDITOR if you need more powerful commands. I find it better to use readline for small changes and jumping to vim for bigger ones.
Have you tried a recent version? An issue I opened about this years ago was finally closed, they claim it’s fixed now. I haven’t tried the purported fix, though.
And if you set `set editing-mode vi` in ~/.inputrc (readline configuration) you'll have it in even more places.
My favourite trick is either commenting out a whole command or placing a comment at the end of a command to make it easier to find in my persistent history (thanks eliben) [0], using the # character.
I tried this in zsh and it wasn't the default behaviour which immediately made me nope from the shell altogether, among all the other quirks. I've just been using bash for far too long to switch to something different.
[0] https://eli.thegreenplace.net/2013/06/11/keeping-persistent-...
Ctrl-r works well at searching character trigrams, which can include space. Trigrams without space work well with auto_resume=substring .
`| sudo tee file` when current user does not have permission to >file
I'm using bash for over 30 years and I still find new things. Nice.
great list but really overboard on the AI generated persona
Another useful "Emergency exit" is CTRL+Z which stops the process and cannot be intercepted.
It's often faster than hitting CTRL+C and waiting for process cleanup, especially when many resources are used. Then you can do e.g. `kill -9 $(jobs -p)` to kill the stopped tasks.
All of the keyboard-driven terminal signals can be intercepted; catching INT (^C) for cleanup is just more common than the others. Only KILL and STOP cannot be caught.
^Z sends TSTP (not STOP, though they have the same default behavior) to suspend; some programs catch this to do terminal state cleanup before re-raising it to accept the suspension. Catching it to do full backout doesn't make as much sense because the program anticipates being resumed.
^\ sends QUIT, which normally causes a core dump and is rarely caught. If you have core dumps disabled (via ulimit -c 0 or other system configuration) then you can often use it as a harder version of ^C; this is how I would tend to get out of ‘sl’ in places where I found it unwantedly installed.
ctrl-z pauses the process, it doesn't terminate. I think of z as in zombie as you can then run fg to bring it back from paused state or as you suggested kill in it for good
Never heard of instant truncate, nor `fc`, nor `Esc .`
Quite a few useful ones
Is it just me, or is it an LLM language? The article tries very hard to be correct but somehow lacks experience.
I've never used the majority of these tricks for decades, except for brace expansion, process substitutions, and complex redirections.
I knew many of these tricks, but learned many new tricks I didn't know and looks very useful (like you can do Ctrl-Y after an Ctrl-U, the 'reset' or 'disown' thing).
Regarding experience, I'm also struck by how many "experienced" engineers are just clueless with the keyboard.
> We’ve all been there.
Close tab.
I ought to migrate away from shell scripting and just keep the shell for interactive use. Unfortunately I have cursed myself by getting competent-ish with P. shell and Bash scripting. Meaning I end up creating maintenance headaches for my future self.
(Echoes of future self: ... so I asked an LLM to migrate my shell scripts to Rust and)
Anyway with the interactive shell stuff. Yeah the I guess Readline features are great. And beyond that I can use the shortcut to open the current line in an editor and get that last mile of interactivity when I want it. I don’t really think I need more than that?
I tried Vim mode in Bash but there didn’t seem to be a mode indicator anywhere. So dropped that.
Edit: I just tested in my Starship.rs terminal: `set -o vi`. Then I got mode indicators. Just with a little lag.
You can use `set vi-ins-mode-string` and `set vi-cmd-mode-string` in .inputrc to get indicators in readline, and you can add them to your prompt with a bit more work: https://superuser.com/questions/1466222/move-vi-mode-string-...
Guilty as charged
My favourite shell trick is to comment my code:
... Some weeks later .. .. finds: Need to see all the special things you've done this week/whenever? ...Makes for a definite return of sanity ..
I don’t keep history. Any commands I think will be useful, I save it in a script.
omg >$ CTRL-R<specialthing>
I could kiss you.. this alone is amazing!
!?specialthing?
If you are feeling brave
http://atuin.sh adds a database to store history in and a custom app to use for lookup with added modes to help with searching.
Yes indeed, it is very fun to discover this if you don't know it already, it expands your understanding of your shell life immensely, doesn't it?
What I hate is that if you start a command with a space it is not recorded in the history. This happens often when copy+pasting commands. I know you can turn it off but still ... this drives me mad.
AFAIK that setting is opt-in, at least in Bash.
Yeah but some operating systems have HISTIGNORE in (or sourced from) their skeleton files.
I just open, agent in tui, and ask it to do what I want and make a plan, i read the plan edit it and run it.
Simple, no need to learn any commandline these days.
I used to use arch and all, and managed many big projects. I find little value in learning new tools anymore, just feed it docs and it generated working plan most of the time
Now I've moved to coding in Haskell, which i find suits me better than wasting my time with cli and exploring what options all these cli tools have.
I'm confused; how is writing a shell command (using shortcuts like those in the article!) "wasting time", but describing what you want to an LLM, having it make a plan, reading the plan, editing it, and running it is somehow not a waste of time?
You also mention there being "little value", when your proposed approach costs literal money in form of API/token usage (when using hosted models).
> Now I've moved to coding in Haskell
You might like https://hackage.haskell.org/package/turtle or http://nellardo.com/lang/haskell/hash/
What is it like to be this proud of not learning the tools you use? Do you really think several paragraphs to an agent that may or may not be correct is the "easy" way compared to just checking the manual for the flag you want?
I will never understand people like you.
Tools are means to end.
They don't matter much to me.