I was about to say "Which is essentially leaking the existence of something terrible inside. They should be embarrassed to say something like this in public. Like saying you can't have %s or $PS1. Why the hell not? What are you doing with this user-supplied input?"
But maybe it's more about what everyone else might do with a channel name. Ie they might cut & paste it anywhere, and I guess windows users aren't expected to escape their own strings when pasted into cmd or powershell or wsl.
The Something Terrible in this case is early DOS which did not have separate folders. So the device files were in the same namespace as the user's files, so the user couldn't name a file CON or LPT1. These are preserved for backwards compatibility. To this day you can write a program that writes to a CON file in any folder, and the program will print the write to console.
Another interesting aspect of this, which I remember specifically from reading MS-DOS manuals in the 90s as a kid (I was an incredibly fun 12 year old) is that this choice was an intentional one done in the name of flexibility. These device names were correctly written with a colon, but you are allowed to omit the colons. For instance:
copy con lpt1
And
copy con: lpt1:
were interchangeable. If they’d chosen to not save users keystrokes and force colons when referencing devices, I’m not positive, but I think it would have eliminated the need for many of these reserved words in file names in general.
Also, side note, the “copy con outputfilename.txt” idiom is one that I still can’t ever remember how to do the equivalent on UNIX/Linux!
This has actually changed a bit in the last few years. In Windows 11 writing to `.\CON` will write to the file but writing to `CON` will still write to the console.
I thought this as well but there's plenty of dangerous commands that aren't escaped here. I'm assuming it's a limitation of it actually writing something to the filesystem, hopefully your own (with the desktop app) and not one in Azure.
In the mid-90s there was a fun and short period of time where IRC clients like mIRC could be set to auto-receive files through DCC.. and would happily write to names like LPT1 (which of course would just write the data directly to the recipient’s printer)
If you do embedded stuff you can easily get above COM100 if you're doing something like testing (if a USB to serial converter has a serial number, it gets a unique COM port). Although I don't think these high numbers have any effect on the file system, just the legacy low numbered ones DOS could have.
IIRC those were mapped to specific I/O and IRQ Ports back in the day.
COM1: I/O port 0x3F8, IRQ 4
COM2: I/O port 0x2F8, IRQ 3
COM3: I/O port 0x3E8, IRQ 4
COM4: I/O port 0x2E8, IRQ 3
I also remember, there was a while where there was no IRQ sharing. So some machines couldn't use all the COM ports available. Or you'd add in like a modem, and would have to disable the onboard COM port if it was using the same IRQ.
Back in the day many of my clients had Windows NT/2000 machines running RAS or RRAS with multi-port serial cards connected to modems for employee remote access. Usually these would be 8 or 16 serial ports per card with multiple cards installed per server.
