groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: <OK> [Groff] serious pdfroff problems


From: Keith MARSHALL
Subject: Re: <OK> [Groff] serious pdfroff problems
Date: Thu, 16 Jun 2005 14:55:24 +0100

Mike Bianchi wrote:
> 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 beg to differ here.  While POSIX defines the $( ... ) syntax for
embedded command invocation, we have to deal with many legacy systems
which are not POSIX compliant.  As you say, Mike, the syntax used in
pdfroff does have portability problems; as I have already indicated to
Werner privately, the correct portable syntax is

  MATCH="$MATCH"`echo --$OPT | $GREP "^$OPTNAME"`

or, possibly, the two line form you indicate below.

> 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.

It is probably doubtful that we can ever achieve true 100% portability
with a shell script; this is why I will probably eventually produce a
C/C++ implementation of pdfroff.  Until I find time to do so, I will
endeavour to make the script version as portable as possible.  This
means adhering to basic Bourne shell syntax, avoiding constructs which
are known to be problematic.  Any POSIX conforming system *should* have
a shell called /bin/sh -- it may be a link to some more advanced shell,
but it is still supposed to be present, and it should be capable of
interpreting standard Bourne shell syntax.  Therefore, IMO it is
entirely appropriate that scripts *should* have the #! /bin/sh shebang.
Bash, tcsh, ksh, zsh, etc. are by no means universal -- /bin/sh *should*
be, and has the best chance of providing a portable script execution
environment, provided appropriate portability guidlines are followed.

Best regards,
Keith.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]