Thanks for the recommendation. In my case, GPT revolutionized the way I use bash. If you know what you want to accomplish, gone are the days of endlessly fiddling around with syntax.
For tasks you do regularly, it's worth the investment to learn.
But there is so much to know one short life
I use Perl, now, for shell scripts. Long before LLMs I decided I could not learn another syntax when Perl was 99% as good
Same reason I have not learnt Sed and Awk.
Once I write the document string of the function I want it gets it right faster than anyone I know.
I don’t mean to bash on SO, it’s really valuable sometimes. But corporate culture (faster is always better) and a new breed of programmers that don’t really care, have left us with a big part of the profession that are unable to produce anything new, or solve any unique problems.
It does feel like the proportions might be changing and the quality of software is trending downward, but I think you have it right that the risk of programmers being too "GPT-reliant" is the continuation of a long, intergenerational pattern.
this is something i get jealous of older programmers who grew up on old computers, with printed manuals...when languages were smaller, and the scope of programs were also smaller...and didnt require external libraries.
Now, it is kinda expected that programs support "text" - non-lgc alphabets, context-sensitive collations, ligatures and cursive text, mixed bidirectional text, combining characters, input method support, locale-dependent string interpolation logic.
And one doen't simply handle all of that, not without bolting something else in your program that is probably larger that your program.
And that isn't even instants in time; those are much harder to handle correctly all the time.
For me, the alternative to using ChatGPT to figure some weird piece of Bash trivial out isn't doing the work myself, meticulously and at great length. It's losing interest and not figuring that thing out at all.
GPT and SO can help you make a deadline today, and we all may use them now and then, but consistently relying on them steals essential opportunities for professional growth.
A journeyman woodworker who just asked somebody else to perform all his tricky jigsaw cuts is going to have a hard time developing the muscle memory and intuitions that mark mastery of the craft.
Several times, I had to spend hours to get a .bat script working. Hopefully, it will get better in the future.
I like this idea. Definitely gonna steal it.
I love that "extensions" can be implemented just by writing a couple extra words.
I use LLMs for the latter, and they often do a great job and save a lot of time looking up individual flags, concepts, etc.
As can I. I recently broke my years long streak of not deleting something by accident with an errant bash command.
Just because a tool has the potential for a negative outcome doesn't mean it shouldn't be used. It just means appropriate caution should be used as well.
LLMs fill in the blanks when left to synthesize a response from a prompt as opposed to translating a response from a prompt. These synthesized responses, aka hallucinations, are predictable in nature. Quotes, titles of books, web page links, etc.
Conversely, providing an LLM with all of the facts necessary to complete a response will result in few to no hallucinations.
For example:
Select name and row_id from table1 joined on table2 on table1_id.
This will never return "DROP table1;". It will basically only ever return something very close to what you want.
A LLM will give you the highest likely suggestion. If that happens to be a DROP, it will not stop.
Now that is of course going to be extremely unlikely in your example. What is more likely though is that your SELECT may include a sql injection vulnerability, even more so once your prompts get more complex. The chance of that happening or not, is completely random from a users point of view. Are we going to blame the user for not providing the requirement “without vulnerabilities”? Even if they did, it’s not sure to be fulfilled.
In this parent case, the scenario was inverted. Given a sql query, will gpt explain if it has vulnerabilities or not? Will it even explain the gist of it correct? Who knows if it will hallucinate or not?
As will answers from stackoverflow, always read the comments, always review yourself.
Use gpt all you want. I do it it myself, it’s great for suggestions. Just think that using gpt to explain things you don’t understand and can’t verify easily, can be risky. Even more so in bash where the difference making a destructive command can be a lot more subtle than select vs drop.
The OpenAI API now has support for deterministic responses.
There you go, the burden of proof is on the accuser.
If I were to state “you can never ride your bicycle to the moon”, you could easily say, well, there is a remote possibility, and then force me to prove that there actually is no remote possibility, well, you would clearly see the problem.
I’ll state it again: you will never ride your bicycle to the moon and ChatGPT will never return “DROP table1;” in response to the aforementioned request. It might not be correct, but it won’t be wildly off target like is flippantly suggested in these forums for populist appeal.
My entire point was that hallucinations are not random. If you craft a query that reduces the task to mere translation then you will not get some wildly incorrect response like you would if you asked for quotes from War and Peace.
I’m pretty much convinced that most of the shade against LLMs from developers is motivated more by emotion than reason because this stuff is easily verifiable. To not have realized this means approaching the tools willingly blindfolded!
If I encounter a new unknown command and ask chatgpt to explain it. For me, it is entirely unpredictable if the answer will be 100% correct, 95% correct or complete mansplaining bullshit.
Even if it may be close to the truth, with bash the difference between a 95% answer and a 100% answer can be very subtle, with seemingly correct code and seemingly correct explanation give very wrong end result.
https://cookbook.openai.com/examples/deterministic_outputs_w...
Now go find some instances where someone is presented with "rm -rf /" or "DROP table1;" when otherwise expecting a response to help with non-destructive commands!
For me, it is entirely unpredictable if the answer will be 100% correct, 95% correct or complete mansplaining bullshit.
Please, show me some evidence of this variance because it is either a bold or ignorant claim to say that the outputs are wildly unpredictable. 100% true vs "complete mansplaining bullshit". Run the numbers! Do 10,000 responses and analyze the results! Show me! I am completely unconvinced by your arguments based on direct experience with reality. You can easily change my mind by presenting me with reproducible evidence to the contrary of my beliefs and experiences.
Even if it may be close to the truth
This is just a classic motte-and-bailey fallacy... let me explain! The bailey is the claim that the outputs are "complete mansplaining bullshit", which is very hard to defend. The motte that you retreat to, "close to the truth", is exactly what I'm saying for prompts that are more of a translation from one language to another, English to bash, English to SQL, etc.
I have never claimed it would be 100% correct, just that the hallucinations are very predictable in nature (not in exactness, in nature). Here's an example of the kind of error:
Select name and row_id from table1 joined on table2 on table1_id.
SELECT table1.name, table2.row_id
FROM table1
JOIN table2 ON table1.table1_id = table2.table1_id;
Anyone who does that now would already have done it from random Google results anyway.
Or `chown -r` or was it.. `chown -R`
"How do you pass a parameter to a Bash script so that the script will exit with an error if it's not passed?"
I ran this through ChatGPT and I could not get it to give ${1:?} or any variation of that syntax as an answer. So now I also have a way to filter candidates who are leaning on the LLM during the interview process.
Because without checking `man` or stackoverflow (or leaning on ChatGTP) my first response would be to go with `if [ $# -lt 1 ]; ...`. This has the advantage of being pretty readable, and while I've been doing shell scripting for long enough to consider myself reasonably competent at it, I'd have to refer to the man page to be sure what `${1:?}` did.
The substance of the first answer:
#!/bin/bash
# Check if the first parameter is not provided
if [ -z "$1" ]; then
echo "Error: Parameter not provided."
exit 1
fi
> This checks if the first parameter (`$1`) is empty.
But what happened to the supplied task? It was stated and echoed as:
> Anonymous: ...if it's not passed?
> ChatGPT: ...if a specific parameter is not passed...
> ChatGPT: ...if the parameter is set.
The second answer:
#!/bin/bash
: ${1?"Error: Parameter not provided"}
> ...and the `${1?...}` part checks if the first positional parameter (`$1`) is unset or null.
--
(the most succinct possible idiom is `#!/bin/bash -u`)
The goal of a DevOps engineer should be to write maintainable code so that a junior can come in and tell what it does immediately.
As another commenter said, my answer would be: `[[ $# -ne 1 ]] && exit 1`. That's readable and understandable to anyone who has a basic understanding of bash scripting.