Dotfiles being hidden is a UNIXv2 mistake (2012)

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by hsbauauvhabzb on Thursday August 11, 2022 @05:53PM (#32432210)

I think that text output protocol is the wrong way of thinking about it. It should be a rich data stream capable of advanced features like objective stuff. Think ps, but then you’re able to navigate the output and perform additional functions. I think a subset of html would work for this.

I think the biggest danger would be scope creep, but a terminal shouldn’t just be thought of as text.

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by wruza on Thursday August 11, 2022 @08:16PM (#32433412)

Think ps, but then you’re able to navigate the output and perform additional functions

We already have gtk, qt, appkit, win32, web based frontends for almost everything, and none of them produced anything remotely interoperable. The main advantage of just text is that you see its structure right there in a terminal and may reason about it without referring to the documentation of ps result-related set of structures with all the possible bells and whistles embedded into a large xml-like document schema (which is of course full of legacy and references to other specs, because compatibility and standardization).

[ Parent | on HN ]

Re:Dotfiles being hidden is a UNIXv2 mistake (2012) by benlivengood on Thursday August 11, 2022 @07:15PM (#32433011)

Unix chose the midpoint between raw unformatted byte input and output (*argv being a raw byte array and stdout being binary or not existing at all and outputs would be configured by whatever was passed into argv) and structured results or a typed-function interface (like COM or CORBA or XML). Either extreme would have been untenable for a cohesive simple operating system, but I do wish Unix had leaned a bit farther toward the typed-interface design. We even had all the ASCII file/group/record/unit control characters.

[ Parent | on HN ]