GNU bug report logs -
#26205
Unhappy with deprecating GREP_OPTIONS
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26205 in the body.
You can then email your comments to 26205 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 21 Mar 2017 15:40:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Thomas Güttler <guettliml <at> thomas-guettler.de>
:
New bug report received and forwarded. Copy sent to
bug-grep <at> gnu.org
.
(Tue, 21 Mar 2017 15:40:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I am not happy with GREP_OPTIONS being deprecated.
I asked here for help, but received no solution I like:
http://unix.stackexchange.com/questions/351083/colored-grep-output-not-grep-options-not-alias
Here the question:
I want colored output of `grep`.
.... But
* Strategy 1: GREP_OPTIONS. But this is deprecated. See http://www.gnu.org/software/grep/manual/html_node/Environment-Variables.html
* Stragegy 2: GREP_COLORS look like a solution at the first sight, but this does something different.
* Strategy 3: alias. This does not work for `find ... | xargs grep`, since xargs does not evaluate aliases.
* Strategy 4: Write a simple wrapper script. No, I think this is too dirty and makes more trouble than it solves.
* Strategy 5: patch the source code - No
* Strategy 6: Contact grep developers, ask for a replacement of GREP_OPTIONS
* Strategy NICE-and-EASY: ... this is missing. I have no clue.
How to solve this?
Now I follow Strategy 6.
Why is GREP_OPTIONS deprecated?
I guess this can do confusing things if you exclude directories via this environment variable.
But setting color=auto looks like something which does not do harm. May be I am too naive. Then please tell me.
What do you think?
Regards,
Thomas Güttler
--
http://www.thomas-guettler.de/
Information forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 21 Mar 2017 15:56:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 26205 <at> debbugs.gnu.org (full text, mbox):
Create a shell script named grep with
/usr/bin/grep --color "$@"
in it, and put it in a directory in your search path that is
found before the standard grep.
HTH,
Arnold
Thomas Güttler <guettliml <at> thomas-guettler.de> wrote:
> I am not happy with GREP_OPTIONS being deprecated.
>
> I asked here for help, but received no solution I like:
>
> http://unix.stackexchange.com/questions/351083/colored-grep-output-not-grep-options-not-alias
>
> Here the question:
>
> I want colored output of `grep`.
>
> .... But
>
> * Strategy 1: GREP_OPTIONS. But this is deprecated. See http://www.gnu.org/software/grep/manual/html_node/Environment-Variables.html
> * Stragegy 2: GREP_COLORS look like a solution at the first sight, but this does something different.
> * Strategy 3: alias. This does not work for `find ... | xargs grep`, since xargs does not evaluate aliases.
> * Strategy 4: Write a simple wrapper script. No, I think this is too dirty and makes more trouble than it solves.
> * Strategy 5: patch the source code - No
> * Strategy 6: Contact grep developers, ask for a replacement of GREP_OPTIONS
> * Strategy NICE-and-EASY: ... this is missing. I have no clue.
>
> How to solve this?
>
>
> Now I follow Strategy 6.
>
> Why is GREP_OPTIONS deprecated?
>
> I guess this can do confusing things if you exclude directories via this environment variable.
>
> But setting color=auto looks like something which does not do harm. May be I am too naive. Then please tell me.
>
> What do you think?
>
> Regards,
> Thomas Güttler
>
>
> --
> http://www.thomas-guettler.de/
>
>
>
>
Information forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 21 Mar 2017 16:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 26205 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 03/21/2017 10:39 AM, Thomas Güttler wrote:
>
> * Strategy 1: GREP_OPTIONS. But this is deprecated. See
> http://www.gnu.org/software/grep/manual/html_node/Environment-Variables.html
>
> * Stragegy 2: GREP_COLORS look like a solution at the first sight, but
> this does something different.
> * Strategy 3: alias. This does not work for `find ... | xargs grep`,
> since xargs does not evaluate aliases.
It can if you teach it to (assuming you are using a sh-like shell):
alias xargs='xargs '
(I can't help you if you are using a csh-like shell)
> * Strategy 4: Write a simple wrapper script. No, I think this is too
> dirty and makes more trouble than it solves.
What trouble does it cause? This our preferred recommendation, by the way.
> * Strategy 5: patch the source code - No
Why not? It's open source, so you are free to do so, for your local setup.
> * Strategy 6: Contact grep developers, ask for a replacement of
> GREP_OPTIONS
Which you've done. But it won't help, because we made a conscious
decision to kill environment variables that have the chance of breaking
scripts, and we are unlikely to be persuaded to change our minds.
> Why is GREP_OPTIONS deprecated?
Because it has the tendency to break unsuspecting scripts that don't
sanitize GREP_OPTIONS out of their environment. Environment variables
that change default output are very dangerous. Environment variables
that only modify behavior that has to be opted into (like GREP_COLORS)
are not as bad, but once you are explicitly opting into something, a
wrapper script is a lot more direct than a wrapper script + an
environment variable.
>
> I guess this can do confusing things if you exclude directories via this
> environment variable.
Yes, that was one of the things known to break scripts.
>
> But setting color=auto looks like something which does not do harm.
You're right that 'color=auto' tends to not break scripts, but
'color=always' does, and it gets rather hard, rather fast, if you try to
special-case WHICH aspects of GREP_OPTIONS are safe, vs. just a blanket
statement that GREP_OPTIONS is in general unsafe.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 21 Mar 2017 16:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 26205 <at> debbugs.gnu.org (full text, mbox):
On 03/21/2017 08:39 AM, Thomas Güttler wrote:
> Why is GREP_OPTIONS deprecated?
The main reason is that it breaks shell scripts. Scripts generally
expect 'grep' to behave as specified in POSIX and as implemented via
traditional 'grep' implementations. GREP_OPTIONS breaks this.
Some shell scripts work around the problem by explicitly unsetting
GREP_OPTIONS before they call 'grep'. However, most scripts don't, I
expect because their authors are not generally aware of this
compatibility issue. So in practice the convenience of GREP_OPTIONS can
be more trouble than it's worth.
> * Strategy 4: Write a simple wrapper script. No, I think this is too
> dirty and makes more trouble than it solves.
Why is it dirty? What trouble does it cause, other than the trouble
GREP_OPTIONS causes?
Added tag(s) wontfix.
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Wed, 21 Jun 2017 21:31:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 07 Nov 2017 21:20:01 GMT)
Full text and
rfc822 format available.
Message #19 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Why is GREP_OPTIONS deprecated?
> The main reason is that it breaks shell scripts. Scripts generally
> expect 'grep' to behave as specified in POSIX and as implemented via
> traditional 'grep' implementations. GREP_OPTIONS breaks this.
> Some shell scripts work around the problem by explicitly unsetting
> GREP_OPTIONS before they call 'grep'. However, most scripts don't, I
> expect because their authors are not generally aware of this
> compatibility issue. So in practice the convenience of GREP_OPTIONS can be more trouble than it's worth.
Here's a simpler fix: grep should test for an interactive shell before parsing GREP_OPTIONS. [There are a number of methods outlined in the man page](http://www.tldp.org/LDP/abs/html/intandnonint.html). At least two of these methods (PS1[1] and test "$($0)” are POSIX compatible if i’m not mistaken.
Interactive shell users can still export GREP_OPTIONS to get a persistent configuration. But this way, shell scripts get grep without the variable set, and if they really need to, can still use those options by calling “grep $GREP_OPTIONS …” explicitly.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-grep <at> gnu.org
:
bug#26205
; Package
grep
.
(Tue, 07 Nov 2017 23:59:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 26205 <at> debbugs.gnu.org (full text, mbox):
On 11/07/2017 01:00 PM, Ankeet wrote:
> grep should test for an interactive shell before parsing GREP_OPTIONS. [There are a number of methods outlined in the man page](http://www.tldp.org/LDP/abs/html/intandnonint.html).
Most of those methods would not work for grep, which is not a shell
script. The only exception (testing whether stdin is a terminal) would
run afoul of the GNU coding standards, which say that the behavior of a
program should not depend on whether standard input or output is a
terminal device. See:
https://www.gnu.org/prep/standards/html_node/User-Interfaces.html
Although we stretch those rules occasionally, stretching does not seem
advisable here.
bug closed, send any further explanations to
26205 <at> debbugs.gnu.org and Thomas Güttler <guettliml <at> thomas-guettler.de>
Request was from
Paul Eggert <eggert <at> cs.ucla.edu>
to
control <at> debbugs.gnu.org
.
(Sat, 02 Jul 2022 22:27:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 31 Jul 2022 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.