On Fri, Oct 6, 2017 at 8:27 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 6 October 2017 at 10:14, Marko Rauhamaa <ma...@pacujo.net> wrote: >> Generally, you shouldn't condition the program too much on such >> environmental details, although it is done. For example, the "ls" >> command outputs the directory listing in a (colorful) multi-column >> format when stdout is a terminal and in a (b/w) one-file-per-line format >> otherwise. > > Agreed that any behaviour of the program should be explicitly > controllable by command line arguments and/or configuration. But IMO, > it's perfectly OK for the *default* behaviour to be affected by the > environment, as long as that's done in a way that provides a good user > experience. Of course, what constitutes a "good UX" is a judgement > call... (Personally I think ls goes too far in how different it is in > the interactive case, for example).
Yeah, agreed. That said, though, there are even more ways for interactive mode to be configured. Your .bashrc quite probably has something like: alias ls='ls --color=auto' So if you type "ls" at the shell prompt, you get colour, but if you type "/bin/ls", you don't. The "=auto" part does what you're saying (using the tty-ness of stdout to control whether or not colour is used), but it's not even active unless you're using bash aliases. Generally, you should not have to worry about the behaviour of a program being drastically different if you append "| cat" to the command line. Which means you don't want TOO much difference between interactive mode and non-interactive mode, which in turn limits the extent of these changes to the defaults. It wants to be small changes only. Everything else should be controlled with options, not magic. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
