Ah, another reminder of my ex-coworker who wrote a script that:
* operated on production data (rather than beta/pre-prod data, or failing if stage is not specified) by default
* did not recognize `--help/-h` as flags, but would simply ignore them and continue to run
I'm not exactly happy in my role currently, but I'm a damn sight happier not having to deal with him anymore.
I have some scripts that are super useful but also should not be used by somebody who doesn't know exactly what they're doing, so I literally stick a `exit 1` or such in the header so a teammate can't run the script without having looked at it first.
As a part-time scripter (is there any other kind?) I'm ashamed to say that I often use shortcut flags because I looked up the functionality I needed and copy pasted without taking the time to even understand what all of the flags mean.
This advice is good not only for others but setting a standard for yourself where you take a moment to learn what exactly is going on.
It took me way too many years to figure out that any management script I write for myself and my co-workers should, by default, execute as a dry run operation.
I now put a -e/--execute flag on every destructive command; without that, the script will conduct some basic sanity checks and halt before making changes.
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.
Yeah, it's not a lowest common denominator scriptability option that's offered as default as is the case with CLI commands and flags -- it takes actual effort and thinking.
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.
I mean, if it’s got flags to represent what you’re asking it to do and you set the wrong flag that’s not a script issue. I can run rm -rf / and that’s not a fault of rm, that’s a behind the keyboard issue.
I think even back then, the reason was a poorly configured script running in (essentially) debug mode. You could turn off detailed error messages even back then. Having debug mode be the default was certainly an interesting decision (probably to make things easier for beginners).
The script was running in production, doing actual work. Stopping it - when you don't remember a damn thing about it and how it worked - was not an option I wanted to consider at the time.
Absolutely. I wrote such a script as a proof-of-concept and was yelled at because it was considered a 'security risk' for me to use company tools to write code (as a not-hired-for-programming employee) even though I already had access to literally all the company's data and their security practices were such that exfiltrating their data without being caught would have been trivial even if I never placed any code on their systems. The place was extremely dysfunctional and there were significant trust issues that were completely irrational and inconsistent. So a script that did this job was largely out of the question.
It's a lot easier to hire people than fire them friend.
The documentation recommends nothing of the sort, it's a direction for consumers. We all live in varied and different worlds, how many varied server environments have you been responsible for all at once? Is it really beyond your amazing programming skills to use the tools at hand in every circumstance? Perhaps it's a chance to demonstrate yet another 3rd party tool which fixes non-existent problems.
It's a few bytes difference in your script that is using requests over the numerous and plentiful stdlib options there.
I have a habit of creating cli tools, which potentially do dangerous things, to default to dry-run mode. For example, instead of the typical `--dry-run` or `-n` option, my scripts instead had a cheesy `--do-it` to be non-dry-run. It is annoying as hell to my colleagues, but saved the day many times.
* operated on production data (rather than beta/pre-prod data, or failing if stage is not specified) by default * did not recognize `--help/-h` as flags, but would simply ignore them and continue to run
I'm not exactly happy in my role currently, but I'm a damn sight happier not having to deal with him anymore.
reply