| Summary: | app-shells/bash: add color alias for watch in /etc/bash/bashrc | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vladimir Varlamov <bes.internal> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | kfm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
oh that is
> alias watch='watch --color'
I don't think that it would be appropriate for Gentoo to do this. Consider the impact of the existing aliases that Gentoo defines. Let's take "ls --color=auto" as an example. The impact is for ls(1) to be able to format its own output depending on whether STDOUT is found to be a terminal. It knows whether STDOUT is a terminal because it uses the isatty(3) function to test the relevant file descriptor. By contrast, the impact of the -c option on watch(1) is to determine how it treat its input, which always comes from a pipe. Keep in mind that no sensibly written program would ever try to write colour sequences to a pipe unless it is forced into doing so. Taking ls as an example again, try to run the following: watch -c 'ls -l --color=auto' You will see that there is no colour at all, nor should there be. Instead, you would have to force ls to produce colour: watch -c 'ls -l --color=always' Even then, there are many programs that do not provide an option for output to be forcibly colourised. Essentially, the fact that your terminal emulator may be colour-capable is not an adequate reason to always specify -c, in and as of itself. If you go as far as to coerce a program writing to a pipe to output colour sequences then you should also then know to specify the -c option to support that particular use-case. Otherwise, there is no compelling reason for a Linux distribution to override the default behaviour of the watch utility. |
Subj. > alias watch='watch --color=auto'