You'd think that, but I had an auditor that had guidance requesting confirmation of security cameras on the servers. They wanted to drive to the AWS data center to see the cameras. If the drives got stolen, you'd better make sure AWS shares that video with you.
Ok, but what if someone bypasses the cameras on your servers with looped footage? Did the auditor think about having security cameras on the security cameras?
This was my introduction to K3s as well. RPis running K3s with enough resources left over to actually do some small tasks. I hosted a small data pipeline that analyzed trading data from an MMO. It was as fun as it was impractical, and I learned quite a bit.
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.
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
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 that was readable and understandable you wouldn’t be using one line shell scripts in the first place, regardless of whether they were written by an AI or not
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
I've been out of grad school for a bit now, but 10 years ago is about right. There were a lot of things being published about compilers that might have well been direct ports of papers written in the 70s, "now for JITs." And honestly, if you read some of those papers from the 70s about automatic parallelization and such, it was pretty freakin' cool. And there were memory guarantees in Fortran that were not present in C that made it non-applicable. Java had most/all of those guarantees, which is what I think brought about their revival. That's probably not the whole explanation, as I'm not sure why it took Java so long (these were 2010+ papers, 15+ years after Java came out).
In this type of scenario, it's sometimes because there are two or more implementors that are trying to develop the standard in a way that makes their existing implementation compliant. Likely there were existing scripts that relied on the behavior being specific to that implementation, so it was explicitly made optional, which is viewed as better than not adding the behavior to the standard at all. "May" is just a polite standards way of saying "Warning: check yourself before you wreck yourself."