Skip to content

fix: report the real version from --version - #10

Merged
iamteedoh merged 1 commit into
mainfrom
DIR-4-version-annotation
Jul 17, 2026
Merged

fix: report the real version from --version#10
iamteedoh merged 1 commit into
mainfrom
DIR-4-version-annotation

Conversation

@iamteedoh

@iamteedoh iamteedoh commented Jul 17, 2026

Copy link
Copy Markdown
Owner

What does this PR do?

--version reported 0.1.0 while the released tag was v0.2.0, and the banner showed the same stale number. Cutting 0.3.0 would have widened the gap to two versions.

The repo releases with release-please's simple strategy, which rewrites versions only on lines carrying an x-release-please-version annotation, and only in files listed under extra-files. VERSION= had neither, so it never moved after 0.1.0 and drifted further with every release.

Changes

  • Annotate the constant: VERSION="0.2.0" # x-release-please-version
  • Declare the script under extra-files in release-please-config.json, so release-please's Generic updater actually runs on it

Set to the currently released 0.2.0. The pending release PR now carries it to whatever version is being released, so the constant is owned by the release process rather than maintained by hand — and the drift cannot recur.

Why both halves are needed

The annotation alone does nothing. Verified against release-please's own updater source (src/updaters/generic.ts):

  • INLINE_UPDATE_REGEX = /x-release-please-(?<scope>major|minor|patch|version-date|version|date)/ picks the line
  • but buildExtraFileUpdates only constructs a Generic updater for paths listed in extra-files

Without extra-files, the annotated line is never visited. Both are required.

Related issue

DIR-4

Validation

git ls-files '*.sh' | xargs shellcheck          # clean
git ls-files '*.sh' | xargs -n1 bash -n         # clean
./tests/run_tests.sh                            # 47 passed, 0 failed
gitleaks git . --config .gitleaks.toml          # no leaks found
python3 -m json.tool release-please-config.json # valid
  • ./dirPathPerms.sh --version now prints dirPathPerms 0.2.0, matching the released tag; the banner agrees.
  • Simulated release-please's Generic updater using the regexes from its source against this file: exactly one line matches, and it rewrites to VERSION="0.3.0" for a 0.3.0 release. No other line in the script is touched.

Checklist

  • git ls-files '*.sh' | xargs shellcheck passes
  • git ls-files '*.sh' | xargs -n1 bash -n passes
  • gitleaks reports no secrets in Git history
  • Scripts and programs include a GPL-3.0-or-later SPDX header
  • No secrets, tokens, credentials, or private infrastructure details are committed
  • Documentation is updated for user-visible or operational changes
  • The PR title follows Conventional Commits

@iamteedoh
DIR-4: let release-please own the version constant
de7cad5 
--version reported 0.1.0 while the released tag was v0.2.0, and the banner
showed the same stale number. The repo releases with release-please's simple
strategy, which rewrites versions only on lines carrying an
x-release-please-version annotation, and only in files listed under
extra-files. VERSION= had neither, so it never moved after 0.1.0 and drifted
further with every release.

Annotate the constant and declare the script as an extra file, so the version
is owned by the release process rather than maintained by hand. Set it to the
currently released 0.2.0; the pending release PR now carries it to the version
being released.
@iamteedoh
iamteedoh merged commit 0d87357 into main Jul 17, 2026
3 checks passed
@iamteedoh
iamteedoh deleted the DIR-4-version-annotation branch July 17, 2026 01:05
@github-actions github-actions Bot mentioned this pull request Jul 17, 2026
Merged
iamteedoh pushed a commit that referenced this pull request Jul 17, 2026
@github-actions
chore(main): release 0.3.0 (#8)
1ad2e24 
🤖 I have created a release *beep* *boop*
---


##
[0.3.0](v0.2.0...v0.3.0)
(2026-07-17)


### Features

* check paths directly, with tilde/variable expansion and prompt history
([#7](#7))
([c7f3389](c7f3389))
* interactive session with tabular output
([#9](#9))
([e1d5e08](e1d5e08))


### Bug Fixes

* report the real version from --version
([#10](#10))
([0d87357](0d87357))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@iamteedoh iamteedoh mentioned this pull request Jul 17, 2026
Merged
7 tasks
iamteedoh added a commit that referenced this pull request Jul 17, 2026
@iamteedoh
docs: document tab completion and bring the README up to date (#11)
219ebea 
## What does this PR do?

Three releases of behavior landed (#7, #9, #10) and parts of the README
still described the tool as it was before. This audits the whole file
against what v0.3.0 actually does.

### Documents tab completion

The prompt has completed paths ever since readline arrived alongside the
arrow-key history, and nothing said so — which means nobody would ever
try it. Adds a keys table under **Interactive**: `Tab`, `↑`/`↓`,
`Ctrl-A`/`E`/`W`/`U`/`R`, `q`.

The table records what was **verified over a pty**, not what readline is
assumed to do. Two claims were corrected during testing:

- An earlier draft said "press Tab twice to list the candidates". That
is false for `read -e` — it fills the common prefix and beeps without
listing. Re-tested on a 120×40 pty in case readline was suppressing the
list on a 0×0 terminal; it was not.
- The session's history never touches your shell history (`HISTFILE` is
cleared), so that is now stated rather than left to guesswork.

### Corrects what had gone stale

| Was | Now |
|---|---|
| Overview: prompts "for the input file and the permission to check" | a
session taking a path *or* a list file, looping until `q` |
| Feature bullet advertising `owner rwx \| group r-x \| other r--` |
that format no longer exists — replaced with the `Mode` column |
| "Interactive prompts guide the user to select the input file" |
predated `--path` |
| "prompts for the rest when a terminal is attached" | had drifted under
the **Paths vs. lists** heading during earlier edits, reading as though
it were about disambiguation — moved back |
| Prerequisites | now name the Bash 3.2 floor (what macOS ships), the
tty the session needs, and that `getent`/`dscl` are only for *another*
user's `~` |
| Installation: "save the script content to a file" | predated the repo
having releases — clone or download the release |

### Adds an Exit codes section

The README recommends the tool for cron and CI but never documented that
**a denied permission exits `0`** — only usage errors exit `2`. Anyone
writing `dirPathPerms.sh … || alert` would get silence forever. Now
documented, with a grep-based recipe for acting on the result.

## Related issue

DIR-5

## Validation

Documentation-only, so the value is in whether the claims are **true**.
Every runnable claim was executed rather than eyeballed:

- **All 16 documented flags** exercised (`-P`, `--path`, `-f`, `--file`,
`-w` × 4, `-p` × 5, `-a`/`--all`, `--no-color`, `-h`, `-V`, positional,
repeatable `-P`) — all pass.
- **Exit codes verified** against the new table: denied → `0`; missing
list file, unknown option, `--file`+`--path`, and no-tty-no-path → `2`.
- **The CI recipe was run**: it fires on a group-writable directory and
stays silent when nothing matches.
- **Tab completion driven over a pty** for `/etc/pass`, `/var/lo`,
`~/Doc`.
- All README internal anchors resolve.
- Repo gate unchanged and green: shellcheck, `bash -n`, 47/47 tests,
gitleaks.

## Notes for review

Two things deliberately **not** done here:

- **Symlink caveat.** Verifying a README example surfaced a real bug —
`/tmp` reports the symlink's mode (`lrwxr-xr-x`) instead of the target's
(`drwxrwxrwt`), so the tool answers "not group-writable" when it is.
Raised as **DIR-6**. Documenting it as a caveat would enshrine a bug
that should be fixed instead; say the word if you'd rather ship the
caveat.
- **The hero image** in `assets/` still shows `v0.1.0` and the old `File
path:` prompt — the exact UX #7 removed. It needs re-capturing from a
real terminal; there is no terminal-to-image tooling available to
regenerate it here.

`docs:` — README-only, so release-please will not bump the version for
it.

## Checklist

- [x] `git ls-files '*.sh' | xargs shellcheck` passes
- [x] `git ls-files '*.sh' | xargs -n1 bash -n` passes
- [x] gitleaks reports no secrets in Git history
- [x] Scripts and programs include a GPL-3.0-or-later SPDX header
- [x] No secrets, tokens, credentials, or private infrastructure details
are committed
- [x] Documentation is updated for user-visible or operational changes
- [x] The PR title follows Conventional Commits
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@iamteedoh