feat(assert): symlink assertions - #995
Merged
Merged
Conversation
Closes #981. Nothing in the catalogue could assert anything about a symlink. Every filesystem assertion follows the link -- `-f` and `-e` report on the target -- so a link and the file it points at were indistinguishable, and a dangling link answered "does not exist", the same as a path that was never created: ln -s "$dir/target" "$dir/link" assert_is_file "$dir/link" # passes, describing the target ln -s "$dir/missing" "$dir/broken" assert_file_not_exists "$dir/broken" # passes, describing nothing That matters for the things people actually write bash for: install scripts, dotfile managers, a release layout with a `current -> releases/N` pointer. For those, "the link exists and points where it should" is the assertion. Three added: assert_is_symlink, assert_is_not_symlink, assert_symlink_to. Two decisions the issue asked to be made rather than guessed. A dangling link is still a link. assert_is_symlink passes for one, because separating "is a link" from "the target resolves" is exactly the distinction that was missing -- and the two existing assertions already answer the second question. assert_symlink_to compares the target **as written**, through `readlink`, not the resolved path. It is what the test author wrote, so a failure names something they recognise, and `readlink -f` is GNU-only, so resolving would need a second implementation for BSD/macOS. A relative link compares as the relative string it is; documented as such. Tests skip on Windows, where Git Bash turns symlink creation into a copy -- matching the existing guard on the permission tests. docs/assertions.md, both completion scripts and the doc snapshot updated. The completions parity test caught assert_symlink_to missing from the lists, which is the job it exists for. 1705 sequential / 1664 parallel; baseline + 8, all RED first.
Closed
8 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤔 Background
Related #981
Nothing in the catalogue could assert anything about a symlink. Every filesystem assertion follows the link (
-f,-ereport on the target), so a link and the file it points at were indistinguishable — and a dangling link answered "does not exist", the same as a path that was never created:That matters for what people actually write bash for: install scripts, dotfile managers, a release layout with a
current -> releases/Npointer. For those, "the link exists and points where it should" is the assertion.💡 Changes
assert_is_symlink "$path"$pathis a symbolic link, resolved or notassert_is_not_symlink "$path"$pathis not a symbolic linkassert_symlink_to "$target" "$path"$pathis a link and points at$target🧭 Two decisions the issue asked to be made, not guessed
A dangling link is still a link.
assert_is_symlinkpasses for one — separating "is a link" from "the target resolves" is exactly the distinction that was missing, and the two existing assertions already answer the second question.assert_symlink_tocompares the target as written, throughreadlink, not the resolved path. It's what the test author wrote, so a failure names something they recognise; andreadlink -fis GNU-only, so resolving would need a second implementation for BSD/macOS. A relative link compares as the relative string it is — documented.✅ Verification
8 new tests, all RED first. They skip on Windows, where Git Bash turns symlink creation into a copy — matching the existing guard on the permission tests.
docs/assertions.md, both completion scripts and the doc snapshot updated. The completions parity test caughtassert_symlink_tomissing from the lists, which is the job it exists for.make sa·make lint·bash build.sh bin -v→✅ Build verified ✅· 1705 sequential / 1664 parallel-simple-strict.