This just gave me a flashback to something I made a long time ago, which was a tool to create a file that was a named pipe - the contents of which were determined by the command in its filename. If I remember correctly (and its embedded man page would seem to validate this memory), the primary impetus for making this tool was to have dynamically generated file content for purposes of enabling a remote process execution over server daemons that did not explicitly allow for it, such as finger, etc, but were intended only to read a specific static file.
Using named pipes in this manner also enabled a hackish method to create server-side dynamic web content by symlinking index.html to a file created in this manner, which was a secondary motivator, which seems kinda quaint and funny now, but at that time, it wasn't very long after just having finally decommed our gopher server, so fingerd was still a thing, Apache was fairly new, and I may still have been trying to convince management that the right move was not from ncsa httpd to Netscape Enteprise Server, but to Apache+mod_ssl. RSA patent licensing may still have been a thing too. Stronghold vaguely comes to mind, but I digress.
Yeah, programs that do stuff based on filename, like busybox. Oh, and this long forgotten artifact this article just reminded me of that I managed to find in the Wayback Machine, a tool to mknod a named pipe on a SunOS 4.1.4 machine, to get server-side dynamic content when remotely accessing a daemon that was supposed to return content from a single static file. Ah, memories.
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.
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
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.
Seems a lot easier to have a --help flag that lists all of the options and their function. That is self-documenting (assuming the descriptions are useful) and helps with discovery. Changing the name of the file to foo--bar.exe doesn't seem any easier than writing foo.exe --bar
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.
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:
That's more a case of providing the distinct "APIs" ( bzip2 , gunzip etc) to userland / scripts, while the implementation for all is just one binary; than it being "Configuration via name..."
This just gave me a flashback to something I made a long time ago, which was a tool to create a file that was a named pipe - the contents of which were determined by the command in its filename. If I remember correctly (and its embedded man page would seem to validate this memory), the primary impetus for making this tool was to have dynamically generated file content for purposes of enabling a remote process execution over server daemons that did not explicitly allow for it, such as finger, etc, but were intended only to read a specific static file.
https://web.archive.org/web/19991109163128/http://www.dfw.ne...
Using named pipes in this manner also enabled a hackish method to create server-side dynamic web content by symlinking index.html to a file created in this manner, which was a secondary motivator, which seems kinda quaint and funny now, but at that time, it wasn't very long after just having finally decommed our gopher server, so fingerd was still a thing, Apache was fairly new, and I may still have been trying to convince management that the right move was not from ncsa httpd to Netscape Enteprise Server, but to Apache+mod_ssl. RSA patent licensing may still have been a thing too. Stronghold vaguely comes to mind, but I digress.
Yeah, programs that do stuff based on filename, like busybox. Oh, and this long forgotten artifact this article just reminded me of that I managed to find in the Wayback Machine, a tool to mknod a named pipe on a SunOS 4.1.4 machine, to get server-side dynamic content when remotely accessing a daemon that was supposed to return content from a single static file. Ah, memories.
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.
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.
This is the classname soup mess of TailwindCSS (when people don't precompile that away) manifested into the CLI...
Careful, comments like that may actually sell people to the idea.
I'll confess to only have skimmed TFA but I love this idea.
Seems a lot easier to have a --help flag that lists all of the options and their function. That is self-documenting (assuming the descriptions are useful) and helps with discovery. Changing the name of the file to foo--bar.exe doesn't seem any easier than writing foo.exe --bar
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 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-t....
Anyway, I'd argue for the vast majority of cases, a shell script that wraps the command and its flags is fine.
> 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.
I guess you could rename it to foo--bar--help.exe to get the help. An awkward workflow indeed
You could skip the underlying mechanism by renaming Claude.exe and then it just passes the name as a new chat.
this is new to me tbh
this is satire, right?
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:
That's more a case of providing the distinct "APIs" ( bzip2 , gunzip etc) to userland / scripts, while the implementation for all is just one binary; than it being "Configuration via name..."
Somewhat similar to how busybox does its thing.
This is already how busybox works. These examples are taking it to a more extreme level but it's not _that_ crazy.
AIUI, on Windows, pip (via the vendored `distlib`) also makes stub executables that work this way to implement the "entry points" defined in installed wheels. See: https://github.com/pypa/distlib/blob/master/PC/ReadMe.txt
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.