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.
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 missed: regex separator instead of just character list.
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.
echo -e "foo bar baz" | choose -1 -2Also 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.
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 portable.
I, for one, never remember the syntax for cut. If "choose" gets a deb, I'll use it: Python slicing is something familiar to me.
I don't care if cut is on every unix system: if I have the possibility to install things on the machine, then I'll just install what I need. I have a script for that. If I don't, I'll google/man/--help GNU commands as usual.
And as for writing shell scripts, I use Python anyway.
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.
This actually makes choose a cut-killer for me. It can be frustrating having to figure out which delimiters to use - tabs or spaces? If spaces, you'll have to chain it with tr, or resort to awk.
>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_
But now, I install their successors, ripgrep and fdfind, on all my machines. Including the windows ones.
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.
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.
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.
$ echo "1,2,3,4,5" | cut -d , -f 1,3
1,3
$ echo "1,2,3,4,5" | cut -d , -f 3,1
1,3 $ echo "1,2,3,4,5" | choose -f , 2 0
3 1
$ echo "1,2,3,4,5" | choose -f , 2:0
3 2 1
awk -F, '{print $3","$1}'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.
$ echo " a b c" | choose 1 2
b c
$ echo " a b c" | python3 -c 'import sys; [print(f[1], f[2]) for line in sys.stdin if (f := line.split()) or True]'
b cThis pain is real: https://xkcd.com/1168/
If it is more comfortable to use for some people then it’s a great invention.
echo -e "foo bar baz" | choose -1 -2
echo -e "foo bar baz" | xargs | cut -d\ -f1,2