🚀 go-pugleaf

In article <1990Sep13.163836.19937@cs.umn.edu> rantapaa@cs.umn.edu (Erik E. Rantapaa) writes:
: For maximum portability, should I just avoid using functions
: altogether? :(

In a word, yes.  I have never written a shell function.  Not because I
wouldn't have liked to upon occasion.  But some of us live in multi-vendor
environments, where portability is a way of life.  Configure scripts can't
afford to use shell functions either.  That's life.

Larry

In article <1990Sep13.163836.19937@cs.umn.edu> rantapaa@cs.umn.edu (Erik E. Rantapaa) writes:
>In experimenting on various systems, I have found the following
>differences in the way /bin/sh handles functions:
>
>   * Some give functions their own private argument list.

Systems with /bin/sh based on the AT&T s5r3 /bin/sh.  This version of
the shell preserves the dollar variables around a series of function
calls.  The s5r3.2 /bin/sh also allows recursive functions.

Such systems include SunOS 4.0, SunOS 4.1, and systems derived from
s5r3.

Bash and ksh also give functions private argument lists.

>   * Some have arguments passed to functions overwrite the script's
>     argument list.

Systems with /bin/sh based on AT&T s5r2 /bin/sh.  Ultrix /bin/sh5,
SunOS 3.x /bin/sh, the BRL Bourne Shell, HP-UX 6.x and 7.x /bin/sh
among others.

>   * Some don't support functions at all.

Systems with /bin/sh based on the version 7 sh.  4.3 BSD, most
systems derived therefrom, Ultrix /bin/sh.

>If /bin/sh supports functions, which behavior is more common?

The practice of giving functions their own private argument lists,
and correctly saving and restoring the dollar variables around
function invocations is clearly the wave of the future.

>Also, does the fact that some Bourne shells don't support functions
>mean that I shouldn't use functions in scripts which I send out for
>general use?

Well, 4.3 BSD is really the only system left using the v7 sh.  4.4 BSD
will ship with a shell that supports functions (whether or not that
shell is bash is something to be decided later).  I belive that 4.3-reno
already does, but I do not have 4.3-reno.  Nevertheless, at least for the
time being, I would not ship scripts with functions for general use.

>Are replacements such as bash and ksh widely enough
>available so people can use them if they have a defective /bin/sh?

Bash is freely available, but version 1.05 (the currently distributed
version) has a number of bugs.  I have fixed all that I am aware of,
so 1.06 should be fairly stable when distributed.

ksh costs money.  This alone restricts its availability somewhat, but it
is quite widespread.

>Finally, what is the POSIX standard with regard to this?

The Posix standard mandates the `private argument list' behavior.

Chet
-- 
Chet Ramey				``Levi Stubbs' tears run down
Network Services Group			  his face...''
Case Western Reserve University	
chet@ins.CWRU.Edu		

In article <1990Sep13.221943.15220@usenet.ins.cwru.edu> chet@po.CWRU.Edu writes:
>In article <1990Sep13.163836.19937@cs.umn.edu> rantapaa@cs.umn.edu (Erik E. Rantapaa) writes:
>>In experimenting on various systems, I have found the following
>>differences in the way /bin/sh handles functions:
>>
>>   * Some give functions their own private argument list.
>
>Systems with /bin/sh based on the AT&T s5r3 /bin/sh.  This version of
>the shell preserves the dollar variables around a series of function
>calls.  The s5r3.2 /bin/sh also allows recursive functions.

I don't think this is precisely correct.  Perhaps you meant that only 
the *positional* parameters are preserved around a function call.  The
*local* variables aren't preserved.

What does the following script do on your system:

	#!/bin/sh
	set -- yes
	lvar="yes"
	foobar() { lvar=$1; }
	foobar no
	echo positional variable $1, local varibale $lvar


My s5r3.2 based Bourne shell says positional yes, local no.  If your 
shell doesn't preserve local variables then it's difficult to implement
real recursive functions (i.e. a function that invokes itself).


-- 
bruce@segue.com
ism.isc.com!segue!bruce
aero.org!segue!bruce

In article <3693@segue.segue.com> bruce@segue.segue.com (Bruce Adler) writes:
>
>I don't think this is precisely correct.  Perhaps you meant that only 
>real recursive functions (i.e. a function that invokes itself).
>
Local variables being preserved (and lost) would also defeat the
main purpose of functions and deny them any mechanism to
return more than one result value.









Bruce Balden
balden@wimsey.bc.ca
:

In article <3693@segue.segue.com> bruce@segue.segue.com (Bruce Adler) writes:

I wrote:
$ >Systems with /bin/sh based on the AT&T s5r3 /bin/sh.  This version of
$ >the shell preserves the dollar variables around a series of function
$ >calls.  The s5r3.2 /bin/sh also allows recursive functions.

$ I don't think this is precisely correct.  Perhaps you meant that only 
$ the *positional* parameters are preserved around a function call.  The
$ *local* variables aren't preserved.

Yes, I meant the positional parameters.  AT&T Bourne shells do not have local
variables.  All variables are global.

$ What does the following script do on your system:
$ 
$ 	#!/bin/sh
$ 	set -- yes
$ 	lvar="yes"
$ 	foobar() { lvar=$1; }
$ 	foobar no
$ 	echo positional variable $1, local varibale $lvar

The /bin/sh running on my system is bash.  Running your script unmodified
says positional yes, local no.  Changing the script so that `lvar' is a
real local variable (making the script read `local lvar=$1'), says
positional yes, local yes.

$ My s5r3.2 based Bourne shell says positional yes, local no.  If your 
$ shell doesn't preserve local variables then it's difficult to implement
$ real recursive functions (i.e. a function that invokes itself).

True, but the s5r3.2 sh does not prohibit them:

zen$ sh53 				<----- s5r3.2 sh
zen$ f()
> {
> if [ $1 -eq 0 ] ; then
>         return
> else
>       echo $1
>       f `expr $1 - 1`
> fi
> }
zen$ f 5
5
4
3
2
1

It just limits their usefulness.

Chet
-- 
Chet Ramey				``Levi Stubbs' tears run down
Network Services Group			  his face...''
Case Western Reserve University	
chet@ins.CWRU.Edu