Re: ATF confusion with improperly terminated script

[Garrett Cooper <yanegomi%gmail.com@localhost>]

On Mon, Feb 7, 2011 at 1:26 AM, Julio Merino 
<jmmv%homeworld.netbsd.org@localhost> wrote:
> On Sun, Feb 06, 2011 at 02:04:21PM -0800, Garrett Cooper wrote:
>> On Sun, Feb 6, 2011 at 1:48 PM, Julio Merino 
>> <jmmv%homeworld.netbsd.org@localhost> wrote:
>> >
>> > But all the above are wild guesses. ?Maybe your problem comes from
>> > somewhere else ;-)
>>
>>     Close, but not quite. The issue is scope [and/or whether or not
>> it's executing the functions in a subshell?], and it's something that
>> I didn't realize before now. Note that magically everything works
>> within the scope of the function, but outside of foo(), bar() and
>> baz() aren't visible. So that's why the ATF functions work in the
>> script I attached earlier, but filters out the nested functions when
>> it checks for the testcases, whereas the standalone functions executed
>> without complaint. Guess that's what I get for trying to be foolishly
>> clever.
>>     AFAICT POSIX doesn't have anything to say on the subject of
>> function scope (probably because no one thought someone would abuse
>> function nesting), but the inability to execute nested functions in my
>> clever manner appears to be consistent behavior with FreeBSD's ash and
>> bash at least, so slap on the wrist for me :). It's interesting how
>> bash barfs on the eval'ed command, but that's purely an `academic'
>> observation.
>>     So, I guess I'll use some Makefile-fu to produce the testcases instead.
>
> The scoping of the function definitions should not have any effect.
> I have in the past dynamically generated test cases and they just work.
>
> Take a look at the tests in src/tests/ipf.  For example:
>
> http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/ipf/h_common.sh?rev=1.3&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
> http://cvsweb.netbsd.org/bsdweb.cgi/src/tests/ipf/t_filter_exec.sh?rev=1.3&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>
>> PS. The end-result is the same when you change the eval below into a
>> bareword function definition, but the symptoms up to that point are a
>> wee bit different.
>>
>> $ cat ~/test_something.sh
>> #!/bin/sh
>>
>> echo "hello ${1:-world}; my pid is: $$"
>>
>> type bar baz foo
>>
>> foo() {
>>     eval "bar() { $_ $0 bar; }"
>>     baz() { $_ $0 baz; bar; }
>>     baz
>> }
>>
>> type bar baz foo
>>
>> if [ $# -eq 0 ]; then
>>     foo
>> fi
>> $ sh ~/test_something.sh
>> hello world; my pid is: 32706
>> bar: not found
>> baz: not found
>> foo: not found
>> foo is a shell function
>
> I'm not sure I understand.  This is expected, isn't it?  When the "type"
> is executed, foo has been defined but not called yet.  Therefore, the
> eval constructs have not yet been run and thus neither bar() nor baz()
> exist.

(Moving Jilles to BCC to avoid the CC spam :)..),
   My original impression was that type should provide something
sensible after foo() was executed as the functions were constructed
properly. Jilles sent me more info off-list about this that I'll
forward in the next email to close out this item from my end in
theory.
Thanks!
-Garrett