[gentoo-user] 'if echo hello' in .bashrc

[gentoo-user] 'if echo hello' in .bashrc

[Stroller]

Hi there,

I've just realised that grep hasn't been highlighting results in  
colour, and it occurred to me that I was sure it has supported this  
facility for some time. Thus I discovered the --colour=always flag to  
grep and trying to make this permanent I stumbled upon this site: http://www.ccs.neu.edu/home/katz/unix-colors.html

To find the part to which I refer you'll need to scroll down about  
halfway through that page to "Colorize grep"; the author advises adding:

   if echo hello|grep --color=auto l >/dev/null 2>&1; then
     export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
   fi

to ~/.bashrc

Why does he echo hello, please?  Is this to ensure that the file is  
not sourced by a non-interactive shell, or by a script or something? I  
understood that that was the difference between .bashrc  
& .bash_profile, anyway - that "interactive commands" like colourising  
stuff should go in .bashrc, to use /usr/local/mount instead of the  
system on then one might alias that in .bash_profile.

It's early in the morning here, so obviously I'm not getting something.

Thanks in advance for any pointers,

Stroller.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Fri, 8 May 2009 14:38:58 +0100
Stroller <stroller@stellar.eclipse.co.uk> wrote:

> To find the part to which I refer you'll need to scroll down about  
> halfway through that page to "Colorize grep"; the author advises adding:
> 
>    if echo hello|grep --color=auto l >/dev/null 2>&1; then
>      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
>    fi
> 
> to ~/.bashrc
> 
> Why does he echo hello, please?

Some greps (like BSD one) might not support '--color' option, so "echo
hello|grep --color=auto l" will return error code, skipping if clause,
and won't break grep operation by adding an unsupported option.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] 'if echo hello' in .bashrc

[Stroller]

On 8 May 2009, at 15:01, Mike Kazantsev wrote:

> On Fri, 8 May 2009 14:38:58 +0100
> Stroller <stroller@stellar.eclipse.co.uk> wrote:
>
>> To find the part to which I refer you'll need to scroll down about
>> halfway through that page to "Colorize grep"; the author advises  
>> adding:
>>
>>   if echo hello|grep --color=auto l >/dev/null 2>&1; then
>>     export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
>>   fi
>>
>> to ~/.bashrc
>>
>> Why does he echo hello, please?
>
> Some greps (like BSD one) might not support '--color' option, so "echo
> hello|grep --color=auto l" will return error code, skipping if clause,
> and won't break grep operation by adding an unsupported option.

Ah! I see! Many thanks!

Stroller.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Alan McKinnon]

On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote:
> On Fri, 8 May 2009 14:38:58 +0100
>
> Stroller <stroller@stellar.eclipse.co.uk> wrote:
> > To find the part to which I refer you'll need to scroll down about
> > halfway through that page to "Colorize grep"; the author advises adding:
> >
> >    if echo hello|grep --color=auto l >/dev/null 2>&1; then
> >      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
> >    fi
> >
> > to ~/.bashrc
> >
> > Why does he echo hello, please?
>
> Some greps (like BSD one) might not support '--color' option, so "echo
> hello|grep --color=auto l" will return error code, skipping if clause,
> and won't break grep operation by adding an unsupported option.

except that STDERR is combined with STDOUT and sent to /dev/null so the script 
will never get it, the if is always true and the entire check is redundant. 
Better would be

if echo hello|grep --color=auto l >/dev/null ; then

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] 'if echo hello' in .bashrc

[Christian]

Hi Alan,

Am Freitag, 8. Mai 2009 schrieb Alan McKinnon:
> > Some greps (like BSD one) might not support '--color' option, so "echo
> > hello|grep --color=auto l" will return error code, skipping if clause,
> > and won't break grep operation by adding an unsupported option.

is this really right?

The result of

if echo hello|grep --Acolor=auto l >/dev/null 2>&1; then echo hallo; fi

is nothing. So the if clause is false although I pieped STDERR to /dev/null.

> except that STDERR is combined with STDOUT and sent to /dev/null so the
> script will never get it, the if is always true and the entire check is
> redundant. Better would be
>
> if echo hello|grep --color=auto l >/dev/null ; then

grep writes to STDERR if an error is occured.

The result of 

 if echo hello|grep --Acolor=auto l >/dev/null ; then echo hallo; fi

is:
grep: Unbekannte Option »--Acolor=auto«
Aufruf: grep [OPTION]... MUSTER [DATEI]...
»grep --help« gibt Ihnen mehr Informationen.


Best regard
Christian

Re: [gentoo-user] 'if echo hello' in .bashrc

[Alan McKinnon]

On Friday 08 May 2009 16:38:30 Christian wrote:
> Hi Alan,
>
> Am Freitag, 8. Mai 2009 schrieb Alan McKinnon:
> > > Some greps (like BSD one) might not support '--color' option, so "echo
> > > hello|grep --color=auto l" will return error code, skipping if clause,
> > > and won't break grep operation by adding an unsupported option.
>
> is this really right?
>
> The result of
>
> if echo hello|grep --Acolor=auto l >/dev/null 2>&1; then echo hallo; fi
>
> is nothing. 

Which is equal to ), which in shell terms is true

Yes, it's the opposite to other languages.
Yes, it really should be that way.
The return value of successful process is by convention 0, which therefore is 
evaluated as true. Non-zero is false

> So the if clause is false although I pieped STDERR to
> /dev/null.
>
> > except that STDERR is combined with STDOUT and sent to /dev/null so the
> > script will never get it, the if is always true and the entire check is
> > redundant. Better would be
> >
> > if echo hello|grep --color=auto l >/dev/null ; then
>
> grep writes to STDERR if an error is occured.
>
> The result of
>
>  if echo hello|grep --Acolor=auto l >/dev/null ; then echo hallo; fi
                        ^
What's this? I didn't type it. 

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] 'if echo hello' in .bashrc

[Alan McKinnon]

On Friday 08 May 2009 16:59:19 Etaoin Shrdlu wrote:
> On Friday 8 May 2009, 16:10, Alan McKinnon wrote:
> > On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote:
> > > On Fri, 8 May 2009 14:38:58 +0100
> > >
> > > Stroller <stroller@stellar.eclipse.co.uk> wrote:
> > > > To find the part to which I refer you'll need to scroll down about
> > > > halfway through that page to "Colorize grep"; the author advises
> > > > adding:
> > > >
> > > >    if echo hello|grep --color=auto l >/dev/null 2>&1; then
> > > >      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
> > > >    fi
> > > >
> > > > to ~/.bashrc
> > > >
> > > > Why does he echo hello, please?
> > >
> > > Some greps (like BSD one) might not support '--color' option, so
> > > "echo hello|grep --color=auto l" will return error code, skipping if
> > > clause, and won't break grep operation by adding an unsupported
> > > option.
> >
> > except that STDERR is combined with STDOUT and sent to /dev/null so
> > the script will never get it, the if is always true and the entire
> > check is redundant. Better would be
> >
> > if echo hello|grep --color=auto l >/dev/null ; then
>
> That will output an uncaptured error message if --color is not supported.

which is the desired effect. It causes the if to be false and the grep options 
are not enabled (as they are not supported)

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] 'if echo hello' in .bashrc

[Eray Aslan]

On 08.05.2009 17:10, Alan McKinnon wrote:
>>>    if echo hello|grep --color=auto l >/dev/null 2>&1; then
>>>      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
>>>    fi
>>>
>>> to ~/.bashrc
>>>
>>> Why does he echo hello, please?
>> Some greps (like BSD one) might not support '--color' option, so "echo
>> hello|grep --color=auto l" will return error code, skipping if clause,
>> and won't break grep operation by adding an unsupported option.
> 
> except that STDERR is combined with STDOUT and sent to /dev/null so the script 
> will never get it, the if is always true and the entire check is redundant. 
> Better would be
> 
> if echo hello|grep --color=auto l >/dev/null ; then

No.  We do not want any output from echo|grep.  We just want the exit
code so that the following export statement gets executed iff grep
returns with no errors.

-- 
Eray

Re: [gentoo-user] 'if echo hello' in .bashrc

[Etaoin Shrdlu]

On Friday 8 May 2009, 16:10, Alan McKinnon wrote:
> On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote:
> > On Fri, 8 May 2009 14:38:58 +0100
> >
> > Stroller <stroller@stellar.eclipse.co.uk> wrote:
> > > To find the part to which I refer you'll need to scroll down about
> > > halfway through that page to "Colorize grep"; the author advises
> > > adding:
> > >
> > >    if echo hello|grep --color=auto l >/dev/null 2>&1; then
> > >      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
> > >    fi
> > >
> > > to ~/.bashrc
> > >
> > > Why does he echo hello, please?
> >
> > Some greps (like BSD one) might not support '--color' option, so
> > "echo hello|grep --color=auto l" will return error code, skipping if
> > clause, and won't break grep operation by adding an unsupported
> > option.
>
> except that STDERR is combined with STDOUT and sent to /dev/null so
> the script will never get it, the if is always true and the entire
> check is redundant. Better would be
>
> if echo hello|grep --color=auto l >/dev/null ; then

That will output an uncaptured error message if --color is not supported.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Etaoin Shrdlu]

On Friday 8 May 2009, 16:51, Alan McKinnon wrote:

> > > except that STDERR is combined with STDOUT and sent to /dev/null
> > > so the script will never get it, the if is always true and the
> > > entire check is redundant. Better would be
> > >
> > > if echo hello|grep --color=auto l >/dev/null ; then
> >
> > That will output an uncaptured error message if --color is not
> > supported.
>
> which is the desired effect. It causes the if to be false and the grep
> options are not enabled (as they are not supported)

It's not the fact that the error message is left free to show on screen 
that makes the exit status true or false.
If the file is sourced from a non-interactive environment, you don't want 
anything printed (and probably, in this case, neither if it's an 
interactive session). Capturing stderr does not change the exit status 
of the pipeline.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Carlos Hendson]

Alan McKinnon wrote:
> On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote:
>> On Fri, 8 May 2009 14:38:58 +0100
>>
>> Stroller <stroller@stellar.eclipse.co.uk> wrote:
>>> To find the part to which I refer you'll need to scroll down about
>>> halfway through that page to "Colorize grep"; the author advises adding:
>>>
>>>    if echo hello|grep --color=auto l >/dev/null 2>&1; then
>>>      export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
>>>    fi
>>>
>>> to ~/.bashrc
>>>
>>> Why does he echo hello, please?
>> Some greps (like BSD one) might not support '--color' option, so "echo
>> hello|grep --color=auto l" will return error code, skipping if clause,
>> and won't break grep operation by adding an unsupported option.
> 
> except that STDERR is combined with STDOUT and sent to /dev/null so the script 
> will never get it, the if is always true and the entire check is redundant. 
> Better would be
> 
> if echo hello|grep --color=auto l >/dev/null ; then
> 

The redirection of output doesn't affect the return code of grep in the
above case.

Grep's return code is determined by matching 'l' against the output of
echo hello.

The desired effect of the above code is to evaluate if the --color
option is supported by grep on the system.

The STDERR and STDOUT redirection is an attempt to not pollute the
systems screen when performing that test.

To illustrate:

1. A system that supports --color

$ if echo hello|grep --color=auto l >/dev/null 2>&1; then  echo "Grep
returned : $?"; else echo "Grep returned : $?"; fi
Grep returned : 0

2. A system that doesn't support --color (simulated by supplying
--unspported as an option to grep)

$ if echo hello|grep --unsupported l >/dev/null 2>&1; then  echo "Grep
returned : $?"; else echo "Grep returned : $?"; fi
-bash: echo: write error: Broken pipe [1]
Grep returned : 2


3. Just to complete the examples, the result of grep not matching echo's
output but still supporting the --color option. (achieved by search
"hello" for the letter 'z')

$ if echo hello|grep --color z >/dev/null 2>&1; then  echo "Grep
returned : $?"; else echo "Grep returned : $?"; fi
Grep returned : 1


Regards,
Carlos

[1] The reason an error message is shown here is because it's bash
that's reporting the broken pipe error.  Grep's error message was
redirected to /dev/null, which was:

grep: unrecognized option '--unsupported'
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.

So even when the system doesn't support --color, that original code will
pollute the screen with bash's error message.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Fri, 8 May 2009 16:10:20 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On Friday 08 May 2009 16:01:14 Mike Kazantsev wrote:
>
> > Some greps (like BSD one) might not support '--color' option, so "echo
> > hello|grep --color=auto l" will return error code, skipping if clause,
> > and won't break grep operation by adding an unsupported option.
> 
> except that STDERR is combined with STDOUT and sent to /dev/null so the script 
> will never get it, the if is always true and the entire check is redundant. 
> Better would be
> 
> if echo hello|grep --color=auto l >/dev/null ; then

As many ppl just pointed out, you mistake "output check" done by "[" or
"test" commands with shell built-in "if" statement operation, which
looks only to a given command exit code, doesn't bothering with any
output.

"if [ $A ]" is equivalent to "if test $A" (where "test" is
"/usr/bin/test"), except that modern shells implement test command as a
built-in.
For the rest of them, there's actually "/usr/bin/\[" symlink, which
should exist on your system as well.
So what happens is "test $A", silently returning it's exit code to "if".

And of course, you can use any command instead of "test".
For example there's also "/bin/true" and "/bin/false", so idiomatical
"if true" and "if false" would actually work as expected ;)

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] 'if echo hello' in .bashrc

[James Rowe]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

* Carlos Hendson (skyclan@gmx.net) wrote:
> [1] The reason an error message is shown here is because it's bash
> that's reporting the broken pipe error.  Grep's error message was
> redirected to /dev/null, which was:
> 
> grep: unrecognized option '--unsupported'
> Usage: grep [OPTION]... PATTERN [FILE]...
> Try `grep --help' for more information.
> 
> So even when the system doesn't support --color, that original code will
> pollute the screen with bash's error message.

  SIGPIPE behaviour depends on the shell, how it was built and its
configuration so won't always receive an error.

  The point of this mail however is that there is still a way around it,
just call the commands within a subshell.  Compare:

  $ (echo hello | grep --colour l >/dev/null 2>&1) && echo colour support
  colour support
  $ (echo hello | grep --broken_arg l >/dev/null 2>&1) && echo broken_arg support

with the original non-subshell'd version:

  $ echo hello | grep --broken_arg l >/dev/null 2>&1 && echo broken_arg support
  -bash: echo: write error: Broken pipe

Thanks,

James


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] 'if echo hello' in .bashrc

[Stroller]

On 8 May 2009, at 14:38, Stroller wrote:
> ...
>  if echo hello|grep --color=auto l >/dev/null 2>&1; then
>    export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
>  fi

I'm afraid this thread has run away from me. I'm drinking the day's  
first cup of tea & rubbing my eyes furiously in confusion. Wha?
I'm sure I'll comprehend the discussion better when I re-read later.
However, is there actually any need to parse whether the grep supports  
colour before setting it?

Let's say we use BSD grep or Schilling grep or whatever - is there  
actually any harm in exporting GREP_OPTIONS='--color=auto' in this case?

Having written the above (so I might as well now send this message) it  
occurred to me to test it:

$ GREP_OPTIONS='--not-suported'
$ grep -i rabbit Alice\ in\ Wonderland.txt
grep: unrecognized option '--not-suported'
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
$

Presumably BSD grep & all other greps also support the GREP_OPTIONS  
environment variable?

Stroller

Re: [gentoo-user] 'if echo hello' in .bashrc

[Etaoin Shrdlu]

On Saturday 9 May 2009, 12:15, Stroller wrote:
> On 8 May 2009, at 14:38, Stroller wrote:
> > ...
> >  if echo hello|grep --color=auto l >/dev/null 2>&1; then
> >    export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
> >  fi
>
> I'm afraid this thread has run away from me. I'm drinking the day's
> first cup of tea & rubbing my eyes furiously in confusion. Wha?
> I'm sure I'll comprehend the discussion better when I re-read later.
> However, is there actually any need to parse whether the grep supports
> colour before setting it?
>
> Let's say we use BSD grep or Schilling grep or whatever - is there
> actually any harm in exporting GREP_OPTIONS='--color=auto' in this
> case?

Yes, because if the grep implementation in question supports GREP_OPTIONS 
but doesn't support --color, you'll get errors when it's run.

(The assumption the author made is that if --color is supported, then 
GREP_OPTIONS is too, which is reasonable and is what happens for GNU 
grep, although I cannot speak for other implementations).

Re: [gentoo-user] 'if echo hello' in .bashrc

[Stroller]

On 9 May 2009, at 11:41, Etaoin Shrdlu wrote:
>> ...
>> Let's say we use BSD grep or Schilling grep or whatever - is there
>> actually any harm in exporting GREP_OPTIONS='--color=auto' in this
>> case?
>
> Yes, because if the grep implementation in question supports  
> GREP_OPTIONS
> but doesn't support --color, you'll get errors when it's run.
>
> (The assumption ... is that if --color is supported, then
> GREP_OPTIONS is too, which is reasonable and is what happens for GNU
> grep, although I cannot speak for other implementations).


So this keeps the .bashrc compatible with older versions of GNU grep.  
That hadn't occurred to me.

My question is:
Do BSD & other greps also support GREP_OPTIONS ?

Stroller.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Etaoin Shrdlu]

On Saturday 9 May 2009, 12:43, Stroller wrote:

> My question is:
> Do BSD & other greps also support GREP_OPTIONS ?

A quick google search reveals that NetBSD and FreeBSD use GNU grep, while 
OpenBSD uses BSD grep, which (at least according to the man page - see 
http://tinyurl.com/cs2unf) does not support GREP_OPTIONS. It seems that 
work is underway to port the BSD grep to FreeBSD and NeetBSD.

See http://www.freebsd.org/cgi/man.cgi for a comprehensive list of manual 
pages for many popular unices. It seems that many greps do not support 
GREP_OPTIONS.

Re: [gentoo-user] 'if echo hello' in .bashrc

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

On Sat, 9 May 2009 11:15:30 +0100
Stroller <stroller@stellar.eclipse.co.uk> wrote:

> Presumably BSD grep & all other greps also support the GREP_OPTIONS  
> environment variable?

If it doesn't have support for the var then there should be no reason
to pollute environment by setting it, possibly confusing the user which
cares to look at it.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] 'if echo hello' in .bashrc

[Joerg Schilling]

Etaoin Shrdlu <shrdlu@unlimitedmail.org> wrote:

> On Saturday 9 May 2009, 12:15, Stroller wrote:
> > On 8 May 2009, at 14:38, Stroller wrote:
> > > ...
> > >  if echo hello|grep --color=auto l >/dev/null 2>&1; then
> > >    export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'
> > >  fi
> >
> > I'm afraid this thread has run away from me. I'm drinking the day's
> > first cup of tea & rubbing my eyes furiously in confusion. Wha?
> > I'm sure I'll comprehend the discussion better when I re-read later.
> > However, is there actually any need to parse whether the grep supports
> > colour before setting it?
> >
> > Let's say we use BSD grep or Schilling grep or whatever - is there
> > actually any harm in exporting GREP_OPTIONS='--color=auto' in this
> > case?
>
> Yes, because if the grep implementation in question supports GREP_OPTIONS 
> but doesn't support --color, you'll get errors when it's run.

My "grep" is called "match" and it does not look at environment variables.

There are few commands that have codumented (by POSIX) environment variables for
options. I think of e.g. "make", that needs this in order to pass options to
sub-makes.

A safe method in shell scripts is to use lower case variable names.....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily