Calling conventions: short-opts, long-opts, equals, keywords, etc

[stuartpb]

I think a section on (or link to) how to parse, and design, script arguments, and specifically options (both long and short), would be useful.

[progrium]

I'm afraid to be too opinionated here because my working model is that you should avoid options. It forces simpler design overall, and better initial user experience. Options and modes should be minimized, but sometimes they are necessary, which I put into environment. I borrow a lot of this philosophy from others but it's been great so far.

Anyway, as much as I want to push this for my projects, I don't know that it would make these guidelines more generally applicable (as some people seem to expect them to be). Thoughts?

[stuartpb]

I touched on this in #14, but I generally say you shouldn't use environment variables for anything that doesn't involve the script's environment. Remember that env vars get copied for every context beneath the call they're set for - so if you define the variable for one call, then within that call you make another call that doesn't _re_define it, it's going to use the definition from the original call. Environment variables should only be used for things where that is what you want to happen (like setting a base dir / namespace / context for actions to be taken in).

In JS terms (although I'm a bit out of my depth when talking about JS's OOP facilities): the environment, and its variables, are like this, and its properties. You generally wouldn't use setting properties of the object as part of a calling convention, you'd use an object of options as an argument of the function. Option arguments (flags etc) in Bash are like option objects in JS.

As an aside, I think our opinions on calling conventions are informed by the structure of how we're doing our calls. One case where we definitely appear to have diverging opinions/styles is that I'm of the opinion that interfaces should be cleaved at the script level (and functions should only be defined as helpers within scripts), whereas you have things modeled at the function level (and treat scripts as encapsulation objects for clusters of functions). I like my way better, mostly because it doesn't force developers to write Bash in order to use your scripts (and source your functions).

(Plushu does have a few points where you have to write Bash which gets sourced, but that's because they are deep, guts-plunging alterations to things like parsers and it would be an abstraction inversion to define an interface around it.)

[progrium]

Even if I was doing script file oriented Bash, I'd prefer using env for certain options. To me this is "environment". Options are a context for scripts to consider, just like environment.

But okay, this issue is on a section on designing commands.