Show HN: Choose – An alternative to cut and sometimes awk • Hacker News Board

Re: Show HN: Choose – An alternative to cut and sometimes awk

#11

Post by oefrha » Sun, Jun 07, 2020, 9:16 AM UTC

BiteCode_dev wrote: post #6

asicsp wrote: post #2

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 ge…

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.

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

Re: Show HN: Choose – An alternative to cut and sometimes awk

#12

Post by rwnspace » Sun, Jun 07, 2020, 9:21 AM UTC

BiteCode_dev wrote: post #6

asicsp wrote: post #2

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 ge…

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.

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.

Re: Show HN: Choose – An alternative to cut and sometimes awk

#13

Post by dirtydroog » Sun, Jun 07, 2020, 9:22 AM UTC

One annoying thing about cut is that it outputs the extracted fields in order of position, not the order you specify.

Other that that it's great, I use it every day

Re: Show HN: Choose – An alternative to cut and sometimes awk

#14

Post by asicsp » Sun, Jun 07, 2020, 9:26 AM UTC

BiteCode_dev wrote: post #7

Someone should make a bundle installer with this, bat, fdfind and ripgrep. I do enjoy those alternative to GNU, and install as many as I can: they are easier to use, usually faster, and just make more sense to my brain. This pain is real: https://xkcd.com/1168/

There is https://github.com/uutils/coreutils implemented in Rust

Re: Show HN: Choose – An alternative to cut and sometimes awk

#15

Post by BiteCode_dev » Sun, Jun 07, 2020, 9:34 AM UTC

asicsp wrote: post #14

BiteCode_dev wrote: post #7

Someone should make a bundle installer with this, bat, fdfind and ripgrep. I do enjoy those alternative to GNU, and install as many as I can: they are easier to use, usually faster, and just make more sense to my brain. This pain is real: https://xkcd.com/1168/

There is https://github.com/uutils/coreutils implemented in Rust

Yes but their goal seems to be API compatible, which I understand the point of, but is not useful to me.

Re: Show HN: Choose – An alternative to cut and sometimes awk

#16

Post by masklinn » Sun, Jun 07, 2020, 9:59 AM UTC

oefrha wrote: post #8

Hmm, so compared to cut this 1. saves -f because it doesn’t support cut’s -b and -c modes (edit: actually -c is supported, I just didn’t see it); 2. Uses -f instead of -d, making it rather confusing for cut users; 3. Uses : instead of - for range specifications; 4. Offers an exclusive indexing mode; 5. Misses a bunch of other cut features (assuming coreutils cut). Not sure I see much appeal... Edit: Another thing I m…

> Not sure I see much appeal…

The appeal is the same as replacing grep with a fancier searcher:

1. it has good and sensible defaults (field mode, also I'd have to check but hopefully and unlike cut it doesn't print the entire line when it's unhappy with the selection you asked for, that's worse error handling than ed) (edit: confirmed, if you give `choose` nonsensical selection it doesn't print anything e.g. if you ask `cut` for columns 10-15 of data with 3 columns it's going to print the source as-is, choose is properly going to print a bunch of empty lines, that alone makes it better than cut)

2. It works better on actual data, which is generally whitespace-separated rather than tab-separated, meaning cut requires preprocessing before it'll do anything of use

Can you massage cut or the data to fit? Yes, in the same way you can massage grep or your data to fit. That you don't have to and the utility behaves sensibly by default is appealing. This exact thing is one I've been thinking about for some time now, I'm glad somebody else agreed and did the legwork.

Re: Show HN: Choose – An alternative to cut and sometimes awk

#17

Post by BiteCode_dev » Sun, Jun 07, 2020, 10:01 AM UTC

oefrha wrote: post #11

BiteCode_dev wrote: post #6

Earlier quoted context omitted.

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.

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.

Re: Show HN: Choose – An alternative to cut and sometimes awk

#18

Post by masklinn » Sun, Jun 07, 2020, 10:02 AM UTC

BiteCode_dev wrote: post #4

xthetrfd wrote: post #3

I can't understand why you are mentioning awk. Cut or choose cannot be compared to awk, awk is a programming language. Also I don't think that it's so much easier to use than cut. On the other hand every *nix system has cut so if you make scripts with it they are portable.

> I can't understand why you are mentioning awk. Cut or choose cannot be compared to awk, awk is a programming language. Because 99% of awk IRL use is just as a fancier cut. It's very rare someone even sets a variable using awk. If you do it, you are a statistical rarity. > Also I don't think that it's so much easier to use than cut. On the other hand every *nix system has cut so if you make scripts with it they are…

> Because 99% of awk IRL use is just a as fancier cut.

You say "fancier", I say "working": since cut can't work on general whitespace without a pre-processing phase (e.g. tr), it simply doesn't work for the vast majority of the things I try to shove into it, and I pretty much always end up using awk instead.

Choose means my awk use will fall down by 99% or so.

Re: Show HN: Choose – An alternative to cut and sometimes awk

#19

Post by [deleted] » Sun, Jun 07, 2020, 10:05 AM UTC

LeonB wrote: post #9

jpxw wrote: post #5

What does this do that cut can’t?

This is a poor question as it invokes the Turing tarpit. (Why using any language that is higher level than machine code?) If it is more comfortable to use for some people then it’s a great invention.

[deleted]

Re: Show HN: Choose – An alternative to cut and sometimes awk

#20

Post by masklinn » Sun, Jun 07, 2020, 10:05 AM UTC

asicsp wrote: post #2

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 ge…

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