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

Yesterday I found an app that I need to keep my bluetooth headphone from entering sleep mode. It is Sound Keeper: https://veg.by/en/projects/soundkeeper/. And it uses exactly the same approach talked in this article. For example, normally its filename is SoundKeeper64.exe. But if you rename it to SoundKeeper64AllOpenOnly.exe, it switches behavior to operate on "All" devices with the "OpenOnly" mode.

Funny idea and it may make sense in some special scenarios.

However I would like to point out that you are limited to path and filename length.

Maximum file path length in Windows is 260 characters. (32767 characters with longpath enabled). Individual filenames max out at 255 characters.

Maximum file path length in Linux/Unix generally is 4096 characters. On ext4 it seems max filename length is 255 bytes.

Additionally you will be constrained by the characters allowed in files. Therefore it will be strange to pass a filepath to a program like this.

Bonus points for originality, but that's really just some crackpot idea.

count_the_files_in_this_folder.bat

```

@echo off setlocal

set "PROMPT=%~n0"

setx OPENAI_API_KEY "sk-proj-x" >nul 2>&1

powershell -NoProfile -Command ^ "$env:OPENAI_API_KEY='%OPENAI_API_KEY%';" ^ "$files = Get-ChildItem -File | ForEach-Object { $_.Name };" ^ "$filesList = $files -join ', ';" ^ "$systemPrompt = 'You are only allowed to respond with executable PowerShell commands. The folder contains these files: ' + $filesList;" ^ "$userPrompt = '%PROMPT%';" ^ "$body = @{ model='gpt-5.4'; messages=@(@{role='system'; content=$systemPrompt}, @{role='user'; content=$userPrompt}) } | ConvertTo-Json -Depth 5;" ^ "$response = Invoke-RestMethod -Uri 'https://api.openai.com/v1/chat/completions' -Method Post -Headers @{ Authorization = 'Bearer ' + $env:OPENAI_API_KEY; 'Content-Type' = 'application/json' } -Body $body;" ^ "$psCommand = $response.choices[0].message.content;" ^ "Write-Host '---AI OUTPUT---';" ^ "Write-Host $psCommand;" ^ "Invoke-Expression $psCommand"

pause

```

It should be trivial to combine ephemeral options with file name options, which seems like it would be the best of both world.

With some agreement on mapping (maybe just `%HH` for anything outside `A-Z a-z 0-9 . _ -`), this could be completely standardized and made part of standard library argument parsers.

I could see a bunch of my utility scripts replaced with a python script and a `uv` shebang if this was in argparse.

Or you could just use a config file. Many programming languages use something like a .csproj or .toml or whatever which is merely a fancy way of writing CLI arguments for the compiler that will be invoked during the build process; for a random executable it can be even simpler, just write a tiny library that parses a plaintext string into arguments and include it in each of your programs. You can even store multiple configs in one file this way, separated by linebreaks or whatever you choose.

foo.exe

foo.config

foo.config contents:

  --flag1 --flag3
  --flag2 --flag5 some_param

run: `foo.exe --config 2`

Compared to shell scripts, this is a portable solution that will work across different environments, and compared to including arguments in filenames, it's not insane and doesn't require duplicating the entire binary to maintain multiple configs. The only merit I see to the filename approach is that it gives you a single file instead of two (if you have exactly one config), but I don't think that tradeoff is worth it.

This is the classname soup mess of TailwindCSS (when people don't precompile that away) manifested into the CLI...

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

That reminds me of self-extracting archives. Perhaps we could also create self- mutating programs that modify themselves to embed the flags.

Somehow i get this as I find myself either creating or using a generic e.g. "run.sh" which I then wrap into other scripts which call the generic one with the most common use cases / configurations.

You could skip the underlying mechanism by renaming Claude.exe and then it just passes the name as a new chat.

exiftool uses this method (among others) for many years. I'm surprised nobody mentioned this.

I love it because it's horrible, but in real life I'd just put the options inside the script (which is what you do anyway when you're too lazy to import argparse).

I'll confess to only have skimmed TFA but I love this idea.

this feels slightly insane and horrible but at the same time I can definitely see me using this for a phd project

this is new to me tbh

this is satire, right?

[dead]

[dead]

[dead]