Re: [bash] Verify substring in shell var

From: Hyo Joon You (hyojoonus_at_xxxNOSPAMxxxyahoo.com)
Date: 04/30/03 

Date: Tue, 29 Apr 2003 22:24:50 -0700

pt wrote:
> I'm trying to verify that a shell variable (PATH) contains a directory
> and, if not, add it to PATH. I've seen:
>
> if ! echo $PATH | /bin/grep -q "/fred" ; then
> PATH=$PATH:/fred
> fi
>
> but it occurs to me I might be able to do something like this:
>
> if [[ $PATH != */fred* ]]; then
> PATH=$PATH:/fred
> fi
>
> Is there any argument for either method (or any six other ways to do
> the same thing)? Any reason to do it entirely "within" the shell vs.
> via external executables (like "grep")?

Dear pt:

Intuitively, the reason why a shell such as bash would have such builtin
  function for comparing string would be because the creator of bash
felt that the benefits of having the function outweighs the additional
cost of having to link the function into the shell.

Pros:
1. It is faster to use a builtin function than to use two processes to
accomplish the same objective.

Cons:
1. This is at the cost of bash being marginally larger. Hence, the
initialization of bash is slower had it not been there. My case in
point, bash is a beast of a shell.
2. Obviously, using a builtin that is specific to one shell will create
compatibility problems.

I can provide you with following advice. Bash has a nice set of
functionalities that makes it easy to use, such as the function above.
But, unless such functionality solves a much larger problem, it is best
to avoid compatibility problems. For instance, the grep matching gets
around the builtin equivalent without significance in complexity of the
code. Therefore, I would prefer the grep matching to the builtin
equivalent. Yes, grep matching would be slower, but the idea behind
shell is flexibility and less to do with speed. One has C (or
languages) for that.

Hope this helps,

hjy

Relevant Pages