3 ms·

> we would avoid many bash bugs in piped commands or shell scripts Food for thoughts: you take a step away from byte-array files. Why stick with the notion of

by moring 4y ago

> we would avoid many bash bugs in piped commands or shell scripts Food for thoughts: you take a step away from byte-array files. Why stick with the notion of using pipes for composition, or using the same language for the (command-line) UI and for scripting? Or, for that matter, with a universal "file" concept that tries to treat videos, pictures, executables, application-internal data files, database files and system configuration files the same (even before taking into account Unix's "special files" that aren't persistent, and are just high-level APIs sharing the same low-level APIs as actual files).

skissane 4y ago
> Food for thoughts: you take a step away from byte-array files. > Or, for that matter, with a universal "file" concept that tries to treat videos, pictures, executables, application-internal data files, database files and system configuration files the same POSIX and Windows have what are called "stream-oriented" or "bytestream" files – as far as the filesystem is concerned, the file is just an unstructured stream of bytes; applications can require those bytes to be in a certain format, but the filesystem is ignorant of that and won't enforce it. Many mainframe/minicomputer operating systems support additional types of files – such as record-oriented files, in which a file is divided into records – either fixed length (every record in file must be same size) or variable length (every record is preceded by a header which stores its length in bytes, sometimes also flags). The filesystem forces all reads/writes to be of whole records (or groups of them), partial reads/writes are prohibited. Some also had indexed files, where you basically have a key-value store built into the filesystem, with each record divided into a key and a value, the filesystem had an API to retrieve records by key instead of location in the file; commonly the file was internally structured as a B-tree or hashtable, but that was hidden from applications, the filesystem looked after those details. The designers of Unix knew about this complexity – they had extensive experience with IBM's OS/360 mainframe operating system which included it – and intentionally decided to avoid it, and give Unix only byte-stream files. The same design choice was made by designers of microcomputer/PC operating systems such as CP/M, MS-DOS and OS/2. Dave Cutler, chief architect of Windows NT, knew all about record-oriented files (OpenVMS has them), but decided against including them in Windows NT. We can question whether those were the right decisions – or, even if they were the right decisions at the time, they are not guaranteed to forever more remain so.

by moring 4y ago

skissane 4y ago

> Food for thoughts: you take a step away from byte-array files. > Or, for that matter, with a universal "file" concept that tries to treat videos, pictures, executables, application-internal data files, database files and system configuration files the same POSIX and Windows have what are called "stream-oriented" or "bytestream" files – as far as the filesystem is concerned, the file is just an unstructured stream of bytes; applications can require those bytes to be in a certain format, but the filesystem is ignorant of that and won't enforce it. Many mainframe/minicomputer operating systems support additional types of files – such as record-oriented files, in which a file is divided into records – either fixed length (every record in file must be same size) or variable length (every record is preceded by a header which stores its length in bytes, sometimes also flags). The filesystem forces all reads/writes to be of whole records (or groups of them), partial reads/writes are prohibited. Some also had indexed files, where you basically have a key-value store built into the filesystem, with each record divided into a key and a value, the filesystem had an API to retrieve records by key instead of location in the file; commonly the file was internally structured as a B-tree or hashtable, but that was hidden from applications, the filesystem looked after those details. The designers of Unix knew about this complexity – they had extensive experience with IBM's OS/360 mainframe operating system which included it – and intentionally decided to avoid it, and give Unix only byte-stream files. The same design choice was made by designers of microcomputer/PC operating systems such as CP/M, MS-DOS and OS/2. Dave Cutler, chief architect of Windows NT, knew all about record-oriented files (OpenVMS has them), but decided against including them in Windows NT. We can question whether those were the right decisions – or, even if they were the right decisions at the time, they are not guaranteed to forever more remain so.