>>> "Paul" == Paul Eggert <eggert@xxxxxxxxxxx> writes: > "local" isn't in POSIX so I'd avoid it in portable scripts. Doh. Thanks. > 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 Thanks, I should have done this myself... > 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?) No, recursion is not an issue, but it was to avoid having to stick to ugly naming convention to avoid clashes. > Assuming you don't need recursion, here's a thought. Nice trick! Thanks for the suggestion. Unfortunately, although I don't have recursion, I do call my function multiple times. Of course I could start using 'unset', which is unportable but easy to work around, but that starts to become quite a mess. I can actually define "local" to do nothing and use an external maintainer-check to grep'n check them. Also, maybe I am paranoid, but would you trust shells to support conditional function definitions? Or function definitions in eval? if (local foo) >/dev/null 2>&1; then :; else local () { true; } fi or even (local foo) >/dev/null 2>&1 || local () { true; } Bah. First trust, then react. Thanks! _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
