Personal experience in computing is not what I meant. I only realized that I'm not intimately familiar of the dawn of the UNIX daemon and how their configuration methods changed with time, only the echos of this in daily Linux use. Thus, I realized I was possibly extrapolating and assuming things.
> Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work.
Yeah, and I think this lack of distinction is what poisons the discussion surrounding this post - these are separate worlds with different requirements, conflated into a single argument or point of view.
tl;dr I stand by my point with preferring anything over environment variables for services (especially complex ones), but I also fully agree with your usecase for interactive, CLI-driven systems. I mean, one of my favourite programming language features in recent years is that I can cross-compile Go programs just by setting two env vars: GOARCH and GOOS :).
I'd be absolutely horrified if a service that I use need a specific environment variable set in a particular way to work correctly and it's not well documented. That service would get bonus points for inability to configure that particular option in a configuration file.
I personally would never add environment variables to a program I write which may run as a service.
Personal experience in computing is not what I meant. I only realized that I'm not intimately familiar of the dawn of the UNIX daemon and how their configuration methods changed with time, only the echos of this in daily Linux use. Thus, I realized I was possibly extrapolating and assuming things.
> Yes, the tools I've talked about are userspace programs, and are not daemons 99.999% of the time. So you need to run it many times with small differences, and reconfiguring/regenerating file is a lot of work.
Yeah, and I think this lack of distinction is what poisons the discussion surrounding this post - these are separate worlds with different requirements, conflated into a single argument or point of view.
tl;dr I stand by my point with preferring anything over environment variables for services (especially complex ones), but I also fully agree with your usecase for interactive, CLI-driven systems. I mean, one of my favourite programming language features in recent years is that I can cross-compile Go programs just by setting two env vars: GOARCH and GOOS :).