Re:Conventions for Command Line Options
by AnonC on Saturday August 01, 2020 @02:28PM
(#24022749)
I’m curious if your preference for environment variables is only for writing programs or for using programs as well. From a user’s perspective, would you prefer that common commands use environment variables to get options? For example, would you prefer a “find” command that uses environment variables instead of command line options?
[ Parent
| on HN ]
Re:Conventions for Command Line Options
by chriswarbo on Saturday August 01, 2020 @05:01PM
(#24023869)
> For example, would you prefer a “find” command that uses environment variables instead of command line options?
I use 'find' so much that my muscle memory would hurt if it changed, but it's actually a really interesting example. Its use of arguments to build a domain-specific language is a cool hack, but pretty horrendous; e.g.
find . -type f -a -not \( -name \*.htm -o -name \*.html \)
We can compare this to tools like 'jq', which use a DSL but keep it inside a single string argument: key=foo val=bar jq -n '{(env.key): env.val}'
Note that 'jq' also accepts key/value pairs via commandline arguments, but that requires triplets of arguments, e.g. jq -n --arg key foo --arg val bar '{(env.key): env.val}'The second example didn't work for jq-1.6 ---I had to write it as
jq -n --arg key foo --arg val bar '{($key): $val}'
Re:Conventions for Command Line Options
by chriswarbo on Monday August 10, 2020 @11:12AM
(#24110106)
Yes you're right. I spotted it myself, but only after I couldn't edit anymore :(
That would depend on the target, the Grand Parent talks about Automation thus the target for their utilities is most likely the system not a user.
When writing automation routines env vars are often better form my experience
Tools that will be manually run by a user or admin then cli options are better