5 ms·
> I'd much rather have a config file I can point it towards than an endlessly long shell script I can't comfortably use comments in (maybe this is a criticism o
by troutwine 4y ago
> I'd much rather have a config file I can point it towards than an endlessly long shell script I can't comfortably use comments in (maybe this is a criticism of shell scripts in general).
I end up designing a lot of CLI tools and this is a design problem I run into a lot with my own stuff: how many flags are too many? Introducing a config file works, but now it makes your tool much less feasible to run in a shell script but, like you say, too many flags makes your tool unwieldy to run anyway. The problem is harder if you have a venerable tool that's always been flag heavy. Do you keep lumping flags in or do you steer the community toward the use of a config file? Or a hybrid?
- rcoveson 4y agoOpenVPN's approach is to have every config key imply a valid config file entry and a long-arg. So if you see the line `tun-mtu 1500` in a config file, you know you could use the arg `--tun-mtu 1500` on the command line, and vice versa; if you see somebody use the CLI arg `--proto udp` you know you could put the line in your config file `proto udp`. I think mysqld has a similar approach, though I don't think it's as complete. I'll bet both of those projects would answer that there's no such thing as a tipping point where you tell users to use a config file. They're just two ways of doing the same thing; use whichever makes sense for your deployment.
- troutwine 4y agoThat's an interesting approach.
- nyanpasu64 4y agoThe mpv media player takes a similar approach.
- nerdponx 4y agoSeveral Python tools (Mypy, Black) also use this approach and I like it a lot.
- solarkraft 4y agoI like tools that have 1:1 mappings for config file and command line flags because, as you say, both have advantages and disadvantages.