4 ms·

There's something I wish command lines would not adopt that is should not be as a CLI flag, and that's --json or --csv. Instead this should be offered as an env

by nmz 3y ago

There's something I wish command lines would not adopt that is should not be as a CLI flag, and that's --json or --csv. Instead this should be offered as an environment variable that runs through all the commands like IOFORMAT=JSON { cmd1|cmd2|cmd3 } if they support the environment variable, they can all read input in a safe way and behave appropriately, if they don't, then they just print as normal

gumby 3y ago
(BTW sometimes ENV vars are bug removers and sometimes a terrible source of mysterious bugs as well as a possible injection vector.) A good option package should support long options being both command line flags and environment variables. The really good ones support them in init files as well (I'm partial to the JSON-ish HOCON format, though .INI works too). I always spec (later overrides previous settings): - system default (/etc/foo.conf) - user defaults (~/.foo.conf) - local defaults (${CWD}/foo.conf) - user-specified init file (overrides local default) - environment vars (FOO_OUTPUT=JSON) - command line var (--output=json) As well as --no-init and --no-env
- nmz 3y ago
  I disagree of having programs use env vars, ENV propagates, now every single program has an env var for that single program that you barely use, a good example is LSCOLORS, or nnn, all programs now consume extra memory. Which isn't a lot. but it adds up if every single program decides to use ENV.
  - gumby 3y ago
    I wouldn't worry about memory. As I noted, the propagation value of environment vars can be very handy (make sure the programs are communicating via JSON, from an upstream example) and can also lead to confusing bugs (why is this generating JSON output???)
    - nmz 3y ago
      I don't see the problem, you're just making something explicit what used to be implicit, unix is implicitly tsv, well now its a variable that you can change.
      - gumby 3y ago
        I do think it is superior to specify the setting explicitly on the cmd line, but sometimes you’re calling a script and want something specified.

by nmz 3y ago

gumby 3y ago

(BTW sometimes ENV vars are bug removers and sometimes a terrible source of mysterious bugs as well as a possible injection vector.) A good option package should support long options being both command line flags and environment variables. The really good ones support them in init files as well (I'm partial to the JSON-ish HOCON format, though .INI works too). I always spec (later overrides previous settings): - system default (/etc/foo.conf) - user defaults (~/.foo.conf) - local defaults (${CWD}/foo.conf) - user-specified init file (overrides local default) - environment vars (FOO_OUTPUT=JSON) - command line var (--output=json) As well as --no-init and --no-env

nmz 3y ago
I disagree of having programs use env vars, ENV propagates, now every single program has an env var for that single program that you barely use, a good example is LSCOLORS, or nnn, all programs now consume extra memory. Which isn't a lot. but it adds up if every single program decides to use ENV.
- gumby 3y ago
  I wouldn't worry about memory. As I noted, the propagation value of environment vars can be very handy (make sure the programs are communicating via JSON, from an upstream example) and can also lead to confusing bugs (why is this generating JSON output???)
  - nmz 3y ago
    I don't see the problem, you're just making something explicit what used to be implicit, unix is implicitly tsv, well now its a variable that you can change.
    - gumby 3y ago
      I do think it is superior to specify the setting explicitly on the cmd line, but sometimes you’re calling a script and want something specified.