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.

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.

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

And you can then set things like "open with" if you want click -> launch with specific app.

The biggest thing for me is that you can name the configurations for what they're doing not how.

For example:

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

could become something like

top_starred_repos.bat/exe/sh

This also removes the need to get myself and others to battle escaping problems as you start adding arbitrary arguments into this.

Careful, comments like that may actually sell people to the idea.

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.

I guess you could rename it to foo--bar--help.exe to get the help. An awkward workflow indeed

I have used that in a project of my own[0] for convenience (avoid duplicated code), but it is uncommon, yes.

I truly think it should be avoided in general, especially when what you actually want (in OP’s article) is a config file.

[0] https://github.com/Frizlab/frizlabs-conf/blob/44030f4123e683... (w/ that, also see the aliases in the folder of the script)

It may be a bit uncommon, but it's not at all new. For example, on a Linux system I have, there are several files in /usr/bin that use hard links to refer to the same file (inode) by different names:

bunzip2 / bzcat / bzip2

gunzip / uncompress

unzip / zipinfo

pigz / unpigz

pkg-config / x86_64-pc-linux-gnu-pkg-config

perlbug / perlthanks

Use ls -li to show the inode number for each file or directory. For example:

    $ ls -li /usr/bin/{bzip2,bunzip2,bzcat}
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bunzip2
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bzcat
    23069197 -rwxr-xr-x 3 root root 39144 Sep  5  2019 /usr/bin/bzip2

This is already how busybox works. These examples are taking it to a more extreme level but it's not _that_ crazy.

I'd say "kind of", because it's ridiculous on the surface but could be a handy trick. If only to be aware that an executable gets told its own name.