You might consider: https://github.com/c-blake/bu/blob/main/doc/cols.md

That's in Nim, though that may not be much a barrier. (There may also be other tools in bu/ of interest.)

You can do it with cut too:

    $ echo "key:     value" | cut -wf 2
    value

but whether it's actually "simpler" is open to debate

edit: actually gnu cut lacks -w, so this is bsd-only. lol computers, stick with awk

What does -w do? This works without it, no?

Edit, found it, "use whitespace as the delimiter"

https://www.unix.com/man-page/FreeBSD/1/cut/

For most cases like the OP you'd know the delimiter anyway so I don't think the absence is a big deal, and if not it would be easy to use tr or sed to make it consistent

the important thing is that it uses _consecutive_ whitespace as a the delimiter, so you'd have to use sed to collapse all the whitespace down to one tab.

At that point, awk is vastly simpler

Only with FreeBSD `cut`.. coreutils `cut` (Linux) is missing -w as is at least OpenBSD?

EDIT: I see you discovered this. lol computers indeed. ;-)

I can't tell you how many times I pipe in rev to put my text where I want it for cut (then rev it again).

Abbreviated example, getting the service names from a k8s cluster looks roughly like (actual command does a bit more processing):

kubectl get deployments -o wide | rev | cut -d'=' -f1 | rev

But if it's just gobbling whitespace, xargs without a command can be your friend.

$ echo "key: value" | cut -d: -f2 | xargs

value

My brain generally goes "rev sed head tail xargs cut tr ... screw it, I'll use python ... someday I shall learn awk." There's a young engineer on my team that knows awk, and I'm envious.

Neat, but both your tricks (rev and xargs) are more for getting the last word than getting the nth word.

For the sake of the argument, say I have the following fixed output and want the sizes:

    $ ls -l
    -rw-rw-r-- 1 userAAA group      588 Aug 29 00:25 file1
    -rw-rw-r-- 1 userAA  groupB   11870 Aug 29 00:24 file2
    -rw-rw-r-- 1 userA   groupBB   1166 Aug 28 23:56 file3
    -rw-rw-r-- 1 user    groupBBB   195 Aug 28 23:56 file4

I would just do:

    $ ls -l | awk '{print $5}'

You don’t even need to know awk these days. Just say “how to do x munging task” in ChatGPT and you’ll get a one liner that will be just as good as if you’d say there squinting at man pages for 30 minutes

this is exactly the sort of case where you get non-portable bullshit you don't understand out of it! It spits out something that works on BSD but not on GNU, you put it in your script and _boom_ wonder why the thing blew up in prod, and oh btw you also lack the ability to debug it because you never understood it in the first place

More importantly it's just mega slow.

The whole point of bash one liners is not to write short bash, it's to type it in your shell to get a result quickly.

Just typing the url to chatgpt in my browser I would have had the time to write my one liner in she'll XD

I sincerely doubt unless you are writing shell all day every day that you will get a decently complex working one liner out faster than GPT4.

Right, but you are bending the argument to your will.

What is a "decently complex one liner"?

If it's decently complex, then it's probably not a one liner, so indeed chatgpt may be faster.

If it's a one liner, then it's probably not complex, so I would be quite confident in being faster than chatgpt.

The reality is, 99.9% of one liners are just series of pipes and filters to extract specific fields from an output, and act on it. I'm quite confident I would be faster than chatgpt for any of these. And no, I don't write bash "all day, every day".

I tend to see "every day bash" as very similar to SQL. Once you know cut, grep, find, sed and awk, even at a basic level, then you can combine them and extract pretty much anything.

One example of what I call “decently complex one liner” that I had ChatGPT write the code for the other day is a command to find top n files of a given pattern in a certain directory, sorted by n in terms of most recently modified. Sure that is reasonably fast to write yourself if you know shell pretty well but why bother when I can just input my requirements and get something that immediately works without squinting at man pages and checking my patterns on regex101? In the time it takes to write out that two sectioned pipe command I’ve already solved it by pasting my requirements into the AI.

SQL is a great example too where I will use an AI even though it’s not necessary. I’ve probably written many tens or hundred thousands of lines of SQL in my life and I would still prefer to just toss my requirements into an AI and have it write the query for me so I don’t have to cross reference things and look up syntax. Easier to do that and iterate on it once or twice than comb through some bigquery or Postgres docs because I can’t remember that particular flavor of sql today

Meh, I don’t think that is a problem endemic to shell specifically. That’s more of putting untested code in production. The thing about the fact that is a one liner is… if that happens and it’s not portable, who cares? You just turn around, paste that sucker back in, and say make it work on OsFlavor2.06 and you get back something that works. You don’t even have to fully understand why it isn’t portable, you can just ask the AI and have it explain why. If you wanted something battle tested in prod you wouldn’t be using one line shell scripts in the first place

Check out https://github.com/sstadick/hck and https://github.com/theryangeary/choose - both are alternatives for cut/awk and allows regex based split as well. Though, they don't remove starting/ending whitespaces IIRC.

I wrote a script (https://github.com/learnbyexample/regexp-cut) that uses `awk` to provide a `cut`-like tool with regex-based split, negative index, etc. And this will take care of starting/ending whitespaces as that's the default `awk` behavior.

I think you mean

    echo "key:     value" | awk '{print $2}'