Not sure I can go with that analysis.
To put it politely I don't think you've looked at the code and output in
enough detail.
Ignore the first 'trace' line - it just happens to be there.
The substantive issue - LINENO going backwards - occurs across four source
lines, two of which are blank, and in which the only 'active ingredient' is
a 'fi'
So unless the function calls are managing some 'delayed action' I can't
see how they can be involved.
I suspect that if I work hard I can get the example down to one empty line,
but I'll need to put money where mouth is on that.
I will put some effort into minimising the content of an example - but
starting with 2800 lines that could be much effort.
Thanks
David
On Wed, Sep 1, 2021 at 6:09 PM Greg Wooledge <g...@wooledge.org> wrote:
> On Wed, Sep 01, 2021 at 04:52:29PM +0100, David Collier wrote:
> > greg - I'm sorry - I assume there is a proper place for me to post
> > follow-up info, can you let me know where it is?
>
> On the bug-bash mailing list is fine. If the script is too big to
> post on bug-bash, then it's not useful for debugging anyway. We'd
> need something smaller that we can actually wrap our heads around.
>
> > I could try for a short script, but this thing is a bit like herding
> eels.
> > I narrowed it down to a single line containing 'sync' - but as you say
> > that's clearly impossible.
> > And to my embarrassment the bug remains unchanged when I comment-out
> > the word sync.
>
> OK, good, that's what I would expect.
>
> > !!!!!!!!!!!!!!!Here is a code segment ( I have removed a few == signs so
> it
> > fits across my screen. ):
> >
> > echo "================ At this point \$LINENO has correctly counted about
> > 2800 lines=========================test @ 2838 $LINENO"
> > echo "=== Something makes bash lose a few counts from \$LINENO - in this
> > case about nine - no idea how to fix it. ==="
> >
> > if ! filesOrSubdirsPresent "${rootOfDummyFsToInstallAPADN}/usr/sbin/*"
> > then :
> > if ${G_verbose} ; then echo "Skipping ${targetAPARN} - nothing
> found";
> > fi
> > else :
> > echo "Installing: ${targetAPARN}*"
> >
> > # Do we really want the '-p' option here??? - it corrupts ownership
> of
> > directories!
> > ( cp -dpR "${rootOfDummyFsToInstallAPADN}"/usr/sbin/* ${cpDestFlag}
> > "${targetAPARN}" )
> >
> > # Not sure we can know that there are no .sh or .pl scripts already
> > there but with execute off.
> > # but we install so many we can't go round naming them one-by-one.
> > #
> > setExecutabilityOfScriptsInEntireBranch "${targetAPARN}" # All of
> > our scripts in /usr/sbin do have .sh extensions.
> > echo
> >
> "===========================================================================================test
> > @ +16 $LINENO"
> > sync
> >
> > fi
> > echo
> >
> "==========================================================================================test
> > @ +20 $LINENO"
>
> I'm guessing filesOrSubdirsPresent and
> setExecutabilityOfScriptsInEntireBranch are functions.
>
> > As you can see, four lines further on, and LINENO has gone down by 5 -
> > making it 9 too small
>
> My first guess is that it has something to do with those function calls.
> Either the fact that bash is calling a function *at all*, or something
> that happens specifically in one of those functions, might be throwing
> off the count.
>
> IIRC you said you were using bash 5.0, so here's a dumb little test with
> bash-5.0 on my system:
>
>
> unicorn:~$ cat foo
> #!/usr/local/bin/bash-5.0
>
> f() {
> : this is f
> }
>
> echo "Point A: line #$LINENO"
> f
> echo "Point B: line #$LINENO"
> unicorn:~$ ./foo
> Point A: line #7
> Point B: line #9
>
>
> This one passes the test, so it's probably not something like "all
> functions break LINENO in the caller in bash 5.0". That would have been
> too obvious.
>
> You should look at setExecutabilityOfScriptsInEntireBranch (since that's
> the last function call before the problem is observed). Maybe something
> funny happens in there. You might be able to comment out that function
> call and see if that makes the problem vanish. If it does, then you can
> try to pinpoint what part of the function is triggering the problem.
>
> If it doesn't, then I'm at a loss.
>
