Hacker News Reader

Comment by asicsp | Hacker News Reader

Not sure why it is even compared to awk instead of just cut. It could've been introduced as cut-like command with regex input field separator. Or at least not say things like:

>However, the awk command is not ideal for rapid shell use

And

>cut is far from ideal for rapid shell use, because of its confusing syntax

anything new is confusing until you learn enough to be comfortable

>ranges are just plain difficult to get right on the first try

and how does choose become easy to use with ':' character instead of '-'

Is this a typo or does inclusive/exclusive depend on whether first number is specified?

>choose 2:5 # print everything from the 2nd to 5th item on the line, _inclusive_ of the 5th

>choose :3 # print the beginning of the line to the 3rd item _exclusive_

View on HN

I heard those arguments when ag went out as an alternative to grep, and ffind as an alternative to find.

But now, I install their successors, ripgrep and fdfind, on all my machines. Including the windows ones.

I do not have an issue with this command, regex field separator and negative index alone makes it a good alternative over cut. And I use ripgrep too. I'm bothered by the description.

I would even suggest the command to add ability to invert the ranges, byte selection (if -c is character and not byte selection), add examples for character splitting in README, etc.

There are literally thousands of Unix tool replacements released on GitHub, and more every year.

Just off the top of my head, fex and miller are alternative cut-likes with field extraction.

Unless a new unix-tool-alike is significantly better and backwards-compatible, HN and most greybeard nixers tend toward conservatism. The old tools are usually good for 95% of use-cases anyway. There's just way too much to keep track of if you're eager to switch to any old shiny new thing.

Tools like rg offer additional features and/or save you from tediously specifying many options. This one gives you -f for free, that’s about it. Detailed comparison: https://news.ycombinator.com/edit?id=23445931

- it supports regex separators. That's a great feature to me.

- the default separator is "\s", like python's split(). Just for that I will adopt it: not having to care about tabs/spaces/mixes is a much better experience.

- it has negative indexes, again like python. Getting the last field, or the last nth field, is something common enought. I don't want to rewrite the thing with a twisted double "rev" with proper index. And I don't want to have to google it.

- plus the syntax is just must easier to remember to me. When I use cut, I always try: "echo 'foo bar baz' | cut 2", just to realize that I need to pass '-f', then I do "cut -f 2", and get stump, and google it, to then remember I need to pass the delimiter explicitly even if it's a space.

- it works the same on windows. I dual boot.

Compare:

    echo -e "foo bar baz" | choose -1

To:

    echo -e "foo bar baz" | rev | cut -d ' ' -f 1 | rev

cut is, to me, the opposite of a friendly API.

Something so basic in the Unix world should have sane default.

Default are not sane if I have to google it once out of two.

One more great feature of choose which cut doesn't have: not returning garbage output on garbage input.

If you give cut columns which don't exist, it's going to output the entire source as-is.

> Is this a typo or does inclusive/exclusive depend on whether first number is specified?

I hope it's a typo given:

> choose -3:-1 # print the last three items from a line

is clearly inclusive (otherwise it'd print but the last one), and there's a very explicit flag for inclusive ranges. Might be a good idea to open an issue just in case.

I not sure how to feel wrt using Python's range syntax with different inclusivity (by default) though.

edit: after installing and testing, it does seem like an error in the readme, the end is inclusive whether a start is provided or not. That is, `:3`, `0:3` and `1:3` all yield the 4th field.

Reply on news.ycombinator.com