On 9/9/15 9:20 AM, Andrew Pinski wrote:
On Wed, Sep 9, 2015 at 11:11 PM, Mike Stump <mikest...@comcast.net>
wrote:
On Sep 3, 2015, at 9:45 AM, Jonathan Roelofs
<jonat...@codesourcery.com> wrote:
Moral of the story is: these tests fail in our environment, but
only because the regexes do not expect the presence of the ansi
color codes, and we can't trick the runtime into not emitting
them.
When the user says, I don’t want color; is color emitted? If so,
There's two ways to prevent emission of these color codes:
1) Set an env var
2) Make the output stream not a tty
Both of these pathways work.
that’s a bug, and needs to be fixed. If the user can, then,
dejagnu can. When it says, don’t use color, that should be
The issue is that I've got a remote target, and there are two
limitations of DejaGnu that prevent me from triggering either (1) or (2):
a) As Andrew says, DejaGnu can't set env vars for remote programs
under test.
b) DejaGnu makes itself appear to the remote program under test as if
it were a tty.
respected; just as if the user had said it. Anyway, a | decolor
more a la prune should be able to remove color, even if there were
no other way.
Are you suggesting that I use `dg-prune-output` to filter out these
color codes? I tried several variations on spellings of:
/* { dg-prune-output "\033\[[0-9\;]+[mK]" } */
but couldn't get any of them to work. (I'm not certain I got the
escaping correct, nor what it should be).
Jon
The issue is dejagnu cannot (at least in the current implementation
of the remotes), cannot set an env that stays alive before invoking
the program (though maybe it could use the env program to do the
invoking).
I’m not a fan of the changes as is.
--
Jon Roelofs
jonat...@codesourcery.com
CodeSourcery / Mentor Embedded
