On Wed, 15 Aug 2018 18:51:15 +0200
Phil Sutter <p...@nwl.cc> wrote:
> On Wed, Aug 15, 2018 at 10:43:25AM -0600, David Ahern wrote:
> > On 8/15/18 10:39 AM, Phil Sutter wrote:
> > > On Wed, Aug 15, 2018 at 10:24:31AM -0600, David Ahern wrote:
> > >> On 8/15/18 10:21 AM, Phil Sutter wrote:
> > >>> Add an additional prerequisite to check_enable_color() to make sure
> > >>> stdout actually points to an open TTY device. Otherwise calls like
> > >>>
> > >>> | ip -color a s >/tmp/foo
> > >>>
> > >>> will print color escape sequences into that file. Allow to override this
> > >>> check by specifying '-color' flag more than once.
> > >>>
> > >>> Signed-off-by: Phil Sutter <p...@nwl.cc>
> > >>> ---
> > >>> Changes since v1:
> > >>> - Allow to override isatty() check by specifying '-color' flag more than
> > >>> once.
> > >>
> > >> That adds overhead to my workflow where I almost always have to pipe the
> > >> output of ip to a pager.
> > >
> > > alias ip='ip -color -color'
> >
> > no. Don't impact existing users.
>
> That's a possible fix for *your* workflow. If applied to the shell
> handling that workflow, it won't impact existing users.
>
> > > Another alternative may be to introduce -autocolor flag. Establishing
> > > the same syntax as used by 'ls' is not as trivial due to the simple
> > > commandline parsing used in 'ip'.
> >
> > I disagree with ignoring or overriding an argument a user passes in. You
> > are guessing what is the correct output and you are guessing wrong.
> > There is nothing wrong with piping output to a file and the viewing that
> > file through 'less -R'.
> >
> > If a user does not want the color codes in the file, then that user can
> > drop the -color arg. iproute2 commands should not be guessing.
>
> OK, I got it. Should I respin the fixes or will you apply the series
> partially?
>
> Thanks, Phil
Please follow the color conventions of grep and ls to have
consistent user experience.
-c == --color=always
and add never and auto.
