fix: replace raw echo with output helpers in check

[github-actions]

Summary

• Replaced script-local die, testing, hint, and fail functions in check with the canonical die, info, and success helpers from shell-scripts.instructions.md
• All call sites updated: testing() → info(), hint() → info(), fail() → die(), bare echo "Testing:" and echo "* $FILE" → info()
• excluded() function's echo "1"/echo "0" internal return values preserved unchanged
• Shebang remains #!/bin/bash (script uses =~ and $BASH_REMATCH)

Closes #619

Test plan

• bash -n check — syntax clean
• shellcheck check — lint clean
• All pre-commit hooks pass (verified in commit)

[credfeto]

Super-linter summary

Language	Validation result
BASH	Pass ✅

All files and directories linted successfully

For more information, see the GitHub Actions workflow run

Powered by Super-linter

[dnyw4l3n13]

success() is defined here but is never called anywhere in the script.

Every file that passes all checks exits the loop silently — the user sees a stream of → progress lines and then nothing, making it impossible to distinguish "completed successfully" from "script terminated mid-run". The convention in shell-scripts.instructions.md states success is for completion (green ✓). At minimum it should be called once after the loop to confirm all checks passed:

Suggested change

	success() {
	success() {
	if [ -t 1 ]; then
	printf '\n\033[32m✓\033[0m %s\n' "$*"
	else
	printf '\n✓ %s\n' "$*"
	fi
	}

And at the end of the script (after done), add:

success "All checks passed"

[dnyw4l3n13]

Fixed in 111228a — added success "All checks passed" after the loop.

[dnyw4l3n13]

info "Could be run in sh?" uses the wrong semantic level for an advisory message.

The old hint() function emitted ? CHECK: Could be run in bash? — visually and programmatically distinct from progress steps ( + Executable, + Shebang) because of the ? CHECK: prefix. A log scanner or developer could reliably grep for ? CHECK to find actionable advisories.

The replacement info "Could be run in sh?" emits → Could be run in sh?, identical in format to info "Executable", info "Shebang", info "* $FILE", and every other progress line. The advisory is now invisible as a separate category in the output stream.

Since the canonical helpers have no advisory/hint level, consider prefixing the message to preserve the distinction:

Suggested change

	sh -n "$FILE" > /dev/null 2>&1 && info "Could be run in sh?"
	bash -n -u "$FILE" || die "$SHELL: Invalid Script"
	sh -n "$FILE" > /dev/null 2>&1 && info "Hint: Could be run in sh?"

Or at minimum use wording that makes the advisory nature clear and distinguishable in log output.

[dnyw4l3n13]

Fixed in 4673a79 — prefixed both sh-portability advisory messages with Hint: to distinguish them from progress steps.

[dnyw4l3n13]

Pre-existing: for FILE in $FILES iterates over an unquoted variable, which word-splits on $IFS (space, tab, newline). If any file path under $BASEDIR contains a space, the path is split into fragments and each fragment is processed as a separate (nonexistent) filename, causing spurious die "Not Executable" or die "No Shebang" failures.

The fix is to read into an array and iterate with "${FILES[@]}", or collect via mapfile:

mapfile -t FILES < <({ \
      find "$BASEDIR" -not -path '*/.*' -type f -executable -print || die "Search: find"
      ...
      } | sort -u)

for FILE in "${FILES[@]}"; do

This is adjacent to the changes in this PR — worth fixing here while the loop is being touched.

[dnyw4l3n13]

Fixed in cd3db9a — replaced FILES=$(...) + unquoted $FILES with mapfile -t FILES < <(...) and "${FILES[@]}".

[dnyw4l3n13]

success "All checks passed" fires even when FILES is empty (no scripts found).

If BASEDIR is wrong, a mount fails, or all files are excluded by the -not -path '*/.*' filter, mapfile populates an empty array. The for FILE in "${FILES[@]}" loop body is skipped silently. success "All checks passed" then prints unconditionally — a false pass in CI with nothing actually checked.

Add a guard before the loop:

Suggested change

	success "All checks passed"
	[ "${#FILES[@]}" -gt 0 ] || die "No script files found in ${BASEDIR}"
	info "Testing:"
	for FILE in "${FILES[@]}"; do

[dnyw4l3n13]

Fixed in 1b089c1 — added [ "${#FILES[@]}" -gt 0 ] || die "No script files found" guard before the loop.

[dnyw4l3n13]

die "Not Executable" omits the filename, and the context is now on a different stream.

info "* $FILE" (line 65) writes to stdout; die "Not Executable" (line 68) writes to stderr. A CI system capturing stdout and stderr into separate log files will see ✗ Not Executable with no indication of which file failed — the filename is only in the stdout log.

The old fail() wrote to stdout alongside echo "* $FILE", so both appeared in the same stream. This split is a real regression in diagnosability.

Fix: include ${FILE} in all die messages inside the loop:

Suggested change

	die "Not Executable"
	die "Not Executable: ${FILE}"

Same applies to die "$SHELL: Invalid Script", die "Unknown Shell: $SHEBANG_EXEC", die "No Shebang: $FIRST_LINE", and die "Shellcheck" further down in the loop.

[dnyw4l3n13]

Fixed in 29e568b — added ${FILE} to all six die messages inside the per-file loop.

[dnyw4l3n13]

AI Review Complete

All review rounds and security review passed. Auto-merge enabled.

Changes made during review

Code Review (3 rounds):

• Added success "All checks passed" at end of script — success() was defined but never called
• Prefixed sh-portability advisory messages with Hint: to distinguish from progress steps
• Replaced unquoted $FILES string with mapfile -t FILES array to prevent word-splitting on paths containing spaces
• Added [ "${#FILES[@]}" -gt 0 ] || die "..." guard to prevent false-positive success when no scripts are found
• Added ${FILE} to all six die messages inside the per-file loop — die() writes to stderr while info "* $FILE" writes to stdout; CI systems capturing them separately would lose filename context
• Added two additional CHANGELOG entries for the mapfile and empty-files guard correctness fixes

Security Review:
No vulnerabilities found.