3 ms·

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

smcl 6y ago
Why go to all that extra effort to type a "<" character? $ python3 -m json.tool test.json
traviscj 6y ago
Bit of pointless contrarian opinion from a long time cat|'r: > Characters saved with "<"? 3. > 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.
- hikarudo 6y ago
  Wow, you described my workflow exactly. Using "<" might be shorter and faster-for-the-machine, but it's less readable and breaks the left-to-right order. I also frequently start with `cat x`, see what's in the file, move on to `cat x | some filter` etc.
  - smorrow 6y ago
    '<file' can be used anywhere in the command. If it makes more human sense to have the file near the start, you can do that. grep <file -opts 'regex'
    - traviscj 6y ago
      This is why I walked back my claims a bit in my tldr — basically started trying stuff out and had a “whoa not used to the way that looks, but it does _work_...” moment. I think I still have the “wrong” preference, but I appreciate learning some new stuff!
dvirsky 6y ago
cat was just to demonstrate using it on streams. A more common use case would be to pipe some curl to it to see some API output, or grep some log file.

smcl 6y ago

Why go to all that extra effort to type a "<" character? $ python3 -m json.tool test.json

Bit of pointless contrarian opinion from a long time cat|'r: > Characters saved with "<"? 3. > 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.

hikarudo 6y ago
Wow, you described my workflow exactly. Using "<" might be shorter and faster-for-the-machine, but it's less readable and breaks the left-to-right order. I also frequently start with `cat x`, see what's in the file, move on to `cat x | some filter` etc.
- smorrow 6y ago
  '<file' can be used anywhere in the command. If it makes more human sense to have the file near the start, you can do that. grep <file -opts 'regex'
  - traviscj 6y ago
    This is why I walked back my claims a bit in my tldr — basically started trying stuff out and had a “whoa not used to the way that looks, but it does _work_...” moment. I think I still have the “wrong” preference, but I appreciate learning some new stuff!

dvirsky 6y ago

cat was just to demonstrate using it on streams. A more common use case would be to pipe some curl to it to see some API output, or grep some log file.