3 ms·

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

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.

themafia 7mo ago
> 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.
- IanCal 7mo ago
  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"
Cthulhu_ 7mo ago
I suppose scripts are OS specific (mainly Windows and "everything else", because #/bin/sh is everywhere else). That said, apparently there's cursed methods of having a universal shell/batch file of sorts, according to https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash https://stackoverflow.com/questions/17510688/single-script-t.... Anyway, I'd argue for the vast majority of cases, a shell script that wraps the command and its flags is fine.
csb6 7mo ago
It just doesn't seem that hard to send someone a message stating: "Run foo.exe --bar from command prompt/the terminal"
- ziotom78 7mo ago
  True, but what if you need to re-run that command several months later and you can no longer find the message?

themafia 7mo ago

> 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.

IanCal 7mo ago
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"

Cthulhu_ 7mo ago

I suppose scripts are OS specific (mainly Windows and "everything else", because #/bin/sh is everywhere else). That said, apparently there's cursed methods of having a universal shell/batch file of sorts, according to https://stackoverflow.com/questions/17510688/single-script-to-run-in-both-windows-batch-and-linux-bash https://stackoverflow.com/questions/17510688/single-script-t.... Anyway, I'd argue for the vast majority of cases, a shell script that wraps the command and its flags is fine.

csb6 7mo ago

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

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