CLI: Improved • Hacker News Board

Re: CLI: Improved

#21

Post by umvi » Thu, Aug 30, 2018, 7:08 PM UTC

cat's primary purpose is combining files together. For example:

    cat mysoftware.tar.gz mysoftware.sig > mysoftware.bin

Combines an archive with a digital signature into a single file. Then, on the other end, you just need to pop off the signature with a tail -1

Or alternatively:

    cat a.log b.log c.log > monolith.log

Re: CLI: Improved

#22

Post by pjmlp » Thu, Aug 30, 2018, 7:08 PM UTC

patja wrote: post #14

"I'm not sure many web developers can get away without visiting the command line." IIS has significant market share. I'll bet most web developers who deploy on it get away without having to use the command line interface very often if at all. https://news.netcraft.com/archives/2018/08/24/august-2018-we...

Same goes to JEE and Spring development.

Re: CLI: Improved

#23

Post by slaiyer » Thu, Aug 30, 2018, 7:12 PM UTC

radarsat1 wrote: post #3

> The bat command also allows me to search during output (only if the output is longer than the screen height) using the / key binding (similarly to less searching). You can do this with `less -F `. It will show the file on the screen like `cat` unless it is longer than one screen, then it will go into paging mode and allow search with `/`. Side note, how do you make his nice-looking prompt?

less +F

Re: CLI: Improved

#24

Post by hk__2 » Thu, Aug 30, 2018, 7:21 PM UTC

umvi wrote: post #21

cat's primary purpose is combining files together. For example: cat mysoftware.tar.gz mysoftware.sig > mysoftware.bin Combines an archive with a digital signature into a single file. Then, on the other end, you just need to pop off the signature with a tail -1 Or alternatively: cat a.log b.log c.log > monolith.log

Of course, but its primary purpose (combining files) differs from its primary usage (showing a file’s content).

Re: CLI: Improved

#25

Post by belark » Thu, Aug 30, 2018, 7:22 PM UTC

thibran wrote: post #2

rg > all other grep tools https://github.com/BurntSushi/ripgrep

Yeah, I stopped reading when the author blithely disregarded grep alternatives, yet praised _syntax highlighting_ of all things.

Re: CLI: Improved

#26

Post by FactolSarin » Thu, Aug 30, 2018, 7:25 PM UTC

patja wrote: post #14

"I'm not sure many web developers can get away without visiting the command line." IIS has significant market share. I'll bet most web developers who deploy on it get away without having to use the command line interface very often if at all. https://news.netcraft.com/archives/2018/08/24/august-2018-we...

I have co-workers who work on a big intranet web application that runs on IIS, and they never touch it.

They recently finally switched to git for source control, and they want to do everything via GUI. I've tried to show them how some things are just easier/better from the command line, but if something isn't doable via GUI, they won't do it. One of them keeps committing line endings differently than everyone else, and he literally won't run git config --global core.autocrlf true because... I dunno why. He just doesn't want to, because it's the command line.

Re: CLI: Improved

#27

Post by flother » Thu, Aug 30, 2018, 7:28 PM UTC

At the end of the article csvkit is given an honourable mention. I’m a big fan and I’ve used it a lot in the past, but these days I’d say that xsv > csvkit for working with CSV files on the command-line.

https://github.com/BurntSushi/xsv

Re: CLI: Improved

#28

Post by nextos » Thu, Aug 30, 2018, 7:31 PM UTC

GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though.

htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern.

Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being composable: doing one thing and communicating via plain text.

I'm less happy with the modern CLI-ncurses userland. Tools like e.g. mutt are little silos and don't compose that well. I've migrated to emacs, where the userland is much more composable.

Re: CLI: Improved

#29

Post by orf » Thu, Aug 30, 2018, 7:41 PM UTC

Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust.

Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the venerable 'cloc' utility. It took over 5 minutes. Looking around I found tokei, written in rust. Same-ish results (more accurate actually) took 10 seconds.

1. https://github.com/Aaronepower/tokei

Re: CLI: Improved

#30

Post by jolmg » Thu, Aug 30, 2018, 7:45 PM UTC

another-cuppa wrote: post #13

"bat" is not a better version of cat, it's a completely different tool. cat is short for concatenate. If you want to view a file use less, and if you want syntax highlighting etc. then use view (comes with vim).

Most tools mentioned are completely different tools from the ones they're suggested to be better versions of. I understand the comparison is for specific use-cases. For example, csvkit is far better than trying and failing to parse CSV with awk, but it's very much useless for any other type of text format. Same thing with jq (a JSON query tool) vs grep (a general text search tool). The only ones I can agree with in the general case are htop > top and ag || ack > grep (though I still prefer grep sometimes).