It feels wrong but I can't quite put my finger on the reason why... It will make version control more hectic, for sure. It also seems to be conflating identification with configuration which seems non-ideal. What about versioning and upgrading? How do I find a "well-known" entry point with a file name of flags? Every read now becomes an expensive find and grep lesson... Yeah, I don't like it.

There's a whole host of problems with it. I'm almost on the side of saying this is a well written troll post but...

To have two different things you need to run, now you need to have multiple copies of the same thing.

What does the parsing? How do you split out a URL, what order are the "flags" in? Do you have named arguments, etc? Well now you need to have your own custom parsing library instead of just using exactly what anyone else would use.

Where do you go for help? Do you rename it to my_program_help.exe then rerun it?

What about chaining things together? Anything dynamic? Is the caller script expected to rename your program before running it?

> fetch---api.github.com---repos/owner/project---q=stars>100---o=json.exe

Oh lord.

> Imagine install_PY3_MODULE_NAME.exe. It reads the filename, extracts the Python module name, downloads dependencies, sets up Python if needed, and creates a launcher. Rename it, and you have a new installer for a different project. Icons, mirrors, or other metadata can also live in the file as resources – all self-contained, all shareable.

Imagine changing that to "install_python.exe --module module_name".

The thing you really want to do instead is have a single executable, then have scripts or even aliases that are named for what they do that are super thing wrappers. One copy, no moving, renaming, anything.

`fetch---api.github.com---repos/owner/project---q=stars>100---o=json.exe`

and 50 different copies for various different projects, is replaced with

`fetch.exe`

and

`top_100_github_repos.exe`

`highest_rated_github_repos.exe`

`get_weather.exe`

Which are single line scripts that pass on arguments to the base program. Which also means you can fix any issues in one place.

It's unexpected. When trying to understand a system it's beneficial if it adheres to expectations, as it means we're not forced to consider the entire possibility space of what a program can be. Utilizing the entire possibility space is usually the domain of malware, which tries to be surprising.

The executed filename could be a symlink to a single common binary/script.

This strikes me more as a matter of taste, i.e. more art than something which can be provably wrong, or correct for that matter. The concerns you outlined might be concerns the author doesn't have to worry about for whatever reason -- if this fits neatly and seamlessly into their existing workflows then that's great, and I for one appreciate learning about other peoples' approaches like this even if they don't immediately work for me

IMV it's a clever trick, and like you my instinct is that if I attempted to integrate this into my own workflows, I would endure some sort of hardship down the line but it's not immediately obvious when or how. Or maybe for certain things it would be fine and less painful than other options, like other similarly clever tricks I felt uneasy about at first

It feels wrong because it's a hack. You're using the name for something else.

If the rename changes the entire behavior (see busybox comment) it makes sense. But defining multiple arguments? Now the author had to use -- in the file name where using space would do (and the OS splits it for you)

And good luck trying to run the same programs with different arguments. You'll have to take turns renaming the file, or create hardlinks just for ephemeral arguments.

It can be useful but there's time and place to do it.

[dead]