5 ms·
The various DEC operating systems (RT-11, VMS, etc.) had PIP (Peripheral Interchange Program) which allowed you to copy files to devices (such as a printer). C
by anonymousiam 5y ago
The various DEC operating systems (RT-11, VMS, etc.) had PIP (Peripheral Interchange Program) which allowed you to copy files to devices (such as a printer). CP/M had PIP, but did not implement the devices in the filesystem, which MS/DOS did. The result of putting specially named files in the operating system was that files were not always files and strange behavior would occur in fringe use cases.
The basename (without the extension) had certain reserved names such as CON, PRN, AUX, PTR, PUN, etc. Originally these names always had a trailing colon to identify them as devices, but MS/DOS dropped that. MS/DOS kept the trailing colons for disk drive identification, but not much else.
This capability could be used to make a batch files (.BAT) without any editor on the system. One could type: COPY CON RUNME.BAT, and then type in the wanted lines of the batch file. The end-of-file character (^Z 0x1A) was the same on CP/M and DOS, unlike (^D 0x04) on Unix.
https://gordonbell.azurewebsites.net/Digital/RT-11%20System%20Users%20Guide%201977.pdf https://gordonbell.azurewebsites.net/Digital/RT-11%20System%...
- dTal 5y ago>files were not always files and strange behavior would occur in fringe use cases. coughs in Unix
- anonymousiam 5y agoTrue, device nodes and other special files exist in Unix, but they are usually contained to special directories.
- cperciva 5y agoYou can create sockets and fifos anywhere. Device nodes are the only special ones which are generally confined to specific locations.
- deleted 5y ago[deleted]
- umanwizard 5y agoI think on BSDs at least you can theoretically put device nodes wherever you want (but there’s no good reason not to put them in /dev where everything expects them to be).
- skissane 5y agoI'm pretty sure on Linux too there is nothing stopping you from putting a device node in any directory either. By convention they live in /dev (or its subdirectories), but there is nothing technically enforcing that convention. (udev assumes they live under /dev. I'm not sure if /dev is hardcoded in udev or configurable. But you don't have to use udev anyway, you can create device nodes manually.)
- yjftsjthsd-h 5y agoYeah, it's just a mknod away provided your filesystem isn't mounted nodev
- tremon 5y agoRunning a service inside a chroot might require some combination of /dev/{null,random,console,log} to be present inside the chroot, and bind-mounting /dev exposes the entire underlying system (raw disk nodes) inside the chroot. So there's actually a good reason for being able to create device nodes outside /dev.
- cperciva 5y agoOn FreeBSD you can mount devfs but tell it to only expose a subset of the device nodes, for exactly this reason.
- kragen 5y agoYeah, I used to do this to NFS-export a root filesystem for my diskless Sun-3. The NFS server was running Linux and the Sun was running IIRC NetBSD, so some of the device numbers in the Sun's /dev needed to be different. Pretty rickety setup but it worked okay. I don't recall ever accidentally overwriting my root filesystem or hanging up the modem line by accessing the bogus device nodes.
- anonymousiam 5y agoShould have been more clear. Yes, (at least in Linux) you can mknod a special file anywhere, but the directory hierarchy is taken in context when you open the file. On MSDOS, you can open AUX or CON in any directory, even though no such named file exists anywhere in the filesystem. THAT is a poor implementation, and would probably be considered a bug by most developers if it were offered as a solution today.
- rbanffy 5y agoYou know… it was called QDOS for a reason.
- hnlmorg 5y agoThere wasn't directories in the first release of DOS. So I can forgive those special devices being location agnostic. However removing the device suffix (the colon) is really what causes this to be a bug. You either have persistent files with special attributes that identify it as a device, or you namespace your devices with characters that cannot be used in a file name. But you don't allow your devices to be valid file names and have them invisible on the file system.
- mbreese 5y ago> However removing the device suffix (the colon) is really what causes this to be a bug. I never thought about it, but when you consider ‘:’ as the device suffix, this makes directory structures make more sense to me on Windows. C:\foo\bar makes more sense to me if it is the ‘C:’ device. Calling it a ‘C drive’ with a separate namespace never made sense to me. Somehow thinking of it the ‘C:’ device in an anonymous global hierarchy makes more sense to me.
- dredmorbius 5y agoDevice files require that the mount point allow device files. That's a mount-time option, and "nodev" will prevent this. You'll still be able to create named pipes (mkfifo), but mknod will fail. This is handy for filesystems with a poorly developed sense of user ownership and permissions, say, msdos or vfat. I tend to mount my /tmp space nodev and nosuid, as occasionally you'll find poorly-written, or nefariously-intended programs attempting to do such things there.
- inopinatus 5y agoThe comparison to Unix stumbles because the behaviour of named pipes, Unix-domain sockets, and device special files, in a regular filesystem, is not based on their filename, but on the arguments to mknod(2) at their creation.
- scruffyherder 5y agoIt goes back to version 2 where there was a planned merge of Xenix and dos. You can even get it using the Unix path slashes in the 2.11 source code.