[BUG] Git 2.42.0-rc2 t1092.57 script error

Hi Team,

I'm getting the following error when running t1092.57 in Git 2.42.0-rc2 on NonStop ia64:

+ ensure_not_expanded status
test_region[8]: test: argument expected
grep: ensure_full_index: No such file or directory
error: last command exited with $?=1
not ok 57 - sparse-index is not expanded

Any suggestions?

Thanks, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400) NonStop(211288444200000000) -- In real life, I talk too much.

<rsbecker@nexbridge.com> writes:

Sorry for not coming up with anything concrete.

"ensure_not_expanded status" should be running as its second step

	test_region ! index ensure_full_index trace2.txt

Which should do this:

    test_region () {
            local expect_exit=0
            if test "$1" = "!"
            then
                    expect_exit=1
                    shift
            fi

            grep -e	'"region_enter".*"category":"'"$1"'","label":"'"$2"\" "$3"
            exitcode=$?

            if test $exitcode != $expect_exit
            then

As "grep" complains that ensure_full_index is not a file, when the command runs there the file name is "$3".

So it appears to me that the first 

	test "$1" = "!"

is not firing and failing to set expect_exit to 1 and shift the "!" out of $@. Why? I dunno. Perhaps your shell has quirks around "local"? I dunno.

On Friday, August 18, 2023 3:05 PM, Junio C Hamano wrote:

'"region_enter".*"category":"'"$1"'","label":"'"$2"\" "$3"

runs

I dunno.

Is this new test code? The local qualified appears to be a bash extension, not available across all shells - from what I can determine. Is it really required here or just fancy?

<rsbecker@nexbridge.com> writes:

You are asking a wrong person ;-)

You know Git well enough to run "git blame" on this code yourself to answer the first question and find out whom to ask it:

  https://github.com/git/git/blame/master/t/test-lib-functions.sh#L1794

On Friday, August 18, 2023 5:28 PM, Junio C Hamano wrote:

the first

Code has been around 2 years. I will chase this down with the platform vendor. Thanks

the first

Well, it was investigated. local is not the issue. It is working correctly on ksh and bash on the platform. It is looking like the issue was something in the environment. We are on a new test system that is seriously overloaded, so it is possible that we ran out of resources or were close to the limit when the test started - multiple times earlier in the day, but it is feeling much better now and the subtest passed.

I'm going to write this one off as no factor.

Thanks for the help. --Randall