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

51–60 of 280 posts

Re: CLI: Improved

#51

Post by barbegal »

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool.

I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking about text parsing and more time thinking about the data you're working with.

I think the command line is great as a way of manipulating data streams but it is incredibly lacking as a user interface. There is very little consistency of the interface between commands and new commands and options aren't easily discoverable.

Re: CLI: Improved

#52

Post by saagarjha »

> There is a weird bug in Mac Sierra that can be overcome by running htop as root

I don't think this was a bug; I think the issue was that htop uses needed something in task_for_pid that required root.

Re: CLI: Improved

#53

Post by pletnes »

burntsushi wrote: post #33
jolmg wrote: post #30

Earlier quoted context omitted.

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?

ag is made to search code specifically. grep is a more general purpose text search tool and better suited (imho) for handling data (in contrast to code). Also, it’s always installed. I’ve never been on a machine with ag unless if I’ve installed it myself.

Re: CLI: Improved

#54

Post by alexeldeib »

merlincorey wrote: post #49
AnIdiotOnTheNet wrote: post #42

Earlier quoted context omitted.

I don't feel the plain text portion has aged well at all in regards to composability. It leads to a lot of headache as the complexity of the task grows because of the in-band signaling and lack of universal format. I think it is high time the standard unix tools were replaced with modern equivalents that had a consistent naming scheme and pipelined typed object data instead of plain text.

I think you should check out Powershell.

This made me chuckle, because it's incredibly accurate. I started with bash and am still naturally more comfortable there for general purpose work. PowerShell is annoyingly verbose sometimes and has its own WTF moments, but there are waaay fewer surprises when working with complex scripts and variables.

Re: CLI: Improved

#55

Post by burntsushi »

barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability.

However, from my own observations (and my own use), folks seem to appreciate having some amount of coupling and integration here. I've often seen folks claim that a legitimate use case (for them) for ripgrep is to "replace crazy 'find ./ ... | xargs' concoctions." The degree to which the aforementioned is "crazy" or not varies based on the individual, but there's a not insubstantial number of people who appreciate the succinctness that coupling brings.

As the maintainer, the coupling is annoying, because it means ripgrep needs to implement more stuff. For example, ripgrep provides a `--sort-files` option, which is something that standard grep doesn't need because you can fairly easy compose its output with 'sort'. You could do the same with ripgrep (ripgrep supports the standard composable grep output format), but then you lose the "pretty styling" that users appreciate. So you have no choice.

In terms of giving more structure to output, I am mostly unconvinced by your argument, but I've been happily using text streams as my user interface for a very long time, and I like its balance.

With that said, the next release of ripgrep will come with a --json flag, which enables structured output. :-)

Re: CLI: Improved

#56

Post by demosito666 »

barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

This is correct. The thing is, powershell is not for humans. It is purposed more towards configuration and system scipting, and thus should be compared to something like ansible. Using it as a shell is counter-productive unless you have very specific mindset.

Unix shell, on the other hand, is a trade-off: it offers you options to process and automate and reasonable convenience when working interactively. None of those aspects is perfect, of course, but it allows gradual learning curve (i.e. being able to do quick and dirty things from the beginning), is much more versatile and ubiquitous.

Re: CLI: Improved

#57

Post by burntsushi »

pletnes wrote: post #53
burntsushi wrote: post #33

Earlier quoted context omitted.

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?

ag is made to search code specifically. grep is a more general purpose text search tool and better suited (imho) for handling data (in contrast to code). Also, it’s always installed. I’ve never been on a machine with ag unless if I’ve installed it myself.

Errmm, yes, I'm familiar with the difference in motivations behind the tools. I guess what I'm looking for is specific examples of things that cause you to use grep instead of ag. Ubiquity is a good one. But let's say you have both ag and grep. When do you reach for one and why?

(I should have said this in my first comment, but I'm the author of ripgrep, and I'm just generally interested in learning more about the differing use cases for these tools, in the words of users. I certainly have my own ideas about the question!)

Re: CLI: Improved

#58

Post by vram22 »

hs86 wrote: post #4

With tools like these or ripgrep it is useful to know whether the authors try to replace the old tool or not. This is usually stated somewhere in their readme or faq. If they choose to approach some problems with different semantics, I would not recommend to alias the new tool over the old one. Just treat it as a like a separate tool and in most cases their new names are as comfortable to type as the 'legacy' tool's.…

Yes, I was thinking about exa and ripgrep recently, since I am going to write a couple of tools (very loosely) like ls/find and grep in a while (for learning and as tutorials). Thought the same as you, that for a command that is to be typed so often as ls, exa is a bit longer (even though just one letter). Of course it can be aliased to a shorter name or one can write a shell script wrapper for it. The point about single hand vs. both is a good one, that had not occurred to me.

Edited to change: like them to: like ls/find and grep

which is what I should have written originally.

Re: CLI: Improved

#59

Post by shimon »

dijit wrote: post #35
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 perceiv…

The Python Paradox (2004): http://www.paulgraham.com/pypar.html

The name may not have aged well...

Re: CLI: Improved

#60

Post by jolmg »

burntsushi wrote: post #33
jolmg wrote: post #30

Earlier quoted context omitted.

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?

Well there's the portability of grep which is better for scripts. Besides that, most if not all times I do a simple `ag pattern file`, I'm interested only in the results and not in the location. I'm probably preparing the pattern to output something to provide to another command via stdin or substitution and at those times (which is also in the interactive command line), I want to see exactly what I'm going to pass in. To remove the numbers ag adds by default, I have to use --nonumbers, which is weirdly long given that one of the main benefits of ag is the brevity of the commands (ag is short and easy to type, no need to include options -r, -i, -P, or -n (when needed)). Instead of using that option, I just switch to grep. I really wish ag changed that default to be consistent with grep and ack or at least change the way its options are negated, like making it a short option and negating like +N.

EDIT: I just saw your comment where you stated you're the author of rg. I honestly haven't tried it before until now. It seems you also chose to output line numbers by default in that case, but it's nice that you have -N. If you don't mind me asking, do you have an option like ag's undocumented -W which allows specifying a max line width for which a matching line is displayed? Regularly when searching a hierarchy a match happens on a generated file where everything is on a single line and so my terminal prints the millions of characters line. -W displays an bracketed ellipsis once the max width is reached on a line.

Post reply on HN