Re: <OK> [Groff] serious pdfroff problems

[Ted Harding]

On 16-Jun-05 Keith MARSHALL wrote:
> Mike Bianchi wrote:
>> [...]
>> 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.

Be watchful here! When one "command" is a link to another, as for
instance

   /bin/sh -> /bin/bash

although the same binary file (/bin/bash) is executed whether one
calls /bin/bash or /bin/sh, nevertheless the program *knows* what
the call was, and may therefore behave differently in the two
cases. Indeed, this seems to be the case for /bin/bash: see the
following extract from the output of "man bash" in Linux:

       If  bash  is  invoked  with  the name sh, it tries
       to mimic the startup behavior of historical versions
       of sh as  closely  as  possible, while conforming  to
       the POSIX standard as well. When invoked as an interac-
       tive login shell, or a non-interactive shell with the
       --login option, it  first  attempts  to read and execute
       commands from /etc/profile and ~/.profile, in that order. 
       The  --noprofile  option  may  be used  to inhibit this 
       behavior.  When invoked as an interactive shell with the
       name sh, bash looks for the variable ENV, expands its
       value if it is defined, and uses the expanded value as
       the name of a file to read and execute. Since a shell
       invoked as sh does not attempt to read and execute 
       commands from any other startup files, the --rcfile
       option has no effect. A non-interactive shell invoked
       with the  name sh does not attempt to read any other 
       startup files.  When invoked as sh, bash enters posix
       mode after the startup files are read.

While what is described here as differences between bash invoked
as "bash" and bash invoked as "sh" may possibly be harmless in
our context, nevertheless it is clear that the two kinds of
invocation cause /bin/bash to behave differently.

I'm no expert on the details of differences between /bin/bash
and /bin/sh -> /bin/bash, still less on differences between
bin/someshell and bin/sh -> /bin/someshell, but I think that
the possible differences of behaviour need to be borne in mind.

Best wishes to all,
Ted.




--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Jun-05                                       Time: 17:06:45
------------------------------ XFMail ------------------------------