On 6 September 2013 09:20, phi gcc wrote: > Hi Marc, > > Well it is more complex than I thought > > First I lied, I was using 4.6 (I was mislead by my host that is 4.8) > but actually I was running an Xgcc that is > > > U82$ arm-linux-gnueabi-gcc -v > Using built-in specs. > COLLECT_GCC=arm-linux-gnueabi-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper > . > . > . > Thread model: posix > gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) > > > Then I use it with a minimalist env with no TERM and no *_COLORS, I > use it remote like this > $ ssh node "cd build-dir; make" > > and I got garbage <esc>seq > > When doing it with an interactive ssh like this > > $ cd build-dir; > $ make > > All is fine > > The interactive session do have TERM=hpterm LANG=C and is fine > > The remote invocation with forced TERM=hpterm like > $ ssh node "cd build-node; export TERM=hp;make" > > fail, still have what I guess is ansi escape seq, so GCC don't respect > that TERM. GCC 4.,6 does not output ansi escape sequences, what you are seeing is probably UTF-8 output on a terminal that doesn't support it, so you need to set LANG correctly to match the font in use by your terminal. GCC uses fancy quotes instead of " and ' when it thinks your terminal supports UTF-8, which it determines by looking at $LANG. > Now to my grand surprise > $ ssh node "cd build-node; export LANG=C;make" > > Works fine, i.e no TERM= in env but LANG=C > > > So dunno why LANG=C as an influence on gcc coloring, without it, gcc > don't respect what you said about GCC_COLORS or TERM= This is nothing to do with colours, GCC 4.6 doesn't use colours.
