5 ms·

CLI tricks every developer should know

36 points by kiyanwang 4y ago

toxik 4y ago
The author pasted commands using Unicode quotes “” so the echo output includes them, and a trailing colon from the article text itself. I get the feeling that this person doesn’t actually know how to use the command line, so why are they writing an article about it?
- dthul 4y ago
  Works fine for me (shows up as normal quotes, not fancy quotes).
  - JimDabell 4y ago
    They are talking about the screenshot; the text of the article is correct.
  - morelisp 4y ago
    The code block is fine but the screenshot is definitely busted: https://github.blog/wp-content/uploads/2023/04/bash-screenshot.png?w=653&resize=653%2C453 https://github.blog/wp-content/uploads/2023/04/bash-screensh...
    - zamnos 4y ago
      the screen shot is internally correct/not doctored. it uses smart quotes, which bash doesn't interpret, so echo then just repeats them back, which says the author copy and pasted from a draft that already had quotes replaced by smart quotes.
- laserdancepony 4y ago
  [flagged]
mickeyp 4y ago
Most of those keyboard shortcuts are worth learning; there are more, though, and the article leaves out why they are the way they are and that they're available anywhere GNU readline is used. Here's a more detailed article I wrote about them a while back: https://www.masteringemacs.org/article/keyboard-shortcuts-every-command-line-hacker-should-know-about-gnu-readline https://www.masteringemacs.org/article/keyboard-shortcuts-ev... For instance, did you know that you can record keyboard macros and play them back? It's a GNU readline feature.
- Lio 4y ago
  GNU readline defaults to emacs mode (the scheme described in the article) but there's also a vi mode which can be enabled with: set -o vi If you're already familiar with Vi, Vim or NeoVim then it's a really comfortable way to work.
- abdusco 4y ago
  What I often miss is a hotkey to jump prev/next argument. The closest I could find is jumping by words, but it's not the same.
  - _TwoFinger 4y ago
    I think M-C-f and M-C-b do that.
0l 4y ago
I think the author is actually talking about the shell (specifically, bash), rather than a CLI. Pretty incomprehensible overall.
- 369548684892826 4y ago
  > specifically, bash That would certainly explain this error message I'm getting in Powershell `Get-History : Cannot bind parameter 'Id'. Cannot convert value "n" to type "System.Int64". Error: "Input string was not in a correct format."`
- slig 4y ago
  I believe most people upvoted because of the domain `github.blog` before reading the article.
- tommy_axle 4y ago
  Correct, I don't think it was mentioned in the article but this was geared towards and *nix platform. It's not only shells but anything that uses readline (the library that implements these shortcuts), e.g. mysql/sqlite cli client, node and many others.
pjmlp 4y ago
Given the content, "CLI tricks every UNIX developer should know"
- mtlmtlmtlmtl 4y ago
  Add one more trick: How to get a Unix like shell on Windows. Now it's for all developers!
  - pjmlp 4y ago
    PowerShell does the job.
- linhns 4y ago
  With WSL then every Windows user can have Unix, then "UNIX" is not necessary anymore
  - pjmlp 4y ago
    Windows developers have access had to various UNIX like workflows since Windows NT exists, yet it has hardly been a thing for Windows developers.
- eesmith 4y ago
  As a tcsh user, I raise an eyebrow, Spock-like, to that characterization. % echo $SHELL /bin/tcsh % echo "the date is $(date)": Illegal variable name. The article doesn't even use the word "Unix": "For this blog post, all of the examples are for Bash since it’s the most widely used shell. And if you’re using Windows, Windows Subsystem for Linux (WSL) is available if you’d like to use a Bash terminal."
  - pjmlp 4y ago
    Windows developers seldom reach for bash, unless to run scripts ported from UNIX. For which OS was tcsh originally developed?
_y5hn 4y ago
This is clearly geared towards developers, many who are using MacOS these days. I guess these same shortcuts work in zsh as well as bash then. A bit click-baity and could deserve a bit more introduction of what it is (shell). But the list of shortcuts is nice to add to your toolbox, if not already there. You can get the same on Windows by using WSL, or out of the box in Linux (usually).
_TwoFinger 4y ago
They mention history expansion, but only briefly. It is a favorite of mine. Learning the full syntax probably doesn't give good ROI these days of mice, but I think the following shortcut notations are worth knowing: Everything but the last argument: % git add -p dir1 % !!- dir2 git add -p dir2 Everything but the command: % textadept a b c % vim !* vim a b c Substitute a string (once): % echo helo world % ^lo^llo echo hello world First and last arguments: % diff path/a/file path/b/file % diff !$ !^ diff path/b/file path/a/file A cool detail is that even a long quoted string containing spaces is considered a single argument, and it all works fine. Also, the bangs can be anywhere on the command line, even inside other kinds of expansion; history expansion has highest priority of all. Edit: the above is csh-style history expansion, available in bash as well.
PeterWhittaker 4y ago
Ctrl-D exits the shell IFF it is entered at an otherwise empty command prompt. When editing a command line, it deletes the character under eh cursor. When reading from stdin, e.g., if one executes cat with no arguments and not in a pipeline, it acts as EOF and ends the read. Interestingly enough, if entered after text without a newline, it ends that segment of input; entering it again ends the read. Ctrl-u and Ctrl-k delete from the cursor to the start and end of line respectfully; ctrl-w deletes from the cursor to the start of the current word. Alt-b and Alt-f move backward and forward one word. Very handy.
ramses0 4y ago
A favorite that I use very frequently is `esc .` (or maybe `alt+.`), which "up-arrows" through the last token of your command history. mkdir /tmp/foo # /tmp/foo is the last token cd <esc .> # cd /tmp/foo is the result touch bar.txt # bar.txt is the last token vim <esc .> # vim bar.txt is the result :wq # ...exit vim ls <esc .><esc .> # two tokens previously gets you to "ls /tmp/foo" It's kindof like an "it" variable. Another "trick" I use often is `fc` and related: `help`, and the humble `#` comment character. # `fc` - mnemonic: "Fix Command" cp -rv /tmp/foo /tmp/bar # ...but don't press enter! <ctrl-a> # <enter> # beginning of line, comment it out, commit to history fc # now you can edit to your heart's content man fc # it's a builtin help fc # and builtins have documentation via "help" man cd # going to the "builtins" manpage is not that useful help cd # ...did you know cd supports -L and -P ?? ...and a slightly related vim-tip in the context of "fc". `<shift-v>:!ls /tmp` is an interesting technique to "bring in" the output of a command for editing. Example: git commit -m "whoops, don't commit just yet (don't press enter)"<ctrl-a>#<enter> # this leaves you with a `#git commit -m ...` comment in your history fc # fix command $VIM => o<esc>V:!git status --porcelain | grep -v ^?? # within vim you're using visual selection with `:!...` to "filter" the selection (a blank line) with an external command # in the case of `V:!ls` you're filtering the current line through `ls` # ...which is basically running `ls` (give you a list of files) # the more complicated `git status --porcelain | grep ...` # ...lets you "pull in" the output of that command # ...(with full pipeline support), and then compose # ...a more complicated (and accurate) command than # ...messing around on the command line. eg: git restore --staged FILE1.txt FILE2.txt && git commit -m "...etc..." Usually you use something like `:!make` to execute the `make` command from vim, but this is an "abuse" of visually-selecting something to filter and replacing the selection with the output. The selection is passed on stdin to the executed command, eg: `V:!tr [a-z] [A-Z]` would be a terribly inefficient way to filter the current line through "tr / uppercase". `ls` as far as I know doesn't really do anything with stdin, so you're basically filtering/replacing the visual selection with the output of `ls` (or any other command), which is great to give you access to accurate filenames or whatever info you can get from a command (`curl`, `git`, `ls`, `apt search ...`, `pip list`, ...etc...). I find using `fc` with `EDITOR=vim` far superior to having the command line (readline) set to "vim/vi" mode, as with `fc`, I'm able to context-switch far easier and have a whole document as a palette / canvas to be able to compose complicated commands. TL-DR: use <esc .> (escape followed by a period) to access "just the last token/word", and use `# commented-out-command.sh` along with `fc` to have full editing power to accurately compose (or fix) a complicated command.

36 points by kiyanwang 4y ago

The author pasted commands using Unicode quotes “” so the echo output includes them, and a trailing colon from the article text itself. I get the feeling that this person doesn’t actually know how to use the command line, so why are they writing an article about it?

dthul 4y ago
Works fine for me (shows up as normal quotes, not fancy quotes).
- JimDabell 4y ago
  They are talking about the screenshot; the text of the article is correct.
- morelisp 4y ago
  The code block is fine but the screenshot is definitely busted: https://github.blog/wp-content/uploads/2023/04/bash-screenshot.png?w=653&resize=653%2C453 https://github.blog/wp-content/uploads/2023/04/bash-screensh...
  - zamnos 4y ago
    the screen shot is internally correct/not doctored. it uses smart quotes, which bash doesn't interpret, so echo then just repeats them back, which says the author copy and pasted from a draft that already had quotes replaced by smart quotes.
laserdancepony 4y ago
[flagged]

mickeyp 4y ago

Most of those keyboard shortcuts are worth learning; there are more, though, and the article leaves out why they are the way they are and that they're available anywhere GNU readline is used. Here's a more detailed article I wrote about them a while back: https://www.masteringemacs.org/article/keyboard-shortcuts-every-command-line-hacker-should-know-about-gnu-readline https://www.masteringemacs.org/article/keyboard-shortcuts-ev... For instance, did you know that you can record keyboard macros and play them back? It's a GNU readline feature.

Lio 4y ago
GNU readline defaults to emacs mode (the scheme described in the article) but there's also a vi mode which can be enabled with: set -o vi If you're already familiar with Vi, Vim or NeoVim then it's a really comfortable way to work.
abdusco 4y ago
What I often miss is a hotkey to jump prev/next argument. The closest I could find is jumping by words, but it's not the same.
- _TwoFinger 4y ago
  I think M-C-f and M-C-b do that.

0l 4y ago

I think the author is actually talking about the shell (specifically, bash), rather than a CLI. Pretty incomprehensible overall.

369548684892826 4y ago
> specifically, bash That would certainly explain this error message I'm getting in Powershell `Get-History : Cannot bind parameter 'Id'. Cannot convert value "n" to type "System.Int64". Error: "Input string was not in a correct format."`
slig 4y ago
I believe most people upvoted because of the domain `github.blog` before reading the article.
tommy_axle 4y ago
Correct, I don't think it was mentioned in the article but this was geared towards and *nix platform. It's not only shells but anything that uses readline (the library that implements these shortcuts), e.g. mysql/sqlite cli client, node and many others.

pjmlp 4y ago

Given the content, "CLI tricks every UNIX developer should know"

mtlmtlmtlmtl 4y ago
Add one more trick: How to get a Unix like shell on Windows. Now it's for all developers!
- pjmlp 4y ago
  PowerShell does the job.
linhns 4y ago
With WSL then every Windows user can have Unix, then "UNIX" is not necessary anymore
- pjmlp 4y ago
  Windows developers have access had to various UNIX like workflows since Windows NT exists, yet it has hardly been a thing for Windows developers.
eesmith 4y ago
As a tcsh user, I raise an eyebrow, Spock-like, to that characterization. % echo $SHELL /bin/tcsh % echo "the date is $(date)": Illegal variable name. The article doesn't even use the word "Unix": "For this blog post, all of the examples are for Bash since it’s the most widely used shell. And if you’re using Windows, Windows Subsystem for Linux (WSL) is available if you’d like to use a Bash terminal."
- pjmlp 4y ago
  Windows developers seldom reach for bash, unless to run scripts ported from UNIX. For which OS was tcsh originally developed?

_y5hn 4y ago

This is clearly geared towards developers, many who are using MacOS these days. I guess these same shortcuts work in zsh as well as bash then. A bit click-baity and could deserve a bit more introduction of what it is (shell). But the list of shortcuts is nice to add to your toolbox, if not already there. You can get the same on Windows by using WSL, or out of the box in Linux (usually).

_TwoFinger 4y ago

They mention history expansion, but only briefly. It is a favorite of mine. Learning the full syntax probably doesn't give good ROI these days of mice, but I think the following shortcut notations are worth knowing: Everything but the last argument: % git add -p dir1 % !!- dir2 git add -p dir2 Everything but the command: % textadept a b c % vim !* vim a b c Substitute a string (once): % echo helo world % ^lo^llo echo hello world First and last arguments: % diff path/a/file path/b/file % diff !$ !^ diff path/b/file path/a/file A cool detail is that even a long quoted string containing spaces is considered a single argument, and it all works fine. Also, the bangs can be anywhere on the command line, even inside other kinds of expansion; history expansion has highest priority of all. Edit: the above is csh-style history expansion, available in bash as well.

PeterWhittaker 4y ago

Ctrl-D exits the shell IFF it is entered at an otherwise empty command prompt. When editing a command line, it deletes the character under eh cursor. When reading from stdin, e.g., if one executes cat with no arguments and not in a pipeline, it acts as EOF and ends the read. Interestingly enough, if entered after text without a newline, it ends that segment of input; entering it again ends the read. Ctrl-u and Ctrl-k delete from the cursor to the start and end of line respectfully; ctrl-w deletes from the cursor to the start of the current word. Alt-b and Alt-f move backward and forward one word. Very handy.

ramses0 4y ago

A favorite that I use very frequently is `esc .` (or maybe `alt+.`), which "up-arrows" through the last token of your command history. mkdir /tmp/foo # /tmp/foo is the last token cd <esc .> # cd /tmp/foo is the result touch bar.txt # bar.txt is the last token vim <esc .> # vim bar.txt is the result :wq # ...exit vim ls <esc .><esc .> # two tokens previously gets you to "ls /tmp/foo" It's kindof like an "it" variable. Another "trick" I use often is `fc` and related: `help`, and the humble `#` comment character. # `fc` - mnemonic: "Fix Command" cp -rv /tmp/foo /tmp/bar # ...but don't press enter! <ctrl-a> # <enter> # beginning of line, comment it out, commit to history fc # now you can edit to your heart's content man fc # it's a builtin help fc # and builtins have documentation via "help" man cd # going to the "builtins" manpage is not that useful help cd # ...did you know cd supports -L and -P ?? ...and a slightly related vim-tip in the context of "fc". `<shift-v>:!ls /tmp` is an interesting technique to "bring in" the output of a command for editing. Example: git commit -m "whoops, don't commit just yet (don't press enter)"<ctrl-a>#<enter> # this leaves you with a `#git commit -m ...` comment in your history fc # fix command $VIM => o<esc>V:!git status --porcelain | grep -v ^?? # within vim you're using visual selection with `:!...` to "filter" the selection (a blank line) with an external command # in the case of `V:!ls` you're filtering the current line through `ls` # ...which is basically running `ls` (give you a list of files) # the more complicated `git status --porcelain | grep ...` # ...lets you "pull in" the output of that command # ...(with full pipeline support), and then compose # ...a more complicated (and accurate) command than # ...messing around on the command line. eg: git restore --staged FILE1.txt FILE2.txt && git commit -m "...etc..." Usually you use something like `:!make` to execute the `make` command from vim, but this is an "abuse" of visually-selecting something to filter and replacing the selection with the output. The selection is passed on stdin to the executed command, eg: `V:!tr [a-z] [A-Z]` would be a terribly inefficient way to filter the current line through "tr / uppercase". `ls` as far as I know doesn't really do anything with stdin, so you're basically filtering/replacing the visual selection with the output of `ls` (or any other command), which is great to give you access to accurate filenames or whatever info you can get from a command (`curl`, `git`, `ls`, `apt search ...`, `pip list`, ...etc...). I find using `fc` with `EDITOR=vim` far superior to having the command line (readline) set to "vim/vi" mode, as with `fc`, I'm able to context-switch far easier and have a whole document as a palette / canvas to be able to compose complicated commands. TL-DR: use <esc .> (escape followed by a period) to access "just the last token/word", and use `# commented-out-command.sh` along with `fc` to have full editing power to accurately compose (or fix) a complicated command.