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.
True, but we cannot possible learn all the things. I wrote a nice little batch script last week with the help of ChatGPT. This is something I have to do maybe once or twice a year and I am sure someone who does this every day was a lot faster, but what took me maybe 30 mins would've taken me a day.
I agree. Here it's being used like a translation app: convert English into the shell language. That's all well and good for a place you're going to visit a couple of times, but if you plan on living there, you need to learn the local language.
I like this method. The problem with it is that there's just too much stuff to know. So let me teach you another method. Don't try to know everything, learn to get things from other resources, one of which is chatGPT. Worth the investment to be wise about what you pick and choose to learn.
For me bash is a weird exception to the rule "code is easier to write than it is read". I'm never doing anything crazy in a shell a script but it's easy to just ask ChatGPT to whip it up for me and I will read it to verify. Perhaps anybody who can't validate the output is just as likely to write an accidentally-destructive script the old fashioned way.
Have you actually tried it? Because this comment seems pretty misplaced with the reality of what ChatGPT can accomplish. I also use it all the time for bash one-liners, and so far my experience has been "80% work correctly on the first try, 15% require minor adjustment to run, 5% require major adjustment to run" and so far none have ever done anything flagrantly wrong or destructive. It also doesn't just print a command with no context: it explains what each flag/step of the command is purportedly doing, which you can (and should!) use to double-check that what you're about to run makes sense. Which is more than I can say for a lot of SO answers!
Traditionally, the alternative wasn't "SO answers", which are indeed dangerous in their own way -- it was to develop, and then maintain, a comprehensive and fluent understanding of the tools suitable to your profession.
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.
A master carpenter that only uses hand tools is a master of their craft, and should be respected as such, but refusing to ever use power tools because of a moral objection to electricity would be seen as quite the eccentricity. Which, the Amish sell furniture, and it's really quite good, if niche, furniture.
I've used chatGPT(ver 4 through ChATGPT plus) for creating .bat files. Really easy ones, it can churn out quite well. A lil more complicated - it doesn't consider edge cases. Several cases require me to ask it to generate a golang program that gets called by the .bat file.
Several times, I had to spend hours to get a .bat script working. Hopefully, it will get better in the future.
I used chat gpt to explain what a complex line in a bash script was doing. Though to be fair if I'd spent a day in man pages and Google I'd probably have learned a lot more than just being given the answer.
Which makes think in the long run gpt may result in worse programmers.
In the same way as Stack Overflow has resulted in worse programmers, at least in some senses.
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.
And a generation before that, it was VB and (early) PHP programmers that earned that critique.
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 one of my BIGGEST frustrations learning to program. i do...not...want....to go online to work out hooow to do something. I want a "manual" - written well...that i can study and find the write tools to use...which for example (Pythons docs...are not...at least for beginners) - i then want to use the tools in said manual....to create. With the syntax, and the words you've defined oh so well in said manual. But...as the language grows...we'll just have to live with this never happening :)
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.
What's better: spending a day figuring out a single line of a complex Bash script, or spending that same day learning literally 100x more because you didn't have to waste that much effort on each individual thing?
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.
Losing interest and not figuring it out at all has been my approach to nontrivial bash. I'm not a UNIX philosophy fan in general, but trying to bea programming language and also a UI, all in one, is a bit much. It's ok-ish as a UI for cases where GUI doesn't work or you want a machine to be able to use the UI, but as a language it's missing a lot of stuff.
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.
This statement implies that LLM hallucinations are completely random which is objectively false.
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.
So what? Review and test it before running in production. Humans also screw things up on first attempts. Test it, check the output, fix it, try again. In my experience with GPT-4 if you describe a bug it will correct it.
I haven't tried GPT for this purpose but I don't think we need to assume that everyone tinkering with it are blindly copy pasting potentially destructive commands.
Anyone who does that now would already have done it from random Google results anyway.
It’s really useful for learning. “Describe this complex bash command I found on stack overflow line-by-line”. Write a quiz question to make sure I understand it. Rate my response to this quiz question.
You can also (surprisingly) ask ChatGPT for validation. The part of the LLM that activates when solving problems is going to be different than the one that activates when reviewing.
Just last week I was asked to provide some possible screening questions to recruit for a Devops role. I figured this would be good:
"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.
That's an unwise way to filter out candidates. It's an obscure and unimportant syntax feature whose effect can be accomplished in many other, more readable ways. Writing line noise using obscure syntax is not a sign of a good programmer. If you want to find good candidates, give them an assignment in bash and make them explain their solution.
I am very proficient in Bash. My day job is as a Senior DevOps engineer. If I were doing an interview and was asked that question, I would never give the answer `${1:?}` (if I even remember at the time that it existed) because it is terrible code. It is obscure and unreadable.
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.
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.
For tasks you do regularly, it's worth the investment to learn.