3 ms·

This thread seems like a good place to ask this: When you're running a script, what is the expected behaviour if you just run it with no arguments? I think it

This thread seems like a good place to ask this: When you're running a script, what is the expected behaviour if you just run it with no arguments? I think it shouldn't make any changes to your system, and it should print out a help message with common options. Is there anything else you expect a script to do? Do you prefer a script that has a set of default assumptions about how it's going to work? If you need to modify that, you pass in parameters. Do you expect that a script will lay out the changes it's about to make, then ask for confirmation? Or should it just get out of your way and do what it was written to do? I'm asking all these fairly basic questions because I'm trying to put together a list of things everyone expects from a script. Not exactly patterns per se, more conventions or standard behaviours.

mason55 5y ago
IMO any script that makes any real changes (either to the local system or remotely) should take some kind of input. It's one thing if your script reads some stuff and prints output. Defaulting to the current working directory (or whatever makes sense) is fine. If the script is reading config from a config file or envvars then it should still probably get some kind of confirmation if it's going to make any kind of change (of course with an option to auot-confirm via a flag like --yes). For really destructive changes it should default to dry run and require an explicit —-execute flag but for less destructive changes I think a path as input on the command line is enough confirmation. That being said, if it’s an unknown script I’d just read it. And if it’s a binary I’d pass —-help.
- bloopernova 5y ago
  Thanks for the reply! I really appreciate being able to pick other folks' brains on here :)
gmuslera 5y ago
What is your intended audience? It is you? A batch job or called by another program? Or a person that may or not be able to read bash and will call it manually? A good and descriptive name comes first, then the action and the people that may have to run it are next.
scbrg 5y ago
A script is just another command, the only difference in this case is that you wrote it and not someone else. If its purpose is to make changes, and it's obvious what changes it should make without any arguments, I'd say it can do so without further ado. poweroff doesn't ask me what I want to do - I already told it by executing it - and that's a pretty drastic change. Commands that halt halfway through and expect user confirmation should definitely have an option to skip that behavior. I want to be able to use anything in a script of my own.
gjulianm 5y ago
> When you're running a script, what is the expected behaviour if you just run it with no arguments? I think it shouldn't make any changes to your system, and it should print out a help message with common options. Is there anything else you expect a script to do? Most scripts I use, custom-made or not, should be clear enough in their name for what they do. If in doubt, always call with --help/-h. But for example, it doesn't make sense that something like 'update-ca-certificates' requires arguments to execute: it's clear from the name it's going to change something. > Do you prefer a script that has a set of default assumptions about how it's going to work? If you need to modify that, you pass in parameters. It depends. If there's a "default" way to call the script, then yes. For example, in the 'update-ca-certificates' example, just use some defaults so I don't need to read more documentation about where the certificates are stored or how to do things. > Do you expect that a script will lay out the changes it's about to make, then ask for confirmation? Or should it just get out of your way and do what it was written to do? I don't care too much, but give me options to switch. If it does everything without asking, give me a "--dry-run" option or something that lets me check before doing anything. On the other hand, if it's asking a lot, let me specify "--yes" as apt does so that it doesn't ask me anything in automated installs or things like that.
auno 5y ago
What you're getting at seems to be more about CLI conventions as opposed to script conventions specifically. As such, you might want to have a look at https://clig.dev/ https://clig.dev/ which is a really comprehensive document describing CLI guidelines. I can't say I've read the whole thing yet, but everything I _have_ read very much made sense. It's been discussed here on HN before. https://news.ycombinator.com/item?id=25304257 https://news.ycombinator.com/item?id=25304257

mason55 5y ago

IMO any script that makes any real changes (either to the local system or remotely) should take some kind of input. It's one thing if your script reads some stuff and prints output. Defaulting to the current working directory (or whatever makes sense) is fine. If the script is reading config from a config file or envvars then it should still probably get some kind of confirmation if it's going to make any kind of change (of course with an option to auot-confirm via a flag like --yes). For really destructive changes it should default to dry run and require an explicit —-execute flag but for less destructive changes I think a path as input on the command line is enough confirmation. That being said, if it’s an unknown script I’d just read it. And if it’s a binary I’d pass —-help.

bloopernova 5y ago
Thanks for the reply! I really appreciate being able to pick other folks' brains on here :)

gmuslera 5y ago

What is your intended audience? It is you? A batch job or called by another program? Or a person that may or not be able to read bash and will call it manually? A good and descriptive name comes first, then the action and the people that may have to run it are next.

scbrg 5y ago

A script is just another command, the only difference in this case is that you wrote it and not someone else. If its purpose is to make changes, and it's obvious what changes it should make without any arguments, I'd say it can do so without further ado. poweroff doesn't ask me what I want to do - I already told it by executing it - and that's a pretty drastic change. Commands that halt halfway through and expect user confirmation should definitely have an option to skip that behavior. I want to be able to use anything in a script of my own.

gjulianm 5y ago

> When you're running a script, what is the expected behaviour if you just run it with no arguments? I think it shouldn't make any changes to your system, and it should print out a help message with common options. Is there anything else you expect a script to do? Most scripts I use, custom-made or not, should be clear enough in their name for what they do. If in doubt, always call with --help/-h. But for example, it doesn't make sense that something like 'update-ca-certificates' requires arguments to execute: it's clear from the name it's going to change something. > Do you prefer a script that has a set of default assumptions about how it's going to work? If you need to modify that, you pass in parameters. It depends. If there's a "default" way to call the script, then yes. For example, in the 'update-ca-certificates' example, just use some defaults so I don't need to read more documentation about where the certificates are stored or how to do things. > Do you expect that a script will lay out the changes it's about to make, then ask for confirmation? Or should it just get out of your way and do what it was written to do? I don't care too much, but give me options to switch. If it does everything without asking, give me a "--dry-run" option or something that lets me check before doing anything. On the other hand, if it's asking a lot, let me specify "--yes" as apt does so that it doesn't ask me anything in automated installs or things like that.

auno 5y ago

What you're getting at seems to be more about CLI conventions as opposed to script conventions specifically. As such, you might want to have a look at https://clig.dev/ https://clig.dev/ which is a really comprehensive document describing CLI guidelines. I can't say I've read the whole thing yet, but everything I _have_ read very much made sense. It's been discussed here on HN before. https://news.ycombinator.com/item?id=25304257 https://news.ycombinator.com/item?id=25304257