This conveys spacing much better thanks to the separateecho line, even though I have a feeling this was done for portability as$'magic' might not be allowed everywhere.

I did it for spacing, and to to takefuller advantage ofecho to have fewer\n sequences. Although it's true that$'' is not POSIX and shouldn't be used in a#!/bin/sh script, this script is abash script and$'' is a available inbash on all systems. (ksh,zsh, and probably some other shells also have$'', but not all POSIX-compatible shells have it.)

Regarding spacing, the table is currently formatted usingprintf and this has the advantage that its own output spacing can be adjusted by, for example, changing14 to15. But I originally usedprintf for it because I was preferringprintf toecho, because originally I wasdoing this inline inMakefile, and aMakefile runs commands using/bin/sh (unlessSHELL is assigned in theMakefile itself). This was to follow the practice of avoidingecho in portablesh scripts,at least when displaying data read from files.

But that is not necessary in a#!/bin/bash script, where we know howecho works and whereecho doesn't expand escape sequences by default. So it would actually be okay, at this point, to go back to displaying the table this way:

echoecho'The VERSION must be the same in all locations, and so must the HEAD and tag SHA'echo"VERSION file   =$version_version"echo"changes.rst    =$changes_version"echo"Latest tag     =$latest_tag"echo"HEAD SHA       =$head_sha"echo"Latest tag SHA =$latest_tag_sha"

This is arguably more readable, and arguably conveys spacing the best. I'd be happy to change it to this if you like.

(Another option could be to go in the opposite direction and make thischeck-version.sh script, and maybe thebuild-release.sh script as well, a#!/bin/sh script, which is feasible.)

This is arguably more readable, and arguably conveys spacing the best. I'd be happy to change it to this if you like.
(Another option could be to go in the opposite direction and make thischeck-version.sh script, and maybe thebuild-release.sh script as well, a#!/bin/sh script, which is feasible.)

Sincetrap is supported in POSIX shells and thussh, making these scripts more portable seems valuable, even though I think that as the project currently is setup there isn't any need as it's only me using them.
Alternatives involve running these on CI which also supportsbash everywhere (at least so it seems).

If you think there is benefits to portability assuming that one day CI can perform trusted publishes, I think it's fair to adjust for portability next time you touch them. Otherwise, it would be just as fair to changeprintf withecho as shown above. It's perfectly optional as well.

The desired interaction oftrap andset -e may be achievable insh. Even if not, we don't have to usetrap; it can be replaced even without making the control-flow logic more complicated or error prone. For example, the script could accept-q to not append the failure message, and otherwise invoke itself with-q, check the result, print the message if it failed, and exit with the original failing exit code. (There is alsoan argument to be made thatset -e shouldn't be relied on at all.)

There are not many systems wherebash doesn't exist and can't be made available. However, due to the problem described in729372f--which only happens when MinGWmake is being used on a native Windows system that has also WSL installed, and does not happen outsidemake nor on other systems--the scripts'bash hashbangs are written as#!/bin/bash rather than#!/usr/bin/env bash, and thus assumebash is in/bin.

Making them#!/bin/sh scripts would also fix that. It is even safer to assumesh is inbin than to assumeenv is in/usr/bin, so#!/usr/bin/env sh is rarely used. (Anyway, there is no corresponding WSL-relatedsh.exe inSystem32.) So, when combined with the other minor reasons for using#!/bin/sh, that is probably worth doing.

As you've suggested, next time I work on those scripts I'll look into making them POSIXsh scripts. However, this would be unrelated to facilitating trusted publishing. CI does supportbash everywhere, at least on runners hosted by GitHub Actions.