On Thu, 05 Jun 2014 14:01:50 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: >> The whole concept of stdin and stdout is based on the idea of having a >> console to read from and write to. > > Not really; stdin and stdout are frequently connected to files, or pipes > to other processes. The console, if it exists, just happens to be a > convenient default value for them. Even on a system without a console, > they're still a useful abstraction.
If you had kept reading my post, including the bits you cut out *wink*, you'd see that I did raise that same point. Having stdin and stdout trivially generalises to the idea of replacing them with other files, or pipes. But the idea of having standard input and standard output in the first place comes about because they are useful for the console. I gave the example of Mac, which didn't have a command-line interface at all, hence no console, no stdin, no stdout. If a system had no command line interface (hence no consoles), why would you bother with a *standard* input file and output file that are never used? > But we were talking about encodings, and whether stdin and stdout should > be text or binary by default. Well, one of the design principles behind > unix is to make use of plain text wherever possible. What's plain text? *half a wink* Its a serious question. Some people think that "good ol' plain text" is EBCDIC, like IBM intended. To them, the letter "A" is synonymous with the byte 0xC1, and there's no need for an encoding (or so they think) because "A" *is* 0xC1. Of course, people on ASCII systems know better: who needs encodings when it is a universal fact that "A" *is* 0x41? *wink* > Not just for stuff > meant to be seen on the screen, but for stuff kept in files as well. > > As a result, most unix programs, most of the time, deal with text on > stdin and stdout. So, it makes sense for them to be text by default. And > wherever there's text, there needs to be an encoding. This is true > whether a console is involved or not. Agreed. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
