rantapaa@cs.umn.edu (Erik E. Rantapaa) (09/13/90)
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.
* Some have arguments passed to functions overwrite the script's
argument list.
* Some don't support functions at all.
I have some questions that maybe the net could help with:
If /bin/sh supports functions, which behavior is more common?
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? Are replacements such as bash and ksh widely enough
available so people can use them if they have a defective /bin/sh?
For maximum portability, should I just avoid using functions
altogether? :(
Finally, what is the POSIX standard with regard to this?
--
Erik Rantapaa
rantapaa@cs.umn.edulwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (09/14/90)
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.
Larrychet@cwns1.CWRU.EDU (Chet Ramey) (09/14/90)
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
bruce@segue.segue.com (Bruce Adler) (09/15/90)
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
balden@van-bc.wimsey.bc.ca (Bruce Balden) (09/16/90)
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 :
chet@cwns1.CWRU.EDU (Chet Ramey) (09/17/90)
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