Re: sh portability questions

[Paul Eggert]

Akim Demaille <address@hidden> writes:

> Now that there are no doubts about the portability of shell functions
> (in the sense that there's always a shell on the machine that supports
> function ---and maybe the documentation should reflect this),

Yes, it should.

> I'm curious about the support of "return" and "local".

"return" is specified in POSIX 1003.2-1992 and later, so I wouldn't
have any qualms about assuming that there is a shell on the machine
that supports it.

"local" isn't in POSIX so I'd avoid it in portable scripts.
Admittedly it is in Bash and ksh, so it's pretty portable to the
larger Unix hosts, but I'm not so sure about other environments.

For what it's worth, I briefly searched for this issue and found these
bug reports dated this year where someone used "local" in a shell
script and someone else complained and fixed it.

http://www.networksecurityarchive.org/html/Secure-Shell/2005-02/msg00067.html
http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-14/changelog

Is "local" that crucial?  Admittedly it's very annoying to lack local
variables, but you can always solve it by renaming.  (Unless you want
to use recursion.  Is that a goal here?)

Assuming you don't need recursion, here's a thought.  Use "local", but
stick to the convention that all variable names are unique.  On
systems that don't support "local", define a function named "local"
that warns if any of its arguments is a variable whose value is set;
the "local" function is otherwise a no-op.  That would catch most
errors on these hosts, where we inadvertently use a local variable
name that collides with a global one.  It's just a runtime test (and
not a complete one at that), but it'd be better than nothing.