On Mon, Nov 11, 2013 at 09:43:30PM +0100, Ingo Molnar wrote:
> * Michal Marek wrote:
> > On Mon, Nov 11, 2013 at 03:27:43PM +0100, Borislav Petkov wrote:
> > > From: Borislav Petkov
> > > Subject: [PATCH] Kbuild: Ignore GREP_OPTIONS env variable
> > >
>
* Michal Marek wrote:
> On Mon, Nov 11, 2013 at 03:27:43PM +0100, Borislav Petkov wrote:
> > From: Borislav Petkov
> > Subject: [PATCH] Kbuild: Ignore GREP_OPTIONS env variable
> >
> > When building the kernel in a shell which defines GREP_OPTIONS so that
> >
On Mon, Nov 11, 2013 at 03:27:43PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
> Subject: [PATCH] Kbuild: Ignore GREP_OPTIONS env variable
>
> When building the kernel in a shell which defines GREP_OPTIONS so that
> grep behavior is modified, we can break the generation
From: Borislav Petkov
Subject: [PATCH] Kbuild: Ignore GREP_OPTIONS env variable
When building the kernel in a shell which defines GREP_OPTIONS so that
grep behavior is modified, we can break the generation of the syscalls
table like so:
__SYSCALL_COMMON([01;31m[K0[m[K, sys_read, sys_read
Dne 30.10.2013 17:06, Borislav Petkov napsal(a):
> So I had defined GREP_OPTIONS=--color=always on one of my boxes and had
> forgotten about it and the kernel build started failing because we use
> grep quite a while in the tree and it started issuing shell color markup
> which generated garbage fi
g the kernel or let the user figure it
out himself that he should be using
GREP_OPTIONS=--color=auto
in the first place and it is his own moronic fault if he does 'always'?
Opinions, comments?
Thanks.
--
From: Borislav Petkov
Subject: [PATCH] Kbuild: Ignore GREP_OPTIONS env variable
MI
6 matches
Mail list logo