Live data from Hacker News

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

github.com

41–49 of 49 posts

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

#41
post #36

I am not sure why being zero-indexed is considered a feature. I have no problem using a zero-indexed system, but I've never really thought of it as a feature. Is there something I'm missing that makes zero-indexed systems faster, easier to use or otherwise better than one-indexed system?

There's a better reason than this that I'm forgetting, but never underestimate the power of being the same as what people are already familiar with. Every time I have to write lua or read some Matlab, the mental overhead of having to remember everything is one-indexed is just incredibly annoying.

Anyone used to command-line tools is used to fields being 1-indexed.

awk uses $0 as the whole line, and $1 as the first field. cut uses -f1 as the first field $1 is the first argument to a posix shell script /1 is the first matched reference in a sed $1 is the first regex match in perl

A command-line tool being 0-indexed breaks from expectation of what everybody is used to using on the command line.

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

#42

I think it is very cool that Rust has led to a renaissance of rewriting classic Unix tools to make them fit more with current use. Unix was never meant to stand still. It just happened that AT&T broke up and it took a while for Linux to catch up, and by then people got used to the idea of a fixed set of POSIX utilities. But their CLIs are often quite bad, and security was never a consideration in the olden days, so i…

> I think it is very cool that Rust has led to a renaissance of rewriting classic Unix tools to make them fit more with current use. Unix was never meant to stand still.

Technically it has not, even for the core tools they've been getting extended, usually incompatibly, in both GNU and BSD lineages. Though it's pretty funny how much the rust community has been taken up by providing alternatives and replacements for "classic" (POSIX) utilities.

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

#44
post #41
post #36

Earlier quoted context omitted.

There's a better reason than this that I'm forgetting, but never underestimate the power of being the same as what people are already familiar with. Every time I have to write lua or read some Matlab, the mental overhead of having to remember everything is one-indexed is just incredibly annoying.

Anyone used to command-line tools is used to fields being 1-indexed. awk uses $0 as the whole line, and $1 as the first field. cut uses -f1 as the first field $1 is the first argument to a posix shell script /1 is the first matched reference in a sed $1 is the first regex match in perl A command-line tool being 0-indexed breaks from expectation of what everybody is used to using on the command line.

Anyone is a generalization based on a narrow viewpoint. I would say I am pretty used to command-line tools at this point, at least enough to be using linux as a daily driver comfortably. And I frankly I didn't know 1-indexed fields were the norm, even though I knew $1 is the first argument to a poxis shell script (I always assumed $0 referred to the script or command itself).

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

#46

I think it is very cool that Rust has led to a renaissance of rewriting classic Unix tools to make them fit more with current use. Unix was never meant to stand still. It just happened that AT&T broke up and it took a while for Linux to catch up, and by then people got used to the idea of a fixed set of POSIX utilities. But their CLIs are often quite bad, and security was never a consideration in the olden days, so i…

> I think it is very cool that Rust has led to a renaissance of rewriting classic Unix tools to make them fit more with current use. Unix was never meant to stand still. Technically it has not, even for the core tools they've been getting extended, usually incompatibly, in both GNU and BSD lineages. Though it's pretty funny how much the rust community has been taken up by providing alternatives and replacements for "…

While development has not stopped, there haven't really been many advances in improving the syntax. Many of these tools are stuck in awkard, unintuitive syntax, which is cumbersome unless you use them frequently. I feel like the renaissance has lately been one of usability, which I personally really appreciate. Obviously, hard-core daily users would disagree, but considering I use `awk` at most once every 6 months, I hate that I need to spend 20 minutes re-learning how to use it every single time, particularly for basic purposes.

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

#47
post #41

Earlier quoted context omitted.

Anyone used to command-line tools is used to fields being 1-indexed. awk uses $0 as the whole line, and $1 as the first field. cut uses -f1 as the first field $1 is the first argument to a posix shell script /1 is the first matched reference in a sed $1 is the first regex match in perl A command-line tool being 0-indexed breaks from expectation of what everybody is used to using on the command line.

Anyone is a generalization based on a narrow viewpoint. I would say I am pretty used to command-line tools at this point, at least enough to be using linux as a daily driver comfortably. And I frankly I didn't know 1-indexed fields were the norm, even though I knew $1 is the first argument to a poxis shell script (I always assumed $0 referred to the script or command itself).

That's fair, I overgeneralized.

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

#48
post #41
post #36

Earlier quoted context omitted.

There's a better reason than this that I'm forgetting, but never underestimate the power of being the same as what people are already familiar with. Every time I have to write lua or read some Matlab, the mental overhead of having to remember everything is one-indexed is just incredibly annoying.

Anyone used to command-line tools is used to fields being 1-indexed. awk uses $0 as the whole line, and $1 as the first field. cut uses -f1 as the first field $1 is the first argument to a posix shell script /1 is the first matched reference in a sed $1 is the first regex match in perl A command-line tool being 0-indexed breaks from expectation of what everybody is used to using on the command line.

I get what you're saying, but to be more general I'd argue that's just 0 indexing with the API specifying what's in what index.

I'd more "formally" define 0/1 indexing as:

Zero indexing: arr[0] is a valid way to address the first element of an array, and len(arr) - 1 is the index to the final element.

One indexing: arr[0] results in an error or an out of bounds access, and len(arr) is the index to the final element.

These statements are true in Matlab, but not most command line tools.

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

#49

Earlier quoted context omitted.

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

Agreed. In fact, anybody promoting cut, please give me the cut version of: echo -e "foo bar baz" | choose -1 -2 It should work on an arbitrary number of spaces, and fields. The oneliner is going to be... interesting. Now you can do it with awk using: echo -e "foo bar baz" | awk '{ print $NF " " $(NF-1)}' But it's neither easy to type, nor to remember. Choose is what cut should have been.

cut? I don't even leave the shell.

echo ... |while read a b x ;do ... ;done

Post reply on HN