stdout goes to file => no color by default.
stdout goes to file, color enabled by user, user still wants to use interactive prompt for whatever reason (errors are not colored) => user is insane.
Nice number by the way.
<img width="1008" alt="Screen Shot 2019-04-11 at 1 08 55 PM" src="https://user-images.githubusercontent.com/4149852/55932177-1e33c780-5c5b-11e9-8a78-22d1b19136dc.png">
win32: also ENABLE_VIRTUAL_TERMINAL_PROCESSING on stderr
========================================================
Follow-up on #277.
As discussed here[1], it's not really necessary when stdout and stderr are the
same console, but it doesn't hurt either.
Note that we did not test sys.stderr.isatty() in the code. This has been
considered, and deemed not a problem, since stdout is handled first (what
really matters) and we have a catch-all pass for any possible exception.
[1] https://github.com/jarun/googler/pull/277#discussion_r274245020
Drop tests/ci-test-wrapper
==========================
ci-test-wrapper is a relic of the past that's not necessary anymore. We can
now comfortably test all commits including README typo fixes.
Also in this commit:
- Add NUM_TEST_ITERATIONS and SLEEP_DURATION to .circleci/config.yml so that
secret environment variables are only used for actual secrets and don't need
to be shared with PR builds.
- Trap SIGINT in tests/test to make interrupting the script easier.
ENABLE_PROCESSED_OUTPUT and ENABLE_WRAP_AT_EOL_OUTPUT are the default, so when you get stdout console mode you get 3, you set it to 3 | 4 = 7; then when you get stderr console mode, which is the same console, you get 7, so setting it to 7 | 4 = 7 is a noop. Again, it doesn't hurt.
@guilt
> The messages sent to stderr through printerr will contain bad sequences, just like the original problem was with stdout.
Yeah, I’m saying after setting ENABLE_VIRTUAL_TERMINAL_PROCESSING on stdout, stderr understands ANSI color too, at least on my machine. The prompt use reverse video which works alright in both cmd and PowerShell. Do you have a problem there? (I’m just using tcsetattr, which I understand well, as a model to guess why it works. Both fd 1 and fd 2 eventually points to /dev/pts/something which tsetattr works upon, and I assume it works similarly on Windows.)
> Can we revert this patch and take any of the following paths...
I made sure this patch is strictly improvements without breaking anything that was working previously, so I don’t see why it needs be reverted. No color by default or always on warning are too heavy-handed and I myself as a ConEmu/Cmder user (when I’m using Windows, that is) won’t appreciate — color was working fine the first time I ported googler to Windows, that was what, two to three years ago? Adding a note to README is fine, it’s already full of things like this.
Also, consider this: Windows 7 EOL is near, Windows 8 is universally hated and admitting to using it in public is a no no ;), Windows 10 auto updates so probably no one is using a pre-1607 version, so this patch really covers almost the entire supported base of Windows users. The rest are like Python 3.3 users and who cares.
I thought about this and it turns out setting the mode flag for stdout makes stderr VT100-aware too. I know little about Windows, I guess it's because the two streams are sharing the same tty device (lacking Windows-specific terminology)? Like on *nix, `tcsetattr(3)` and friends from termios apply to the tty device and are not specific to any stream.
I can't think of case where someone would split stdout and stderr on two ttys, so we're probably good here.