4 ms·
In my head there's been a hierarchy for a long time. when I build command line utilities and I think about the way that they'll be used, I tend to use configur
by jpitz 6y ago
In my head there's been a hierarchy for a long time.
when I build command line utilities and I think about the way that they'll be used, I tend to use configuration files for things that will change very slowly over time, and environment variables as a way to override default behaviors, and command line arguments to specify things that will often vary from invocation to invocation. In fact, most of the time, I use the environment variables either for development/testing features that I don't really intend to expose to most users, or for credentials that don't get persisted.
it's never occurred to me to use environment variables as a primary way to configure an application. I'll have to noodle on that for a while. My gut says that it's enough of a deviation from the Unix convention that I probably won't use that.
- Izkata 6y ago> My gut says that it's enough of a deviation from the Unix convention that I probably won't use that. It's not completely unheard of. Checking the man pages for a few I remember being affected: * `ls` looks at LS_COLORS * `grep` looks at GREP_OPTIONS, GREP_COLOR, GREP_COLORS, as well as the not-grep-specific LC_ALL, LC_COLLATE, LANG, etc, and POSIXLY_CORRECT * `find` also looks at LC_%, LANG, POSIXLY_CORRECT as well, plus TZ and PATH for some of its other options Looks like the program-specific ones LS_% and GREP_% can be overridden by options directly on the command, but the others don't have such options. (Makefile wildcards because asterisk keeps doing italics)
- Annatar 6y agoThese are all GNU/Linuxisms and are nowhere to be found in a real UNIX®️ like illumos, Solaris, HP-UX or IRIX64. This is also a good example of why having GNU/Linux as one's first OS instead of a real UNIX®️ is so toxic.
- jpitz 6y agoI feel like I didn't make "primary" clear enough - it would be like using an environment variable for the path for ls. That's gonna be a big no from me, dog.
- chriswarbo 6y ago> it would be like using an environment variable for the path for ls. That's gonna be a big no from me, dog Me too. My point about env vars was limited to key/value options. I'm happy to use positional arguments when names are irrelevant, e.g. `ls foo/` is better than `DIR=foo/ ls` or `ls --dir foo/` or `ls --dir=foo/` or whatever, since the latter just adds noise and increases the chance we'll get something wrong. I'm also happy to use arguments for flags which are either present or absent, where values are irrelevant, e.g. `ls --all` rather than e.g. `ALL=1 ls` or `ls --all=yes` or whatever. In this case the presence of a value is even more hamful, since the program might only be checking for the variable's presence, in which case `ALL=0 ls` would be misleading; plus we'd have to guess whether the value should be 0/1, yes/no, y/n, on/off, enable/disable, etc.