← Back to context

Comment by ziotom78

5 days ago

I too was perplexed, but the main use case seems to be when you want to share a particular configuration or need to be sure that you always use the same set of flags:

> Flags are ephemeral – you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability. Filenames solve both: the program describes itself, requires zero setup, and any configuration can be shared by simply renaming the file.

[Emphasis added] Although I find a script that wraps the command and calls it more versatile, there might be some value in this idea for some very simple cases, like example #4.

> you have to share the command line or wrap it in a script. Scripts depend on environment, which can break portability

I get the problems but I don't think I've ever had both at once. A need to portably wrap and share a specific command line for a specific program?

For the case of broadcast it seems easiest to just document the proper command line options. For the case of "unicast" I can just ask the other person what their environment is so I can craft the appropriate wrapper for them.

The area of overlap in the Venn diagram is infinitesimally narrow.

  • Also, you can share the generic program and then share wrapper scripts that are named for what they do rather than a series of flags. Then to share, you're just sharing a config file, script or similar that calls "whatever.exe --dir=./blah --run=12 --batch=false"

It just doesn't seem that hard to send someone a message stating: "Run foo.exe --bar from command prompt/the terminal"

  • True, but what if you need to re-run that command several months later and you can no longer find the message?