The company I work for basically relies on use scripts to make any of our internal tools usable. Its kind of insane and makes on-boarding new employees somewhat difficult when they aren't even looking at the same UI as tenured people.
hahahah. A friend of mine has a problem with a contractor at his workplace that tries to PR in shell scripts written with Copilot. My friend spends an hour to explain why a script generated in 5 minutes is horrifically awful and will likely take down the company. He's legitimately angry about it.
They're called scriptkiddies: they have just enough technical know-how to hang themselves, more or less. Enough to copy and paste lines into a terminal window.
I sympathize but amusingly I have the opposite problem. Most of the time I want it to output a full script, and it only wants to output a small block with changes unless I plead with it to include everything.
I'd say many, not most, are capable of writing small scripts that save them time at work for small tasks.
It all falls apart when they try to turn it into software that does multiple things, has a GUI, is useful for anyone not using their specific machine setup a particular way, has error handling instead of checking the work output manually, etc.
If your script is over 80-120 lines, it's time for modularization. No sane person writes 1000 line scripts, and the fact that the Oil author uses such a scenario as a reason to use their shell is very disconcerting about the quality of code and I wouldn't touch Oil with a ten-foot pole.
Genuinely curious: How much time would you say you saved prompting for and then carefully reviewing and testing those scripts for bugs, versus writing them yourself?
And for context what's the average line count we're talking about here? Tens of lines? Hundreds?
But tiny throwaway scripts get built up into huge applications all the time, sometimes by other people who don't have the mental TODO to go back and handle errors.
This is a developer's answer to a business problem. Scriptability added to a non-developer's tool is usually just enough rope to hang them on IME, and often ends up in a whole arsenal of footguns.
I have 90 scripts in my /etc/init.d directory. 51 are less than 100 lines, the most recent one I created is actually a perl script which is 29 lines long.
Those 'quick n dirty scripts' will work for you (and work well) but when others need to rely on them it gets messy. At my company we have 50 developers and everyone relies on "Jeff's script". No one really touches it because no one really gets it and Jeff might move across the country soon. :(
reply