1 |
On Mon, Sep 02, 2013 at 09:41:28PM +0200, Michał Górny wrote: |
2 |
> Dnia 2013-09-02, o godz. 14:21:52 |
3 |
> William Hubbs <williamh@g.o> napisał(a): |
4 |
> |
5 |
> > On Mon, Sep 02, 2013 at 01:33:19PM +0200, Michał Górny wrote: |
6 |
> > > Dnia 2013-09-01, o godz. 16:49:34 |
7 |
> > > William Hubbs <williamh@g.o> napisał(a): |
8 |
> > > |
9 |
> > > > On Sat, Aug 31, 2013 at 10:48:32PM +0200, Michał Górny wrote: |
10 |
> > > > > Dnia 2013-08-31, o godz. 11:26:30 |
11 |
> > > > > Ulrich Mueller <ulm@g.o> napisał(a): |
12 |
> > > > > |
13 |
> > > > > > >>>>> On Sat, 31 Aug 2013, Michał Górny wrote: |
14 |
> > > > > > |
15 |
> > > > > > > And time for a small update. |
16 |
> > > > > > |
17 |
> > > > > > In git-r3_checkout: |
18 |
> > > > > > |
19 |
> > > > > > git --no-pager diff --color --stat \ |
20 |
> > > > > > ${old_commit_id}..${new_commit_id} |
21 |
> > > > > > |
22 |
> > > > > > I'd rather omit the --color option, otherwise log files will contain |
23 |
> > > > > > escape sequences. |
24 |
> > > > > |
25 |
> > > > > I'd rather leave it. The diff is more for pretty-printing anyway, it |
26 |
> > > > > shouldn't really matter in the logs. |
27 |
> > > > |
28 |
> > > > Please don't. I also do not want escape sequences in log files. |
29 |
> > > |
30 |
> > > Ok, '--color' removed. However, I think we should work something out to |
31 |
> > > get both parties satisfied. Maybe portage feature or a tool to 'uncruft' |
32 |
> > > logs from escape sequences since many people actually benefit from them. |
33 |
> > |
34 |
> > All, |
35 |
> > |
36 |
> > I'm starting a new thread on this, because I think it might warrant some |
37 |
> > discussion. |
38 |
> > |
39 |
> > I can see why someone might want to use escape codes for color displays, |
40 |
> > etc. However, imo, escape codes do not belong in log files. |
41 |
> |
42 |
> Well, colors are not the only thing that uses escape sequences. They |
43 |
> are used pretty often for various kinds of progress reporting -- |
44 |
> percentages, progress bars. Many tools simply don't implement any other |
45 |
> kind of progress reporting, so sometimes it's either escape sequences |
46 |
> or long waiting with no signs of life. |
47 |
> |
48 |
> > mgorny says many people benefit from having escape codes in log |
49 |
> > files, but I see no benefit from it, and I don't like going through |
50 |
> > build.log because of them. If you load a build.log into an editor, the |
51 |
> > escape sequences are basically trash characters that get in the way. |
52 |
> |
53 |
> I said people benefit from having them output during the build process. |
54 |
> Logs are a different thing, that's why I suggested having a feature |
55 |
> that would remove those from output when generating logs. |
56 |
|
57 |
There is a NOCOLOR variable you can set in make.conf, but that would |
58 |
require users to set it, and it also affects the display. |
59 |
|
60 |
How does portage write build.log? |
61 |
|
62 |
> > Another consideration is if someone puts messages from a build.log |
63 |
> > directly in a bug and the messages contain escape codes, this will crash |
64 |
> > things like pybugz because bugzilla doesn't filter out the escape |
65 |
> > character. |
66 |
> |
67 |
> That is a bug in pybugz and not an argument, you know. |
68 |
|
69 |
I said "things like pybugz". |
70 |
|
71 |
Bugzilla allowing control characters in the xml is the issue. The python |
72 |
xmlrpc library raises an exception for malformed xml because of it, so |
73 |
there isn't much pybugz, or anything that uses that library, can do |
74 |
about it. |
75 |
|
76 |
William |