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) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 16-Jun-05 Time: 17:06:45
------------------------------ XFMail ------------------------------
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
