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.
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.
- 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
echo -e "foo bar baz" | rev | cut -d ' ' -f 1 | rev
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.
If you give cut columns which don't exist, it's going to output the entire source as-is.