Live data from Hacker News

Become Shell Literate

drewdevault.com

221–230 of 341 posts

Re: Become Shell Literate

#221
The following sets up a key binding to grab interesting lines from the history, throw them into a file, and pop it up in an editor:

  # put interesting lines from history into a file, open an editor
  function h2e() {
      echo "#! /bin/bash" > "$3"
      history | tail -n"$1" | egrep "$2" | sed -re 's/\s*[0-9]+\s+//' >> "$3"
      "${EDITOR:-emacs}" "$3"
  }

  # prompt for h2e's arguments
  function h2ei() {
      read -p 'num. lines [1]: ' lines
      read -p 'pattern [.]: ' pattern
      read -p 'file [foo.sh]: ' fn
      h2e "${lines:-1}" "${pattern:-.}" "${fn:-foo.sh}"
  }

  # fix the terminal settings for the duration of a command, revert afterward
  function insane() {
      save=$(stty -g)
      stty sane
      "$@"
      stty $save
  }

  # bind F12 to our history grabber
  bind -x '"\e[24~":insane h2ei'
It's been quite handy of late.

Re: Become Shell Literate

#222

Earlier quoted context omitted.

You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…

>The Linux man pages are upside down. Examples don't come till the very end, if at all. You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?

I always thought someday I would become a hardcore Linux hacker and know all the commands and flags but the reality is I have to relearn every time. Who spends that much time just in the command line these days? I’m sure some people do but I don’t know what they do unless its CTFs or security related.

Re: Become Shell Literate

#223
post #45

Earlier quoted context omitted.

(nit) > `grep --extended-regexp` but `sed --regexp-extended` Why not use `grep -E` and `sed -E`?

Hint: if you're still using grep to search files rather than a file , install and start using the "newer generation" of greps (ag, ripgrep etc). You likely won't believe the speed. I use ag many times a day to search 10,400 files comprising about 800k lines of code, and it is in every meaningful way completely instantaneous. It also understands repository structures, and so won't waste your time there. It seriously c…

Integrating rg and fzf into vim changed my programming life. I find that combo pretty incredible and something I haven't found in IntelliJ. I usually find myself switching back to my shell and then back to IntelliJ.

Re: Become Shell Literate

#224

That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.

You can fix it by replacing the awk with "cut -d ' ' -f 2-" Haven't tested it, but you may also need to throw a "tr '\n' '\0'" in there and call xargs with "-0" to make it happy. This will still break on files with a CR in the filename. (CRs are allowed in unix filenames but, imho, they should not be.)

you also want to tell xargs not to run the command on an empty set, otherwise you'll just do 'git checkout --' which will just kill all your local changes, probably.

Re: Become Shell Literate

#225
post #195

That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.

Yeah, it's annoying that unix filenames and shell quoting are both fundamentally broken and that (as above) people would generally (knowingly) write a a broken-for-spaces-in-filenames version by default because it's easier (and the author no doubt knew he'd not encounter spaces in his repo). Having said that, it's not very hard to fix, I'd probably write something like: git status -s | awk -vORS="\0" 'gsub(/^ D /,"")…

But now you require gnu awk, it no longer works under posix (so for example busybox). Which sucks a bit.

Re: Become Shell Literate

#226
post #35

Earlier quoted context omitted.

tldr [0] is great for easy to understand example commands. It is community driven and there are many cli based programs you can install[1][2]. [0] https://tldr.sh/ [1] https://www.npmjs.com/package/tldr [2] https://github.com/tldr-pages/tldr-python-client

That python client seems very lack of maintenance. It doesn't have proper color code for Windows at all.

That's true. I thought that was the one packaged by most linux distros but debian packages the haskell client [0]. Looks like they have some windows builds too.

[0] https://github.com/psibi/tldr-hs#readme

Re: Become Shell Literate

#227

I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…

It’s even worse if you man test: you’re directed to the shell builtins page, that’s a few hundred pages long.

Re: Become Shell Literate

#228

I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…

[deleted]

Re: Become Shell Literate

#229
Learning some kind of common shell language is certainly a knowledge that will serve you well in the widest amount of circumstances. From managing headless servers, to local use on a workstation, to scripting within your U-Boot bootloader, to reverse engineering Linux based IoT/devices that oftentimes include busybox. Shell is included in a lot of places.

Re: Become Shell Literate

#230

Earlier quoted context omitted.

You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options. That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is ho…

> The Linux man pages are upside down. Examples don't come till the very end, if at all. man pages are meant to be a full reference, not a quick tutorial. To get the quick tutorial others have already mentioned cheat.sh [1] and tldr pages [2] is another good resource. [1]: https://cheat.sh/ [2]: https://tldr.sh/

+1 for tldr.sh. It's fantastic, I use it all the time, sometimes randomly for stuff I haven't got installed to find out whether I should homebrew it or not. Unlike man pages, tldr can search and find docs for stuff you don't currently have installed.

And it's fun to read. It's how man pages should be written, at least have a tl;dr before boring you to death.

Post reply on HN