Platform-independent shell scripts?

Platform-independent shell scripts?

Post by Michael Slad » Wed, 17 Nov 1999 04:00:00



I've been looking for a web page or similar on how to write a bourne
shell script that will work with any bourne shell.  No luck so far.

Does such a page exist?

Where in the FAQ is it mentioned? :)

Mick.

 
 
 

Platform-independent shell scripts?

Post by Donn Cav » Wed, 17 Nov 1999 04:00:00



| I've been looking for a web page or similar on how to write a bourne
| shell script that will work with any bourne shell.  No luck so far.
|
| Does such a page exist?
|
| Where in the FAQ is it mentioned? :)

We don't like to talk about this.

It's easy to say what will work with most current UNIX platforms.
(I assume that you mean /bin/sh on any UNIX platform, and other
shells that may be available are not an issue - /bin/sh5,
/usr/local/bin/bash, etc.)

But when you raise the bar to _any_ shell the question actually
becomes less well defined, because the answer may vary wildly
depending on where we draw the line on the outer fringes of the
realistic possibilities.  UNIX has been around a long time.
And the question is compounded by variations in the tools we
use in shell scripts, other than the shell itself.

I have mixed feelings about where the draw the line myself.  The
big question for me is whether the last versions of Ultrix and other
platforms of that vintage can be ignored.  They're still in service,
no question about that, but often in legacy roles that may be
irrelevant for new software and their standard /bin/sh is awkwardly
different from the modern platforms.  If you wanted to go even
farther than this and dig up even more antique systems, I think we
really wouldn't like to talk about that.

One notable success here are the "configure" scripts produced by the
GNU autoconf system.  They may not cover all the things you may need
to do, and they're not directly hand written so can be a little hard
to read in places, but they're a nontrivial shell application that
works "everywhere".  Many examples, e.g., Python 1.5.2 source distribution.

        Donn Cave, University Computing Services, University of Washington


 
 
 

Platform-independent shell scripts?

Post by Paul D. Smi » Wed, 17 Nov 1999 04:00:00




  >> at the "Configure" script that comes with perl.

  bh> This configure script in question is generated automatically by
  bh> the GNU autoconf system, worthy in itself a check for its analysis
  bh> of portable shell considerations.

Actually, not.  Perl's "Configure" isn't generated by autoconf.  Those
are "configure" scripts.  I think Perl's "Configure" was created,
originally, by metaconfig (?)  Confusing, eh? :)

The Perl folk all swear by Configure, but I personally much prefer
autoconf configure scripts.  I guess it's all what you're used to...

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

 
 
 

Platform-independent shell scripts?

Post by ScriptOmati » Thu, 18 Nov 1999 04:00:00





> | I've been looking for a web page or similar on how to write a bourne
> | shell script that will work with any bourne shell.  No luck so far.
> |
> | Does such a page exist?
> |
> | Where in the FAQ is it mentioned? :)

> We don't like to talk about this.

> It's easy to say what will work with most current UNIX platforms.
> (I assume that you mean /bin/sh on any UNIX platform, and other
> shells that may be available are not an issue - /bin/sh5,
> /usr/local/bin/bash, etc.)

> But when you raise the bar to _any_ shell the question actually
> becomes less well defined, because the answer may vary wildly
> depending on where we draw the line on the outer fringes of the
> realistic possibilities.  UNIX has been around a long time.
> And the question is compounded by variations in the tools we
> use in shell scripts, other than the shell itself.

> I have mixed feelings about where the draw the line myself.  The
> big question for me is whether the last versions of Ultrix and other
> platforms of that vintage can be ignored.  They're still in service,
> no question about that, but often in legacy roles that may be
> irrelevant for new software and their standard /bin/sh is awkwardly
> different from the modern platforms.  If you wanted to go even
> farther than this and dig up even more antique systems, I think we
> really wouldn't like to talk about that.

> One notable success here are the "configure" scripts produced by the
> GNU autoconf system.  They may not cover all the things you may need
> to do, and they're not directly hand written so can be a little hard
> to read in places, but they're a nontrivial shell application that
> works "everywhere".  Many examples, e.g., Python 1.5.2 source
distribution.

>    Donn Cave, University Computing Services, University of Washington


Michael,
I agree with Donn.  However, that being acknowledged, I have extensive
shell experience and I'm allowed to help anyone with any shell problem
on company time!  I get to do this because it is hoped that are company
can become known as "the" place for good stuff on korn/bourne and some
c-shell.
So ... if you have specific problems you want solved I give it a crack.
I once had to maintain 10,000 lines of installation scripts for every
god blessed version of UNIX - t'was 1988 time frame.  If you have a
Q' send it my way and I'll be glad to add my 2cents worth.

--
Help for UNIX admins!  Free shell archive at
http://www.opensysmon.com/support
While you're at it, why not give OpenSysMon a try?
Low cost, high quality, monitor systems, shells and cron.

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

Platform-independent shell scripts?

Post by brian hile » Thu, 18 Nov 1999 04:00:00


Dave Brown <dagbr...@home.com> wrote:
> In article <3831053E.49162...@multinet.com.au>,
> Michael Slade  <michael.sl...@multinet.com.au> wrote:
> > I've been looking for a web page or similar on how to write a bourne
> > shell script that will work with any bourne shell.  No luck so far.
> > Does such a page exist?
> Actually, you can learn an awful lot about portability by looking
> at the "Configure" script that comes with perl.

This configure script in question is generated automatically by
the GNU autoconf system, worthy in itself a check for its analysis
of portable shell considerations.

http://www.isys.net/susehilf/gnu/autoconf/Portable_Shell.html

I will not add too much to Mr. Cave's fine examination of the real
issues of shell portability issues, except to say:

(1) More and more, it behooves one to understand that bourne shell
was never the really portable shell, ksh is. It's documented,
stable, comes from one development lineage, and is currently being
maintained as well as having the latest version available for
download (well, for "non-commercial use".)

(2) If you are not dissuaded by the above, there is a book written
_specifically_ concerning shell portability:

http://www.amazon.com/exec/obidos/ASIN/0134514947/qid%3D942801172/002...
ftp://ftp.prenhall.com/pub/ptr/hewlett_packard_professional_books.w-0...

(3) And, for the asking, I send you my script "whichshell", which
determines shell (bourn-ish and cshell-ish) and version.

# whichshell 2>&- || SHTYPE=SH_1977 : do NOT eliminate this first comment line!
#*TAG:48056 5:Nov 21 1998:0755:whichshell:
# Author: Brian Hiles <b...@iname.com>
# Copyright: (c) 1997-1998
# Description: determine which shell this script runs under
# Inspired-by: hei...@darwin.noris.de (Heiner Steven)
# Name: whichshell
# Sccs: @(#)whichshell.sh 1.2 1998/05 b...@iname.com (Brian Hiles)
# Usage: whichshell [script [script-parameter]...]
# Version: 1.02

#XXX consider allowing "init.KSH" instead of "init.KSH_19??"
#XXX SH_OLD -> SH_1977, etc.
#XXX SH_POSIX -> SH_199?
#XXX thoroughly document differences between early bourne shells in _man-page_

#01 COMMON CORE CODE
unset a || SHTYPE=SH_OLD                # ignore potential error message
set a = "$*"
test "$a" = "$*" && goto CSH

#02 BOURNE FAMILY
PATH= export PATH
case $3 in
'')     shcmd='echo ' ;;
*)      set -- $3
        shcmd=". ${1?}."              # bash bug: "var=value shift" not poss!
        shift ;;
esac
# From: werner.bu...@ubs.com (Werner Burri)
# zsh 2.5.x/3.0.x error: "whichshell: read-only variable: LINENO [60]"
IFS=' ' LINENO= RANDOM= a=$[1] retval=0
a=2 a=$[3] wait 2>/dev/null
case $a:$LINENO:$RANDOM in
1*)     # use BASH_VERSION?
        if (: ${!a}) 2>/dev/null
        then    SHTYPE=BASH_2           # bash 2.00 (IRIX 5.x)
        else    SHTYPE=BASH_1           # bash 1.14.7(2) (IRIX 5.x)
                # From: werner.bu...@ubs.com (Werner Burri)
                [ "${ZSH_VERSION:-${VERSION#zsh }}" > 2.5 ] &&
                SHTYPE=ZSH_${ZSH_VERSION:-${VERSION#zsh }}
        fi ;;
'$[3]::'*)
        SHTYPE=KSH_1986 ;;              # ksh 6/3/86
$\[[13]]:1:[0-9]*)
        # some ksh88s are modified to apparently conform to POSIX 1003.2
        if (: ${.sh.version}) 2>/dev/null
        then    SHTYPE=KSH_1993         # ksh M-12/28/93e (SunOS 4.x, IRIX 5.x)
        else    SHTYPE=KSH_1988         # ksh 11/16/88f (AIX 4.x, OSF/1 3.x)
                #SHTYPE=KSH_1988POSIX   # ksh 11/16/88f (AIX 4.x, OSF/1 3.x)
        fi ;;
'$[3]::')
        SHTYPE=SH_1994 ;;               # sh SVR4 (UnixWare)
2::)    case $SHTYPE in
        SH_OLD) ;;
        *)      if (_(){ :;}) 2>/dev/null
                then    SHTYPE=SH_1983  # sh SVR3 Unix
                else    SHTYPE=SH_1977  # sh SVR2 Unix
                fi ;;
        esac ;;
#3*)    SHTYPE=ZSH_ ;;                  # zsh 2.3.1 (IRIX 5.x)
*)      retval=1 SHTYPE=`
                IFS=/
                set -- ${SHELL:-UNKNOWN}
                until test \$# -eq 1
                do      shift
                done
                echo "\$1"
        ` ;;
esac
eval $shcmd$SHTYPE
exit $retval

#03 CSHELL FAMILY
CSH:
unset path
if ("X$a" == X) then
        set shcmd = 'echo '
else
        set argv = ($a) shcmd = "source $1."
        shift
endif
set a = /b/c.d.e retval = 0
switch ($a:t:r:e)
case c.d.e:r:e:                         # csh (SunOS 4.x)
case c:d:e:r:e:                         # csh (IRIX 5.x)
        set SHTYPE = CSH
        breaksw
case d:                                 # tcsh 1.2 1993/07/15 (IRIX 5.x)
        set SHTYPE = TCSH
        breaksw
default:
        if ! ($?shell) set shell = UNKNOWN retval = 1
        if ("X$shell" == X) set shell = UNKNOWN retval = 1
        set SHTYPE = $shell:t
        breaksw
endsw
eval $shcmd$SHTYPE
exit $retval
--

#04 EMBEDDED MANPAGE FOR "src2man"
#++
NAME
        whichshell - determine which shell this script runs under

SYNOPSIS
        whichshell [script [script-parameter(s)]]

DESCRIPTION
        With no arguments, the determined value of <shell> is printed
        to stdout. If this cannot be determined, $SHELL is assumed if
        set and non-null, otherwise string "UNKNOWN".

        With <script> argument and optional <parameter(s)>, the script
        <script>.<shell> is sourced with its positional parameters set
        to <parameter(s)>.

        Whichshell knows about bash 1.x/2.x, csh, ksh86/88/93, V7/SVR2 sh,
        SVR3 sh, POSIX sh, tcsh, #XXXand zsh.

EXAMPLE
        csh -f whichshell init p1 p2 p3
        sh -f whichshell init p1 p2 p3
        ksh -f whichshell init p1 p2 p3

        It is assumed that files "init.{CSH,KSH_1988,SH}" exist having
        valid csh, ksh[88], and sh code, respectively. Or another
        technique may be to create links "init.KSH_1988" and "init.KSH_1993"
        that point to "init.SH", and a link "init.TCSH" to "init.CSH".

RETURN VALUE
        For the case of no arguments:
                0 if the shell is able to be determined, else 1.
        else,
                if the sourced file does not exist: 1, else the same
                as above (barring an explicit "exit" command therein.)

CAVEATS
        This script cannot be sourced; it must be executed within a
        subshell.

        Bash 1.x will attempt to source an $ENV script meant for ksh or
        other shells.

        Different sources document the release year of the various shells
        distributed with the canonical releases of Unix; however, whichshell
        only stipulates that such numbers be formally increasing for each
        major family of shell.

        To be truly robust for very ancient sh's: eliminate all comments
        but the first.

        Until weirdnik zsh can decide on how to act whether interactive
        or not, whichshell cannot be expected to either.

BUGS
        Positional parameter(s) cannot have embedded whitespace or
        special characters.

#--

-Brian

 
 
 

Platform-independent shell scripts?

Post by Donn Cav » Thu, 18 Nov 1999 04:00:00






| > > I've been looking for a web page or similar on how to write a bourne
| > > shell script that will work with any bourne shell.  No luck so far.
| > > Does such a page exist?
| > Actually, you can learn an awful lot about portability by looking
| > at the "Configure" script that comes with perl.
|
| This configure script in question is generated automatically by
| the GNU autoconf system, worthy in itself a check for its analysis
| of portable shell considerations.
|
| http://www.veryComputer.com/

A postscript to Paul Smith's followup - Larry Wall's Configure scripts
date to long before Perl and were the first example I remember of any such
thing.  So they're likely to preserve some knowledge of shell antiquities
that you'd never find elsewhere.  I think the autoconf stuff started with
David MacKenzie's GNU shell-utils/file-utils suites, masterful work that
wouldn't have been practical without some kind of automated configuration
utility.

| (1) More and more, it behooves one to understand that bourne shell
| was never the really portable shell, ksh is. It's documented,
| stable, comes from one development lineage, and is currently being
| maintained as well as having the latest version available for
| download (well, for "non-commercial use".)

And there's the rub.  Because of its restricted availability as a
commercial, proprietary product, you will find "ksh" isn't always
present, and when present isn't always the real thing.  If the notion
that it's a standard becomes more prevalent, over time there will be
less of the former - NetBSD et al. will come with "ksh" so scripts
that need it won't fail outright - but that just means more of the
latter, where "ksh" means pdksh or something in that vein.  NetBSD
can't just distribute ksh93 for free, right?  Or Debian or what have
you.  Be could have used it instead of bash, in BeOS, but what's the
incentive - why pay to use a proprietary, closed source shell when
there's a really excellent open source alternative that's already the
standard shell on Linux?

I don't think open source is any kind of m*imperative, but it
seems to be a particularly effective solution in this area, I mean
programming languages.  It isn't enough by itself, and it may take
some special talents to make it work well, but in recent years bash
has been a great example.  Maybe ksh could be another.  I don't think
ksh is likely to displace bash as the standard shell on Linux, BeOS
et al., but I gather that's not the point - if we're looking to
ksh as a standard instead of sh, all we really need is to reliably
find the real ksh under that name.  If the up to date source were
reliably available to anyone who wanted it, things would certainly
move much faster in that direction.

        Donn Cave, University Computing Services, University of Washington

 
 
 

Platform-independent shell scripts?

Post by Peter Seeba » Thu, 18 Nov 1999 04:00:00




>No, it isn't.  Larry Wall's Configure script is far more
>wide-ranging than the 'configure' script generated by autoconf.

My only complaint is that they insist on calling any stdio library whose
internals they can't figure out how to muck with "not very std".

The standard says you can't touch the internals.  Hmph.

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!

 
 
 

Platform-independent shell scripts?

Post by brian hile » Fri, 19 Nov 1999 04:00:00






> > ...
> > currently being maintained as well as having the latest version
> > available for download (well, for "non-commercial use".)
> Unless you use Linux.  But, that's only a fringe operating system,
> right?

_Especially_ if you use Linux. Ksh93 is native ported to that
platform, available right there in the download pages linked through
kornshell.com.

I do my code development on a multi-boot system of Win98 and SuSE
Linux, and one Voyager SparcStation5.

-Brian

 
 
 

Platform-independent shell scripts?

Post by Peter Seeba » Fri, 19 Nov 1999 04:00:00




Quote:>_Especially_ if you use Linux. Ksh93 is native ported to that
>platform, available right there in the download pages linked through
>kornshell.com.

For what processors?

I'm ignoring ksh93, and using PDKSH by preference.  This will change the
moment I can do anything I want with ksh93 and I have source.  In the mean
time, I can rely on pdksh, because I can try to fix a behavior I don't like,
and I have some confidence that, if I switch hardware platforms, I'll still
be able to use it.

Do I have a promise that ksh93 will run on NetBSD/alpha?  Will it still run
if they convert to ELF?  Will it be 64-bit clean on that platform?  With
pdksh, I get answers to these questions, and I like them.  ;)

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!

 
 
 

Platform-independent shell scripts?

Post by Christopher J. Matter » Fri, 19 Nov 1999 04:00:00





> : (1) More and more, it behooves one to understand that bourne
> : shell was never the really portable shell, ksh is. It's
> : documented, stable, comes from one development lineage, and is
> : currently being maintained as well as having the latest version
> : available for download (well, for "non-commercial use".)
> Unless you use Linux.  But, that's only a fringe operating system,
> right?

You can use ksh on Linux.  You can go and get your free (for non-
commercial use) ksh for Linux at www.kornshell.com right now.  
It's just that since it's incompatible with the GNU license, it
can't be distributed with Linux.

                   Chris Mattern

 
 
 

Platform-independent shell scripts?

Post by Paul D. Smi » Fri, 19 Nov 1999 04:00:00






  >> : (1) More and more, it behooves one to understand that bourne
  >> : shell was never the really portable shell, ksh is. It's
  >> : documented, stable, comes from one development lineage, and is
  >> : currently being maintained as well as having the latest version
  >> : available for download (well, for "non-commercial use".)

  >> Unless you use Linux.  But, that's only a fringe operating system,
  >> right?

  cjm> You can use ksh on Linux.  You can go and get your free (for non-
  cjm> commercial use) ksh for Linux at www.kornshell.com right now.  

Well, I use Linux commercially.

  cjm> It's just that since it's incompatible with the GNU license, it
  cjm> can't be distributed with Linux.

Wrong.  Hundreds of programs with licenses incompatible with the GNU
license are distributed on Linux distributions.

The reason it can't be distributed is because selling a disk with the
binary on it would be... wait for it... commercial use!  And really, who
would bother to pay money for something as basic and well-understood as
a shell.  It's like paying extra to get "cat" on your system.  Ptooey.

Forget it.  Bash and zsh are both better anyway.

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

 
 
 

Platform-independent shell scripts?

Post by Dan Merc » Sat, 20 Nov 1999 04:00:00





DELETIA

> Forget it.  Bash and zsh are both better anyway.

zsh maybe.  But bash:

echo if only bash could do this|read then you would not be far from right

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

 
 
 

Platform-independent shell scripts?

Post by Paul D. Smi » Sat, 20 Nov 1999 04:00:00





  >> Forget it.  Bash and zsh are both better anyway.

  dm> zsh maybe.  But bash:

  dm> echo if only bash could do this|read then you would not be far from right

Does POSIX.2 require that the last command in a pipeline be executed in
the current shell?  I don't think it does.

If it does, then indeed you're right; this is a bug.

If it doesn't, then big deal; there are non-standard enhancements that
bash has that ksh doesn't, too.

--
-------------------------------------------------------------------------------

 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.

 
 
 

Platform-independent shell scripts?

Post by Dan Merc » Sat, 20 Nov 1999 04:00:00







>  >> Forget it.  Bash and zsh are both better anyway.

>   dm> zsh maybe.  But bash:

>   dm> echo if only bash could do this|read then you would not be far from right

> Does POSIX.2 require that the last command in a pipeline be executed in
> the current shell?  I don't think it does.

> If it does, then indeed you're right; this is a bug.

> If it doesn't, then big deal; there are non-standard enhancements that
> bash has that ksh doesn't, too.

The statement was bash was better than ksh88 (ksh93 is clearly
superior to everything but perl).  The ability of ksh88 to
execute the last command of a pipeline in the current shell
is a major advantage of ksh88 over bash.  So are the typeset
options, co-processes and speed of execution.  Bash has better
string handling, superior UI, better arithmetic expressions.
I would give bash a slight edge as a user environment, ksh88 a
major edge for scripting.

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

 
 
 

Platform-independent shell scripts?

Post by Dan Merc » Mon, 22 Nov 1999 04:00:00





>: I would give bash a slight edge as a user environment, ksh88 a
>: major edge for scripting.

> I would say use straight-up sh.  If you need something more
> powerful than straight-up sh, use perl, or wrote a C program.

There's no such a thing as straight up shell.  The program called
"sh" may actually be many different programs - A SysV Bourne sh,
the BSD port of a slightly older Bourne sh,  a "posix" sh which
will mean different things to different vendors,  ksh88,  ksh93,
or bash. You can write "portable" scripts that will run
identically on all versions,  but it is extremely trick.  Because
you must severely limit the scope of operations you can actually
do in the shell for portability's sake,  you must rely heavily on
using external programs.  That,  of course, requires the programs
you call to have some consistency across platforms,  which many
do not.  Even simple "cat" has a wide range of different options
on different architectures.  If you are distributing software
across many architectures,  it may be easier to just include a good
free shell (I would suggest you look at rc) as part of the package.

As for perl,  there are far too many perl4 installations out there
for that to be practical (or systems with no perl at all).

Quote:> But, hey, that's just me.

> --Dave

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

 
 
 

1. How do I make my shell script platform independent?

Hi!

I read the FAQ, but didn't get an answer to this.

I've written a wish script that needs to run on two different platforms.  Right now,
I have two different versions of the script.  The only difference is the first
line of each script however:

        platform 1: #!/platform1/path/to/wish -f
        platform 2: #!/platform2/path/to/wish -f

How do I make the path to wish conditional based on the platform?

Thanks!

--Les

2. Beyond 8 Slices

3. Best windows (platform-independent) Debugger?

4. Problem with GDM and Eterm (correct !)

5. make AT_SYSINFO platform-independent

6. Multiple IP addr on one Interface

7. Platform-independent MAKE

8. Problems with user web directory access with Apache !?!?!?

9. ANNOUNCE: Spectrum Software Launches First Truly Integrated, Platform-Independent SCM System In Europe

10. shell independent script

11. platform independent installation tools

12. No fast platform independent interfaces?

13. Are IEEE floats platform independent?