Interactive scripts (back on topic for once) [was Re: The "loop and a half"]

[Chris Angelico]

On Fri, Oct 6, 2017 at 8:27 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 6 October 2017 at 10:14, Marko Rauhamaa <marko at 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