[asicsp]

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_

[BiteCode_dev]

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.

[asicsp]

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.

[rwnspace]

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.

[oefrha]

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

[BiteCode_dev]

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

[masklinn]

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.

[masklinn]

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