Re: <OK> [Groff] serious pdfroff problems

[M Bianchi]

On Thu, Jun 16, 2005 at 08:46:01AM +0200, Werner LEMBERG wrote:
>       :
> I think that the offending line is
> 
>   MATCH="$MATCH`echo --$OPT | $GREP "^$OPTNAME"`"
> 
> I suspect that the
> 
>   "...`..."..."`"
> 
> combination causes the problem.

The  `command`  shell escape has been known to be fragile for some time.
The more robust form is  $(command).  In this case:
        MATCH="$MATCH$( echo --$OPT | $GREP "^$OPTNAME" )"

The blanks after $( and before ) are not required, but I find it helps when
reading the code.

I strongly suspect that finding all cases of  `command`  and replacing them
with  $(command)  would make the code more robust over time.

I also strongly recommend _against_ using  #!/bin/sh  as the first line of
shell scripts.  There is no shell called "sh" anymore.  It is always one of the
other shells and they are different enough that it has become unreasonable to
expect any given shell script to work with all of them.  For example, I just
discovered that  tcsh  does not understand  $(command) !  So any script that
uses the  $(command)  feature should use  #!/bin/bash  as the first line, on
the rash assumption that bash is universal.  (How likely?)

So what is the practical fall back?  Must shell scripts be written to some
(undocumented) lowest common denominator of all existing (and past and future?)
shells?  If so, then our problem line should be rewritten:
        MATCHTMP=` echo --$OPT | $GREP "^$OPTNAME" `
        MATCH="$MATCH$MATCHTMP"

I heard many years ago that "it is easier to port a shell than to port a shell
script".  This demonstrates the assertion.

--
 Mike Bianchi
 Foveal Systems

 address@hidden
 http://www.AutoAuditorium.com
 http://www.FovealMounts.com