4 ms·

> The ‘Unix philosophy’ originated with Ken Thompson's early meditations on how to design a small but capable operating system with a clean service interface.

• mbrock 11y ago
  What do you mean by "text"?
  • alkonaut 11y ago
    Exactly. That's one of the biggest problems with text-only interfaces.
    • pdkl95 11y ago
      Maintaining IPC/RPC as text has the significant advantage of keeping the programs involved honest, approachable, and easier to debug. Just being able to see the interface by running the program (or reading the config file) makes it a lot easier to learn[1], and bugs in text formats can often be seen visually (or marked in an editor). The alternative - binary structures - require complex data definitions where you have to care about stuff like exact byte lengths when you have to convert between big/little endian. Some people like to claim that binary is faster, but your bottleneck is not going to be strtol(3). As for advantages in parsing - you still have to parse the binary structure you just read. I suspect most people that think "parsing text" is difficult are confusing the parser with lexer; the latter is the only part that changes when you switch between text and binary formats. In the long run the initial investment in a text interface can be cheaper than wasting time debugging binary structures. Even more important when thinking long-term: it is a lot easier to inspect a text interface from the outside without the consent or availability of the original author. If you have an old program binary that was used in production for years and no source code or documentation, which would you rather try to debug? An opaque binary file? Or something in JSON or INI format? [1] however, this is not an excuse to skip proper documentation
      • jrmenon 11y ago
        Fully agree with you here. Wanted to also add that even the 'parsing' of text is easy by using standard tools like awk, sed etc.. rather than writing custom code to debug binary protocols. In addition with protocols like JSON, it is easily extensible without worrying about where new data fields are added as long as backward compatibility is maintained - i.e. if designed correctly, the server can be upgraded to accept new fields while still working with older clients.
      • alkonaut 11y ago
        "Text" in a computer is bytes + metadata about those bytes. Without that metadata, it's just bytes. Exactly that is what unix pipes are: a streams of bytes, not streams of text. Ironically, the tools that are happiest about these streams are of course those tools that don't care about text but just stream bytes. The pain occurs when the tools actually need to parse the text. I would agree much more with the unix design, and think it was a much better implementation of the unix philosophy, if the glue layers were strictly specified or demanded that programs could negotiate things like encodings. Somewhere between "just bytes" and "binary structures" there has to be a reasonable simple format for program communication. Structured text, or text with a small metadata header (like BOM, but done right) for example.
        • pdkl95 11y ago
          see locale(1) and locale(7) This is why you the predefined character classes in regular expressions. For example, setting LC_CTYPE changes the meaning of '[[:alpha:]]' and sort(1) respects LC_COLLATE. A lot of work has already been done to solve these problems.
          • zvrba 11y ago
            > A lot of work has already been done to solve these problems. Not nearly enough. You write a script which expects a 'file' at some place, but it will break in french locale because 'file' will be replaced with something like 'fichier'. Sure, you can run under C locale, but then some other script, written for french locale will break. Not to mention date formatting, number formatting, etc. In comparison, binary or XML (!) become very attractive.
  • zvrba 11y ago
    Semi-rigid, informally specified output meant for easy inspection by humans. The output of `ifconfig -a` for example. (That's the worst offender, most other commands have a better-formatted output.) As a general rule of thumb: if you have a command pipeline that would break because programs in it handle locale differently, it's most definitely text-based program. I like the idea of Power shell: programs pipe formatted (binary) objects between them, and there exist commands to print them out in a nicely formatted way to the terminal. But it's objects. I can extract information through named fields instead of through magic indexes and regexpes in awk/sed/perl oneliners. IOW, proper object (meta)model, not sucky text streams. Text is great for long-term storage, but awful for data in flight. UNIX ignored this distinction and decided to use text for everything.
    • mzs 11y ago
      env -i ifconfig -a | ... solves a lot (like locale or other special env vars), but yeah...
• nwmcsween 11y ago
  I thought the same but what are the alternatives? Use a format like json? What happens when the format can't express what I want? The other issue is the output is now deeply intertwined with the program because it's now an API, although the same could be said about text output.
  • ben11kehoe 11y ago
    PowerShell gives a good alternative: the things passed between the programs should be objects. It requires, of course, that everything is communicating with a common runtime, but for a shell that is not the biggest burden.