Re: Fix IRIX testsuite debugging failures: $0 in functions.

[Benoit Sigoure]

On Nov 20, 2007, at 10:51 PM, Ralf Wildenhues wrote:

> diff --git a/doc/autoconf.texi b/doc/autoconf.texi
> index 7f3428a..26410c9 100644
> --- a/doc/autoconf.texi
> +++ b/doc/autoconf.texi
> @@ -13525,6 +13516,46 @@ This variable is an alias to @samp{$?} for  
> @code{zsh} (at least 3.1.6),
>  hence read-only.  Do not use it.
>  @end table
>
> address@hidden Shell Functions
> address@hidden Shell Functions
> address@hidden Shell Functions
> +
> +Nowadays, it is difficult to find a shell that does not support
> +shell functions at all.  However, some differences in support should

"in support" sounds strange to me.  Maybe we can just drop these 2  
words.

> +be expected:
> +
> +Inside a shell function, you should not rely on the error status of a
> +subshell if the last command of that subshell was @code{exit} or
> address@hidden, as this triggers bugs in zsh 4.x; while Autoconf  
> tries to
> +find a shell that does not exhibit the bug, zsh might be the only  
> shell
> +present on the user's machine.
> +
> +Shell variables and functions may share a namespace, for example with

I'd use 'the same namespace' rather than `a namespace'.

> +Solaris 10 @command{/bin/sh}:
> +
> address@hidden
> +$ @kbd{f () @{ :; @}; f=; f}

I think there is a trailing brace here: `f}'

> +f: not found
> address@hidden example
> +
> address@hidden
> +For this reason, Autotest uses the prefix @samp{at_func_} for its
> +functions.
> +
> +Handling of positional parameters and shell options varies among  
> shells.
> +For example, Korn shells reset and restore trace output (@samp{set  
> -x})
> +and other options upon function entry and exit.  Inside a function,
> +IRIX sh sets @samp{$0} to the function name.
> +
> +Some ancient Bourne shell variants with function support did not  
> reset
> address@hidden@var{i}, @var{i} >= 0}, upon function exit, so effectively the
> +arguments of the script are lost after the first function invocation.

The sentence starts with past tense, so I suggest s/are lost/were lost/

  "Some ancient .. variants .. did not reset <whatever> .. so the  
arguments .. are lost"

> +It is probably not worth worrying about these shells any more.  More
> +explanations about this issue can be found on
> address@hidden://www.in-ulm.de/@/~mascheck/@/bourne/@/ 
> function_parameters.html,

What are these `/@/'?

> +Sven Mascheck's page} about this issue.

Hmm, I think we do better mention what's on this page so that the  
manual is self-contained (and acknowledge Sven Mascheck, maybe by  
putting the link in a footnote).  Personally, when I read a manual to  
learn about something, I prefer it to be self-contained rather than  
full of links which might not even be accessible (if you're offline,  
reading a printed copy, and so on...).  The man pages of Git are a  
real pain in this respect because they keep referring to each other  
and it's very hard to know all the arguments accepted by each command  
or the concepts they encompass.

> +
> +
>  @node Limitations of Builtins
>  @section Limitations of Shell Builtins
>  @cindex Shell builtins

Thanks for writing this section, I think it contains highly valuable  
information.

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

PGP.sig
Description: This is a digitally signed message part