CLI Tips and Tricks (with readline) to Optimize your Workflow - You Suck at Programming
Вставка
- Опубліковано 29 сер 2024
- Yo what's up everyone my name's dave and you suck at programming.
🔗 More Links
Website → ysap.sh
Discord → ysap.sh/discord
Instagram → ysap.sh/instagram
TikTok → ysap.sh/tiktok
UA-cam → ysap.sh/youtube
Ko-fi (donate) → ysap.sh/ko-fi
📖 Keywords
you suck at programming #programming
#devops #bash #linux #unix #software #terminal #shellscripting #tech #stem
ctl + l - clear screen rreally helps me not get distracted by all the junk filling htescreen from previous commands.
Love the channel, even though I do suck at programming!
ty! appreciate it
These are Stallman's doing. They're the defaults from Emacs. ctrl+a is beginning of line, ctrl+e is end of line, ctrl+k is current cursor position (called, "at point") to end of line on kill ring buffer, ctrl+y is yank kill ring buffer at point. The last two are great for incrementally executing a long series of piped commands interactively to understand it better.
This was pretty darn helpful! I had no clue the command line had so many quality of life features!
Set -o vi the best
I use emacs mode in the command line for the same reason i use vim as my editor: it is a staple in any machine i ever ssh into, so i can get up and running without barely ever feeling like i left my own environment
i’m gonna try this out and see how it feels
@@yousuckatprogramming You suck at programming too! Just go vi-mode and you'll be better :P
vi-mode shortcuts:
k (previous command)
j (next command)
(enter normal mode)
i (enter insert mode again)
b (move back a word)
w (move forward a word)
h (move left a character)
l (lowercase L) (move right a character)
C (delete everything to the right of the cursor)
cc (clear whole line)
ciw (change current word)
ciW (change current group of non-space characters)
diw (delete current word)
dW (delete next group of non-space characters)
$ (move cursor to end of line)
p (paste last deleted text)
x (delete character under cursor)
fx (jump to next x, x can be any character, fa, fb, etc)
Fx (jump to previous x, x can be any character Fa, Fb, etc)
rx (replace character with x)
Thanks Bam
How to show key icon when use sudo, It is terminal feature or font feature or other settings implement this
terminal feature… iterm2 on macos
Oh nice I thought my terminal was broken when I tried to use Ctrl + arrow keys to jump between words, or Ctrl + Backspace to delete an entire word, like in any other text editor I ever used (even notepad).
How is alt + f/b any better than this? keys far from each other, why ctrl + f/b to navigate characters, just use the arrow key, this is useless.. ctrl + w => delete one word back, like ???? why
I don't know if I am using it, I need standardized workflow not having to switch my muscle memory context depending on the software I use, and sorry I ain't using alt + f/b in other softwares to navigate between words back and forth, my arrow keys are my motion keys and that's all, like vim users use hjkl
I don't know for sure but i would take a guess
A) it appears emacs started developing before keyboard layouts were standardized, so keyboards were not guaranteed having arrow keys(emacs is relevant because bash readline essentially got its keybinds from emacs)
B) arrow keys are not single characters, but sequences, which depend on terminal emulator. Not a big deal now as most terminals are conpatible with xterm sequences, which was large terminal emulator
C) changing hand position to go for arrow keys is just kind of annoying, interrupts my flow
Also, its not hard to have a muscle memory for readline(its the library used in bash for navigating the command line), because a lot of interactive cli tools have readline bindings: sql stuff, ruby, python (some of theese actually use lib called `editline` but the bash bindings I'm used to are the same)
if you have a long covoluted command from your history that needs some tweaks and some editing before your next run ctrl-x ctrl-e lets you edit it in your $EDITOR before executing
oh this is sick
I would add alt + d for deleting one word forward
Needs moar fzf
i just found out about this tbh
cheat sheet:
ctrl-r: fuzzy find command in history.
ctrl-t: fuzzy find file/directory. e.g. `cd dnd` could expand to `cd deeply/nested/directory`
Episode 15 - CLI Tips and Tricks (with readline) to Optimize your Workflow
This episode centers around the GNU Readline, which is a common underlying library shared by bash and a number of other GNU utilities including emacs. So far everything Dave has demoed, even the stuff built for interactive mode, has dealt with bash operating primarily in a "line mode," where what you type out character-by-character is of no interest to the shell until after you finalize it and press enter. Readline breaks from that, in order to implement interactive command lines, by caring about the data you send to your terminal keystroke by keystroke rather than line-by-line.
Readline is effectively the "operating system" which is in effect prior to a line being sent into bash for interpretation at the script/code level, watching what you do one keypress at a time. It generally won't know if you have pressed a chording key such as shift/control or not, but any time you press a chord which causes your terminal emulator to send input to your terminal, readline is the part of the bash codebase which interprets that character of input. Readline permits key-bindings such as the ones Dave demonstrates, and also interoperates with a number of other bash features including those for tab completion and editable command history.
The bindings Dave shows (and I call them bindings here because that's the terminology in Bash documentation; other programs on desktop operating systems often instead refer to these as "hotkeys") are part of the Emacs-style readline bindings enabled in bash by default, and after 'set -o emacs'. You can instead get a vi-style binding using 'set -o vi', which gives you the ability to enter a control mode by pressing escape and then navigating your command line using all the same keys and functions that are available to you in vi. This is my mode of preference.
readline configuration is govered by your inputrc file, usually ~/.inputrc but sometimes elsewhere depending on how your system administrator or OS packager has built and configured bash. It has documentation under the 'READLINE' section of your bash man page, and in Chapter 8 of the Bash Reference Manual, Command Line Editing.
A key thing to understand when interacting with bash which can vary widely depending on your operating environment is how the 'meta' key which readline expects is received from your terminal. Most decent terminal emulators include a setting which let you bind (in the more conventional OS application sense) the key which will be sent as Meta, and there is a separate key sequence for 'Alt' which is distinct from Meta and can be sent over a terminal.
You can customize your environment to make profound changes to your interactive bash command lines, including some limited syntax highlighting for commands, fresh bindings, even full macros. Other than your .inputrc file, you can also interact with these commands using the 'bind' command. If you want to learn more about how to change this environment, start with Chapter 8 of the reference manual, while you have a terminal open, and as you read the docs, periodically compare what you're reading with the output of 'bind -p', which lists all the bindings currently applicable to your environment.
I tend not to change the stock bindings for a bash shell at all, because it can be disorienting if your shell bindings change from one host to another, or one user to another on hosts where you are using sudo and su to switch users to various role accounts including the root user. If your usage pattern varies from that, for example primarily interacting with your shell via a terminal running locally on a MacOS or Linux desktop, you may want to consider far deeper customizations, _especially_ if you also plan to make significant investment in programmable completion (i.e. the "tab" key becomes a contextual do-what-I-mean button, completing far more than simple filenames). Learning how to interact with the built in "kill-ring" included in Readline to do copy-and-paste without relying on the local clipboard of the desktop where your terminal is running can be a godsend in certain cases.
Do you suck at programming if you don't know this stuff? To a certain extent, yes! This is an area in bash where you probably don't need to go anywhere near as deep as the shell lets you, but knowing even the visible part of the readline iceberg can definitely make you both a better shell operator and a better bash programmer.Good programmers are able to work quickly. Working quickly in a command line environment requires you to be able to produce and modify the commands you enter quickly, without having to resort to strategies like copy-and-paste or manual re-entry of botched lines. Understanding how to interact with both readline and the history facility are critical to improving your bash operating speed. This is especially true if you are often interacting with bash via ssh or via a terminal emulator, versus interacting with it using something like an embedded terminal on an IDE which might include its own command line history features independent from your shell.
Happy command line editing!
When you should be offended, but then understand that you suck at everything
This is an emacs things
Sometimes when I'm typing a command I realize I need to run another command first. So, I use Ctrl+u to delete the line. Later, I can use Ctrl+y to bring it back.
ok i need to learn ctrl-y
We need a `.history/` to dump all the history files into. Please, XDG!
XDG already decided they should end up in XDG_STATE_HOME, or ~/.local/state.
a hackers dream