Re: [PATCH v2 1/2] test-lib.sh: add limited processes to test-lib

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 27, 2022, 12:22 UTC
Message-ID: <xmqqpmiuqosw.fsf@gitster.g>
In-Reply-To: <CAKgqsWVAy8RTSCwG=LVHPoeF5ECSzeNfK4mPacLo=dTeUkc6SA@mail.gmail.com>

Han Xin <hanxin.hx@bytedance.com> writes:

> Maybe I should use "lib-bash.sh" instead of "test-lib.sh" just like t9902
> and t9903?
> The different meanings of "-p" in bash and dash really make this tricky.

I do not think lib-bash.sh is appropriate for this.

t9902/9903 are about command line prompt and completion support _FOR_ bash users. By including lib-bash.sh, even if your "usual" shell is not bash, you can run these two scripts under bash, as long as you have it installed.

For the purpose of testing these bash specific features, that framework makes quite a lot of sense. Those who are happy to have dash on their system without having to install bash would have no reason to see these two tests to pass, as they do not care about bash at all.

What the test under discussion is doing is quite different. Instead of forcing to re-spawn bash when the user's shell is not bash, you'd want to adjust how you invoke "ulimit" if it is not bash, something like

run_with_limited_processes () {
	(ulimit ${ulimit_max_process-"-p"} 512 && "$@")
}

test_lazy_prereq ULIMIT_PROCESSES '
	# bash and ksh use "ulimit -u", dash uses "ulimit -p"
	if test -n "$BASH_VERSION"
	then
		ulimit_max_process="-u"
	elif test -n "$KSH_VERSION"
	then
		ulimit_max_process="-u"
	fi
        run_with_limited_processes true
'

perhaps?