Live data from Hacker News

Linux Productivity Tools (2019) [pdf]

usenix.org

151–160 of 276 posts

Re: Linux Productivity Tools (2019) [pdf]

#151
post #23

The python utils section missed the very cool json.tool that can pretty print JSON files (and exists on your OS if it includes Python): cat /tmp/foo.json | python -m json.tool https://docs.python.org/3/library/json.html#module-json.tool

Don't abuse cats, use `python3 -m json.tool < test.json` instead.

Bit of pointless contrarian opinion from a long time cat|'r:

> Characters saved with " Hours lost with accidental ">"? unbounded.

Preface: I'm confident on the shell & with my keyboard: I've been using shell redirects for a couple decades, learned touch-typing up to around 80WPM, and used to note-take math lectures live in latex. Yes, I have noclobber enabled. But...

I can't promise myself I'm on a machine configured that way OR that I won't typo this one on a file that really matters.

I kinda use of `cat` as a `immutability-please` command: it _creates_ a barrier/seam between this file and whatever I'm doing with it, such that I'm _guaranteed_ nothing downstream will mutate it (as long as everything only works on stdio).

In a kinda similar way: by starting with `cat x |` (or even just `cat x`, frequently!), the rest of that compound command is _input source independent_ (and even _ignorant_!) -- if I want to hook it up later to a `curl example.com/xyz.json`, I don't need to split it into separate commands/introduce temp files/etc. This is especially because I find myself doing a _really_ quick scan of the entire file ("did it return the actual object this time or just `{}`?"), then piling on transforms from there.

Something about doing `cat x | head` and then kill-wording to fill in `next-thing` feels faster and more consistent than `head x` and then `next-thing x`, maybe because the filenames are often much longer than the commands? Maybe I need a "go to start of line, forward-kill one word" hotkey?

tl;dr: i'm playing psychological games with myself and TBH not sure I'm coming out ahead.

Re: Linux Productivity Tools (2019) [pdf]

#153
post #51
post #21

Nice slides. I missed him covering ripgrep and friends, which is very useful to avoid slower find-grep queries. Along with ripgrep, I think GNU Parallel (covered in the slides) and htop (briefly discussed) are great additions to any Unix development environment. The rest of the standard utilities have stood the test of time surprisingly well. But top is a bit wonky, xargs has many pitfalls and, as I said, ripgrep is…

+1 for ripgrep (it really is a lot faster). Also, I recommend using fd as a replacement for find. It’s API is a bit easier to grok imo, and it’s similarly blazing fast. fd/rg/fzf are the core tools I end up using most frequently, working in a big monorepo.

Does fd actually cover all the same ground as find? I used to be intimidated by find, but these days I find it’s extremely useful for all sorts of otherwise complicated file location operations. For example, to find files newer than a certain date, just use ‘touch’ to set the date of a temp file and then ‘find -newer temp’. Or, I have a script that deduplicates all the regular files in a tree by hard linking them to a file named by the sha256 of the file’s contents ‘find -type f | ( while read -r fn; do ...; done )’ and then, after deleting files or whatever, I can “garbage collect” the shas by deleting files in my link farm that only have one hard link ‘find -links 1 -print -delete’

Re: Linux Productivity Tools (2019) [pdf]

#154
post #20

One useful thing when managing one's time is to know when a command will complete. I have a habit of using "pv" anywhere I wait for a result so that I know how long it takes: http://www.ivarch.com/programs/pv.shtml It's basically "cat", but with a progress bar. Also useful for measuring IO speed and volume (e.g. decompression: `pv -c largefile | gzip | pv -c > /dev/null` )

You can also use it with dd, or even just redirect it directly to a block device. I use it a lot for writing USB images. `pv image.iso > /dev/sdX`. Just gotta be careful not to redirect it to the wrong one...

Project idea: ML-based snafu-avoider that prompts for confirmation when past invocations by other users in the community of that command resulted in manifestations of regret[1].

[1]: screaming picked up by mic; detected maniacal CTRL-C'ing as immediate as it is futile; permanent loss of peer relationship to the project's cloud (indicating subsequent reformatting and/or booting-off-tall-building)

Re: Linux Productivity Tools (2019) [pdf]

#155
post #20

One useful thing when managing one's time is to know when a command will complete. I have a habit of using "pv" anywhere I wait for a result so that I know how long it takes: http://www.ivarch.com/programs/pv.shtml It's basically "cat", but with a progress bar. Also useful for measuring IO speed and volume (e.g. decompression: `pv -c largefile | gzip | pv -c > /dev/null` )

You can also use it with dd, or even just redirect it directly to a block device. I use it a lot for writing USB images. `pv image.iso > /dev/sdX`. Just gotta be careful not to redirect it to the wrong one...

I use bmaptool for that. It shows progress and prevents writing to mounted volumes.

Re: Linux Productivity Tools (2019) [pdf]

#158

In native Mac text editors, you can use e.g. SHIFT + ALT + LEFT to select the whole word on the left of the cursor. Is there a way to get a Mac terminal that uses similar shortcuts? For copy/paste also? Related, but I found https://micro-editor.github.io/ which tries to use shortcuts you'd expect in native Mac apps.

There’s a couple options here: most of the Mac terminals allow you to specify custom key-combo -> Terminal input mapping that can be used to get this. Also, on most shells you can customize the interpretation of the key bindings to attach this key combo to a specific editing command. Which works best depends on the functionality and the key combo you’re trying to bind.

Re: Linux Productivity Tools (2019) [pdf]

#159

feedgnuplot [1] is wonderful for quick visualizations of data from the shell. Also great for decoupling visualization from CLI programs. [1]: https://github.com/dkogan/feedgnuplot

Hey that's my old roommate! Check out his vnlog project as well, it's kinda feedgnuplot 2.0

Re: Linux Productivity Tools (2019) [pdf]

#160
post #88

Earlier quoted context omitted.

> How many desktop environments actually let you switch the window button side? KDE does. And Gnome used to.

So use KDE then? Last time I tried it I found it to lack the polish that gnome has.

Interesting conundrum, with KDE I'm fighting the abundance of features not to break things but with GNOME I'm fighting the absence of features in order to make it productive.
Post reply on HN