Okay. Now go to File Explorer and right click to create a new text file and try to name it “con”. That’s three letters: con. You can’t do it. Not allowed. Because CON has been reserved (in every directory on every drive) for piping to and from console since MS-DOS 2 or so. (I think 2 is when they stole pipes from Unix)
Okay. Now, open just about any kind of desktop window and double click in its upper left corner. In > 9 windows out of 10 that action still closes the window even though the “close window” button was moved to the upper right corner by Windows 3. Even though a bunch of modern applications don’t even have any icon there at all any more.
“aux” is the same. And file ending doesn’t matter. Short version: I had this fun experience a few years back. I used cygwin and Vim for coding and used some old compiler for embedded systems. I created a file called “aux.c” in cygwin. No problem. I compiled my code. Got very strange error. Trouble shooted, tested a bunch of things. Wasted lots of hours before I figured out that “aux” was reserved on one abstraction later but not on another, so Vim/cygwin could access it. My dos compiler couldn’t. Fun times.
I still double-click the left corner every now and then. I’ve found myself using CTRL+INS and Shift+INS lately because CTRL+C/V keeps giving me very inconsistent results. Particularly in terminals. I remember using the the same hotkeys in MS-DOS editor.
Ctrl+C and Ctrl+V for copy and paste come from non-Unix (I’d say Windows itself, but they may have stolen it from elsewhere), and so it makes sense that those two keys have other special meanings under Unix and its descendants.
Specifically, they mean “Stop what you’re doing” and “The next character is to be entered without special meaning” in most shells, the most common programs that run, often as the main program, in/on a terminal.
As such, most terminal emulators in Linux GUIs reserve those keypresses for their Unix-y functions. Most of the good ones move copy and paste to Ctrl+Shift+C and Ctrl+Shift+V instead.
MS-DOS and Windows command prompts also inherit their use of Ctrl+C from Unix, by way of 86-DOS and CP/M, and were in there long before Microsoft adopted Ctrl+C for copy in a GUI, which is where those other Insert-based keybinds you mention came in.
For an example of Unix Ctrl+V, try echo hello[Ctrl+V][Ctrl+H]world in a Linux terminal shell and press Enter. You’ll see the command as echo hello^Hworld and when you press Enter, it will display hellworld, because that embedded Ctrl+H is a backspace.
Okay. Now go to File Explorer and right click to create a new text file and try to name it “con”. That’s three letters: con. You can’t do it. Not allowed. Because CON has been reserved (in every directory on every drive) for piping to and from console since MS-DOS 2 or so. (I think 2 is when they stole pipes from Unix)
Okay. Now, open just about any kind of desktop window and double click in its upper left corner. In > 9 windows out of 10 that action still closes the window even though the “close window” button was moved to the upper right corner by Windows 3. Even though a bunch of modern applications don’t even have any icon there at all any more.
“aux” is the same. And file ending doesn’t matter. Short version: I had this fun experience a few years back. I used cygwin and Vim for coding and used some old compiler for embedded systems. I created a file called “aux.c” in cygwin. No problem. I compiled my code. Got very strange error. Trouble shooted, tested a bunch of things. Wasted lots of hours before I figured out that “aux” was reserved on one abstraction later but not on another, so Vim/cygwin could access it. My dos compiler couldn’t. Fun times.
I still double-click the left corner every now and then. I’ve found myself using CTRL+INS and Shift+INS lately because CTRL+C/V keeps giving me very inconsistent results. Particularly in terminals. I remember using the the same hotkeys in MS-DOS editor.
This is how I get around an application at work that prevents copying and pasting with CTRL+C/V. I was surprised to find that it worked.
Ctrl+C and Ctrl+V for copy and paste come from non-Unix (I’d say Windows itself, but they may have stolen it from elsewhere), and so it makes sense that those two keys have other special meanings under Unix and its descendants.
Specifically, they mean “Stop what you’re doing” and “The next character is to be entered without special meaning” in most shells, the most common programs that run, often as the main program, in/on a terminal.
As such, most terminal emulators in Linux GUIs reserve those keypresses for their Unix-y functions. Most of the good ones move copy and paste to Ctrl+Shift+C and Ctrl+Shift+V instead.
MS-DOS and Windows command prompts also inherit their use of Ctrl+C from Unix, by way of 86-DOS and CP/M, and were in there long before Microsoft adopted Ctrl+C for copy in a GUI, which is where those other Insert-based keybinds you mention came in.
For an example of Unix Ctrl+V, try
echo hello[Ctrl+V][Ctrl+H]worldin a Linux terminal shell and press Enter. You’ll see the command asecho hello^Hworldand when you press Enter, it will displayhellworld, because that embedded Ctrl+H is a backspace.Other DOS reserved names include PRN, LPT1, LPT2…
copy file.txt prnwas an interesting shortcut for printing things 35 years ago.The Linux equivalent of that is
cat file.txt > /dev/lp0. It still works if you have a parallel port printer that accepts plain text.I tried the upper left corner, but it doesn’t work
What if I create the file con in wsl, will it also not be allowed?
You can create them under Linux but this possible breaks windows
Never under any circumstances especially if you want to have some free time or petty revenge create such a file on a company wide shared drive
If you do manage to create it, you’ll have trouble accessing or deleting it.
I dare you to try it
I think it’s likely it just won’t work either but I don’t want to break anything on a work machine 😁
Just say you wanted to run
echo "someField=someValue" > .confbut made a typo in the target filename or so 😜