Fix tests when using rust-coreutils (#5542)

[renanrodrigo]

Authored-by: Renan Rodrigo rr@ubuntu.com

testHeaders copies the 'true' binary to a file named testHeaders
relying on the fact that GNU's true always exits 0. The 'true'
implementation in rust-coreutils is a multicall binary which
returns based on argv[0] - so it can't be called by other name.

Create an empty executable instead.

[yadij]

Polished the description to fit Anubis requirements. No Substantive change.
Marking for review by myself as I want to look into the side effects of ':' command deeper - we had a lot of portability issues revealed while settling on use of $(TRUE) previously.

[yadij]

Okay, the ':' command redirection support checks out as good for bash, dash, ksh and csh (for Linux, BSD, and ARM devices). I am not able to test MinGW, Cygwin or MacOS shells specifically for redirection but they should also be okay since we already know they support the command itself.

[kinkie]

output redirection is done by the calling shell, there's no reason it shouldn't work.
MacOs' shell is either bash or zsh, also not concerned about it.
Good catch!

[rousskov]

Do we need to make $@ (i.e. squid-conf-tests) executable? Sorry, I cannot easily check this myself right now.

If the answer is "no", then should we switch from rather unusual/obscure redirection code that creates an empty executable file to simple and well-known touch that we already use in, for example, errors/Makefile.am?

[yadij]

We do, because it is executed by other parts of automake. That is why it is true in the first place instead of just a touch (been there tried that years ago).

[athos-ribeiro]

How about using install -m 775 /dev/null $@ to avoid the unusual redirection then? Assuming true is around, install should also be since it is part of coreutils as well.

[athos-ribeiro]

i.e., s;cp $(TRUE);install -m 775 /dev/null/; instead of : > $@ && chmod +x

[rousskov]

We do, because it is executed by other parts of automake.

Which one? AFAICT, no part requires that squid-conf-tests file is executable, and no part executes that file. Replacing our cp with touch worked in my quick-and-dirty test.

(been there tried that years ago).

Can you give a specific reference? FWIW, there are other use cases where we do execute the copied binary (e.g., testHeaders), but this question is specific to squid-conf-tests.

[yadij]

athos-ribeiro:

i.e., s;cp $(TRUE);install -m 775 /dev/null/; instead of : > $@ && chmod +x

Unfortunately anything under /dev is not guaranteed to be a file we can copy. It may be a socket, pipe, or kernel device. Best we could do along that approach is, e.g. use install to duplicate a local script that calls true - which is just extra complication.

While it is a bit obscure the : > $@ command is sufficient and works portably. The part holding review is whether we can drop the chmod entirely. If we can, then a simple and clear touch $@ would be better logic.

[renanrodrigo]

FWIW If the : approach is too shady, a comment on why could be useful?

[yadij]

IMO the only thing "shady" about it is that it is a symbol instead of a word self-documenting what it does/means. Once one finds the right part of shell documentation it checks out as fine.

[rousskov]

FWIW If the : approach is too shady, a comment on why could be useful?

This change request is not about the arguably problematic choice of executable creation code (i.e. redirecting :). It is about the alleged need to create an executable here (by any means). This change request remains unaddressed. I will come back to that in a separate comment later -- it is difficult for me to type long responses right now. Carefully rereading (and answering) my request followup may speed things up.

However, I would be curious to know the answer to the why question, even though it is outside this change request scope: How would you justify using : instead of doing something more ordinary/well-understood/etc.? This answer may help with the other change in this PR.

[yadij]

It seems @rousskov is right. This specific line is not building a target listed in TESTS, so it specifically does not need to be executable.

I have now run a complete re-test and the below change works well and simpler:

Suggested change

	if test "$$failed" -eq 0; then : > $@ && chmod +x $@ ; else exit 1; fi
	test "$$failed" -eq 0 && touch $@ || exit 1

[yadij]

output redirection is done by the calling shell, there's no reason it shouldn't work. MacOs' shell is either bash or zsh, also not concerned about it. Good catch!

Thanks for that info. I have now also tested zsh - it does work as needed.