3 ms·

Env vars are a built-in for key-value command line args. Why introduce some custom convoluted way into your app for kv args instead of this standardised approac

Env vars are a built-in for key-value command line args. Why introduce some custom convoluted way into your app for kv args instead of this standardised approach. I can understand why some heavily used cli app would support a custom parameter pattern, eg. for ergonomics, but for majority of apps running as deployed services and not cli apps invoked 100 times a day, I don't see a reason to not use env args. I can run the following and introduce exactly zero parsing boilerplate into my app or invoking scripts. port=12345 color=green ./myapp.py Also - some apps have to be configured from file, others on the command line. Which parameter parsing library even supports that? Env vars support this out of the box.

zokier 6y ago
Environ isn't actually key-value, it's only convention that applications (/libraries) parse it in the name=value form. But the underlying mechanism is similar to cmdline: array of pointers to strings. You could parse cmdline same way if you'd want.
- yrro 6y ago
  It's an exceedingly strong convention. I'd be genuinely curious to learn of non-malways uses for entries within the environment block that don't fit the standard name=value pattern.
- josephcsible 6y ago
  Don't POSIX and portable C both require key=value? If so, isn't that more than just convention?
  - zokier 6y ago
    Righto, I was considering Linux only, I don't personally care much for POSIX. I don't think ISO C standard sets any strong requirements. But yes, if you want maximum portability then you probably should be pretty conservative with environment.
  - spc476 6y ago
    I don't know about POSIX, but C doesn't mandate an implementation. The C Standard says about getenv(): Quote: The getenv function searches an environment list, provided by the host environment, for a string that matches the string pointed to by name. The set of environment names and the method for altering the environment list are implementation-defined. The implementation shall behave as if no library function calls the getenv function. Returns The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function. If the specified name cannot be found, a null pointer is returned. End quote. The takeaway from me is that yes, environments do define a key/value store of some sort, but how they're implemented isn't stated. It can be an array of strings in "key=value" format stored in RAM, but it could just as well be a hash table stored in ROM.
    - zokier 6y ago
      Also, the specification of getenv does not exclude of having other data in environment that is just not retrievable by getenv but would be accessible e.g. through the third argument to main that is mentioned in the common extensions section.

zokier 6y ago

Environ isn't actually key-value, it's only convention that applications (/libraries) parse it in the name=value form. But the underlying mechanism is similar to cmdline: array of pointers to strings. You could parse cmdline same way if you'd want.

yrro 6y ago
It's an exceedingly strong convention. I'd be genuinely curious to learn of non-malways uses for entries within the environment block that don't fit the standard name=value pattern.
josephcsible 6y ago
Don't POSIX and portable C both require key=value? If so, isn't that more than just convention?
- zokier 6y ago
  Righto, I was considering Linux only, I don't personally care much for POSIX. I don't think ISO C standard sets any strong requirements. But yes, if you want maximum portability then you probably should be pretty conservative with environment.
- spc476 6y ago
  I don't know about POSIX, but C doesn't mandate an implementation. The C Standard says about getenv(): Quote: The getenv function searches an environment list, provided by the host environment, for a string that matches the string pointed to by name. The set of environment names and the method for altering the environment list are implementation-defined. The implementation shall behave as if no library function calls the getenv function. Returns The getenv function returns a pointer to a string associated with the matched list member. The string pointed to shall not be modified by the program, but may be overwritten by a subsequent call to the getenv function. If the specified name cannot be found, a null pointer is returned. End quote. The takeaway from me is that yes, environments do define a key/value store of some sort, but how they're implemented isn't stated. It can be an array of strings in "key=value" format stored in RAM, but it could just as well be a hash table stored in ROM.
  - zokier 6y ago
    Also, the specification of getenv does not exclude of having other data in environment that is just not retrievable by getenv but would be accessible e.g. through the third argument to main that is mentioned in the common extensions section.