If the file is truncated after the function's closing brace, it will succeed but do nothing.
If the file is truncated in the middle of the word `check_sha512` it will try to execute a hopefully-not-existing command.
Wrapping in simple { braces } should fix this - if the brace is missing, you get a syntax error, and if present, you can execute the full thing, regardless of whether a trailing newline is available. This is admittedly bash-specific, so won't work for the linked script, but (subshell) doesn't cause too many problems
Using a function and checking the SHA don't really add anything after these fixes.
Checking the shebang is hostile to environments that install bash elsewhere.
An almost-working possibility would be:
exec some-interpreter -c 'commands' "$0" "$@" ""
which will fail if the second ' is missing. The child interpreter can then check for later truncation by checking that at least 2 arguments were passed and the last one is an empty string. However, this is still prone to truncation before the -c.
Comments
If the file is truncated after the function's closing brace, it will succeed but do nothing.
If the file is truncated in the middle of the word `check_sha512` it will try to execute a hopefully-not-existing command.
Wrapping in simple { braces } should fix this - if the brace is missing, you get a syntax error, and if present, you can execute the full thing, regardless of whether a trailing newline is available. This is admittedly bash-specific, so won't work for the linked script, but (subshell) doesn't cause too many problems
Using a function and checking the SHA don't really add anything after these fixes.
Checking the shebang is hostile to environments that install bash elsewhere.
An almost-working possibility would be:
which will fail if the second ' is missing. The child interpreter can then check for later truncation by checking that at least 2 arguments were passed and the last one is an empty string. However, this is still prone to truncation before the -c.