Re: <OK> [Groff] serious pdfroff problems

[M Bianchi]

Keith,

On Thu, Jun 16, 2005 at 02:55:24PM +0100, Keith MARSHALL wrote:
>       :
> 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.

As I read this, we are in agreement.  The ideal world (in this case the
documented standard of POSIX) makes $( ... ) the better solution.
The real world does not.
 
> > 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.
> >     :
> 
> It is probably doubtful that we can ever achieve true 100% portability
> with a shell script;

Oh, how true.  And how sad.

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

I agree with all you say, up to the idea that  #!/bin/sh  is appropriate.
Whoever writes a shell writes against one of the non-universal models because
there is no universal model.  By documenting which model is in use, we know
which man page to read when looking for bugs.  And explicitly pointing at the
_matching_ model prevents bugs from being expressed.  Assuming that which ever
shell happens to be /bin/sh in the current environment is going to work strikes
me as too risky once you get beyond sequential command executions.

I never looked before, but these are the shells on my Linux.  I live in pdksh.

                /bin/ash*
                /bin/bash*
                /bin/bsh -> ash*
                /bin/csh -> tcsh*
                /bin/ksh -> pdksh
                /bin/pdksh*
                /bin/sh -> bash*
                /bin/tcsh*
                /bin/zsh*

The good news in all of this is that the open/free software world lets us have
discussions like this.

--
 Mike Bianchi