Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI: Improved

remysharp.com

Post reply on HN
Print view View original

31–40 of 280 posts

Re: CLI: Improved

#31

Post by androidgirl »

The inclusion of Ponysay over cowsay is dubious at best.

Let me be clear: Ponysay has its niche. But with the Ansible stack providing great out of the box integration with Cowsay, it's clear which is the tool of choice for modern workflows.

On a serious note, TL:DR is amazing in some cases. The man page for "tar" compared to the TL:DR is much more unwieldy for 99% of use cases, for example.

I love ripgrep and htop, and I think that a lot of people new to *nix cli's would love tree as well!

Re: CLI: Improved

#32

Post by smartmic »

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).

whether cats or bats … beware of the Useless use of cat (UUOC) (or bat) ;)

Re: CLI: Improved

#33

Post by burntsushi »

jolmg wrote: post #30
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 t…

If you don't mind me asking, in roughly what cases do you reach for grep instead of ag || ack? Is it a familiarity thing, or specific features or something else?

Re: CLI: Improved

#34

Post by steveklabnik »

orf wrote: post #29

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…

IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark...

We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!

Re: CLI: Improved

#35

Post by dijit »

orf wrote: post #29

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…

I wonder if there's a name for this phenomenon.

New and not-popularly adopted languages tend to have more senior people learning and developing software using them; this leads to people (read: recruiters) looking for the people with experience.. People equate the quality of software with something innate with the language, or that the developers are exceptional. Then after being popularly adopted it slumps in perceived elegance and goes on a downward spiral until it ends up like PHP, Ruby or JAVA. (not to undersell the folks who predominantly use those languages, I'm just picking languages that I've seen follow this pattern)

Re: CLI: Improved

#37

Post by jayrhynas »

mlevental wrote: post #17

bat is cool but is there a way to get not to dump everything into my terminal and just page just like less? i wonder if there's a `bless` ?

You should be able to pass `--paging always`. The default `auto` will only page if the file contents is bigger than your screen.

Re: CLI: Improved

#38

Post by C0d3r »

mlevental wrote: post #17

bat is cool but is there a way to get not to dump everything into my terminal and just page just like less? i wonder if there's a `bless` ?

If your terminal is big enough, it will just output like cat, otherwise, you get a pager.

You can disable it with `bat --paging never`

Re: CLI: Improved

#39

Post by khalilravanna »

FactolSarin wrote: post #26
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, a…

I just went through this with most of the engineers at our company as they're mostly .NET devs. It's an ongoing process but I basically gave a big talk open to questions on how to use git, all the commands, and the benefits of using the CLI. Thankfully they have a willingness to learn and become better developers and so it's been going pretty smoothly outside of a couple hiccups where I had to step in and perform git-surgery and explain to them how things work a bit better.

>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.

It sounds like someone needs to have a conversation with this engineer. I personally wouldn't want a single engineer on my team or company that has a resistance to learning new skills. Learning new things and better ways to do those things is basically the job description. Hopefully they have a good reason other than being obstinate otherwise they might need to find a new company that tolerates mediocrity :/

Re: CLI: Improved

#40

Post by stirner »

>The talk reviews reasons for UNIX's popularity and shows, using UCB cat as a primary example, how UNIX has grown fat. cat isn't for printing files with line numbers, it isn't for compressing multiple blank lines, it's not for looking at non-printing ASCII characters, it's for concatenating files.

>We are reminded that ls isn't the place for code to break a single column into multiple ones, and that mailnews shouldn't have its own more processing or joke encryption code.

Post reply on HN