Re: [PATCH] Enable runtime cwrapper debugging; add tests

[Charles Wilson]

Ralf Wildenhues wrote:
> That's not how these ancient shells work.
[snip long explanation]

Oh, that's just...evil.  How could that EVER have been expected to work
properly, except in the most trivial of scripts?

>> Oh yeah...ping? Is the HPUX problem a blocker for these three patches,
> 
> No.

Good!

>> or can they be considered before solving the HPUX issue?
> 
>> In any case, here's a quick-n-dirty set of test scripts to help narrow
>> down the problem.  If someone with access to HPUX can unpack and run
>> 't.sh', and report back the results, we might be able to narrow down the
>> cause of this problem. (Might need to change the shbang lines to use the
>> same shell that's causing issues with libtool).
> 
> The tests all pass with HP-UX /bin/sh and /bin/ksh.

Well, that's...good, I suppose. It means that the problem isn't
specifically in the fork/shell-func/HERE implementation, such that the
failure ALWAYS occurs.  But instead, it means that we have a race
condition or resource contention problem (where 'unique names' can be
considered a resource) -- or maybe my test case wasn't sufficiently
complex, and didn't capture the bug exposed by libtool-as-a-whole.

...
Unfortunately, I don't see a way to avoid this problem on HP/UX -- short
of requiring a less brain-dead shell.

1. every HERE document creates a temp file, whether that HERE document
   should or should not be emitted by the script.  If the script
   contains the magic <<EOF...EOF incantation even if it's inside an
   excluded block:
      if /bin/false; then
        cat >foo <<-EOF
        blah blah
        EOF
      fi
   We may not get a file named 'foo' but we WILL get a temp file, whose
   name we do not know, with the contents 'blah blah'.
2. there are only a limited number of unique temp file names
3. Sometimes these temp files don't get cleaned up. Eventually, we will
   try to reuse the temp file name of one of these non-cleaned pieces
   of litter. Boom.

We can't even pre-emptively clean up the temp files "as the first line
of the script on HP/UX" -- because we'd be "cleaning up" the ones
produced by parsing of THIS instance of the script -- some of which we
may actually need -- not to mention possibly others needed by other
in-progress instances.  What a mess.

--
Chuck