5 ms·
> output formats that are not machine-friendly Not a new problem. It was always like that. Not sure if you know about the `jc` tool. It converts the plain tex
by pdimitar 4y ago
> output formats that are not machine-friendly
Not a new problem. It was always like that.
Not sure if you know about the `jc` tool. It converts the plain text output of a subset of UNIX commands to JSON. It's helpful, I've used it.
> complicated configuration files (typically requiring even more libraries)
Not sure I can stand behind the "more libraries" argument, some formats like TOML are stable and predictable and having one more system-wide library is worth it to have them accessible.
On config files: if the tool allows you to specify 100% of what you need on the CLI then I usually make an alias and I'm done.
I too dislike tools that mandate a config file though. I view the tool authors as not very sympathetic to their users in this case.
- PhilipRoman 4y agoYeah I shouldn't have included that bit about libraries - if there is a config file, it doesn't matter how you parse it. My preferred ways of configuring in order of preference would be: having a config.h (for a few, highly customized programs, like my terminal, browser, etc.), environment variables (has the advantage of applying to subprocesses, which can be useful for some types of programs) and flags. Aliases with flags can be lost in a lot of contexts, but you can always place wrapper scripts in PATH which just exec the real command. As a side note - the wrapper script approach is really powerful for fixing programs that you don't have the time to patch. In particular, if a TUI program doesn't clear the terminal after exiting, you can put it between "tput smcup" and "tput rmcup".