--no-ansi is not stripping colours

[kylef]

$ pod --version
[!] The specification of arguments as a string has been deprecated Pod::Command::Lib::Docstats: `NAME`
0.33.0

$ env
Apple_PubSub_Socket_Render=/tmp/launch-en5dW9/Render
CMD_DURATION=4.40s
COLORFGBG=7;0
DESTINATION=/var/folders/x3/rxbktkzx4xlf98p4bsn60p040000gn/T/iTerm 1.0.0.20140421 Update
EDITOR=vim
GEM_HOME=/Users/kylef/gems
HOME=/Users/kylef
ITERM_PROFILE=Default
ITERM_SESSION_ID=w2t0p0
LANG=en_GB.UTF-8
LOGNAME=kylef
LSCOLORS=Gxfxcxdxbxegedabagacad
PATH=/Users/kylef/gems/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
PIP_REQUIRE_VIRTUALENV=true
PWD=/Users/kylef/Projects/cocode/palaver
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/tmp/launch-2JXa9u/Listeners
TERM=xterm-256color
TERM_PROGRAM=iTerm.app
TMPDIR=/var/folders/x3/rxbktkzx4xlf98p4bsn60p040000gn/T/
USER=kylef
__CF_USER_TEXT_ENCODING=0x1F5:0:0
__CHECKFIX1436934=1
__fish_bin_dir=/usr/local/Cellar/fish/2.1.0/bin
__fish_datadir=/usr/local/Cellar/fish/2.1.0/share/fish
__fish_help_dir=/usr/local/Cellar/fish/2.1.0/share/doc/fish
__fish_sysconfdir=/usr/local/Cellar/fish/2.1.0/etc/fish

[fabiopelosin]

Closed by 6c7f6b3

[AliSoftware]

👍

[kylef]

Sorry guys, missed something with the yellow warning:

[fabiopelosin]

That happens during class evaluation much earlier than CLAide::Command::run

[fabiopelosin]

I don't have a well formed opinion about this yet... the options that I see are:

• Remove the colour form the warning
• Do nothing as it is a temporary problem
• Refactor to print the warnings in CLAide::Command::run

None of those look optimal to me.

[fabiopelosin]

I think that we shouldn't fix this as it is a temporary problem

[fabiopelosin]

Closing until someone weight-ins expressing a reason about why we should fix.

[alloy]

It’s temporary now, but other warnings will be introduced at some point, so it’s a recurring problem.

[fabiopelosin]

This problem doesn't affect all warnings but specifically this one because the warning is presented during the initialization of the concrete CLAide sub-classes: https://github.com/CocoaPods/CLAide/blob/master/lib/claide/command.rb#L502-L503

This happens before the machinery to handle the ANSI flag is setup. It is very unlikely that we encounter a similar warning. Moreover, handling it properly would require extensive changes to the architecture of CLAide (i.e. to parse and handle the --no-ansi flag before loading the classes of the concrete CLAide commands).

[fabiopelosin]

Another important thing to keep in mind is that the --no-ansi has been introduced to not pollute the standard output of the executables when used by a script (not for visual preference). The warnings are printed to the standard error stream and thus it is less relevant to strip the ANSI codes from them, although still desiderable for visual consistency.

[alloy]

I was actually thinking more of buffering such early warnings in a simple array and displaying them as soon as the options were parsed and evaluated. That might still be too much, but I think that an app like AppCode does not like ANSI, ever?

[fabiopelosin]

Good alternative. A bit annoying that we already do that in CocoaPods (to show warnings at the end of the output so the are more visible to the user). If we decided to go that route I would be tempted to move that logic here.

I think that an app like AppCode does not like ANSI, ever?

Why? If you don't know hot to interpret them they just look like any other stream of characters... no?

[alloy]

Why? If you don't know hot to interpret them they just look like any other stream of characters... no?

Yeah I have actually no clue, so never mind that :D

I’m on the fence about all of this. @kylef is right from a purist point of view of course.

[fabiopelosin]

I'm generally on the purist side on this things, but is really too and edge case for me.