[PR #135] [MERGED] Fix path regex compatibility with Bash 5.3 #127

New issue

Closed

opened 2026-10-15 18:07:12 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:07:12 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/SillyTavern/SillyTavern-Launcher/pull/135
Author: @jochst
Created: 8/3/2026
Status: ✅ Merged
Merged: 8/4/2026
Merged by: @deffcolony

Base: main ← Head: fix/bash-5-3-path-regex

📝 Commits (1)

5315f31 Fix path regex compatibility with Bash 5.3

📊 Changes

1 file changed (+2 additions, -1 deletions)

View changed files

📝 launcher.sh (+2 -1)

📄 Description

Summary

Replace the inline path-validation regex with a valid POSIX ERE stored in a shell variable.
Preserve the same 22 forbidden path characters.
Avoid a runtime invalid regular expression failure on GNU Bash 5.3.

Root cause

launcher.sh used this expression in check_path_special_chars:

[[ "$PWD" =~ [\!\#\$\%\&\*\+\,\;\<\=\>\?\@\[\]\^\`\{\|\}\~] ]]

On GNU Bash 5.3.9, the regex backend rejects the escaped braces inside the bracket expression with:

invalid regular expression ... Invalid content of \{\}

bash -n launcher.sh does not report the problem because -n validates shell syntax without executing commands. The right-hand side of [[ string =~ regex ]] is compiled by Bash's regex engine only when that conditional executes, so the script can pass the syntax check and still fail at startup.

The error appeared in a Zsh terminal, but Zsh was not parsing this expression during normal ./launcher.sh execution. The script has a #!/bin/bash shebang, so Zsh launched Bash as the child interpreter and displayed Bash's runtime diagnostic on the terminal. Sourcing the launcher into Zsh would be a separate, unsupported execution mode.

Fix

Store a standards-compliant bracket expression in a single-quoted variable and pass that variable to =~:

local special_chars_re='[][!#$%&*+,;<=>?@^`{|}~]'
if [[ $PWD =~ $special_chars_re ]]; then

Placing ] first makes it literal inside the bracket expression. The braces are already literal inside the class and must not be escaped. Keeping the regex in a single-quoted variable also avoids shell-parser ambiguity around the punctuation.

Verification

No canonical launcher test suite was detected, so I ran focused behavioral verification against the function extracted from the modified launcher.sh:

bash -n launcher.sh
git diff --check
Confirmed a normal path is accepted
Confirmed all 22 intended forbidden characters are rejected
Confirmed none of those executions produce an invalid-regex diagnostic

Test environment: GNU Bash 5.3.9.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/SillyTavern/SillyTavern-Launcher/pull/135 **Author:** [@jochst](https://github.com/jochst) **Created:** 8/3/2026 **Status:** ✅ Merged **Merged:** 8/4/2026 **Merged by:** [@deffcolony](https://github.com/deffcolony) **Base:** `main` ← **Head:** `fix/bash-5-3-path-regex` --- ### 📝 Commits (1) - [`5315f31`](https://github.com/SillyTavern/SillyTavern-Launcher/commit/5315f31c40b6adf63b8d55d95e7d69e41401ed1c) Fix path regex compatibility with Bash 5.3 ### 📊 Changes **1 file changed** (+2 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `launcher.sh` (+2 -1) </details> ### 📄 Description ## Summary - Replace the inline path-validation regex with a valid POSIX ERE stored in a shell variable. - Preserve the same 22 forbidden path characters. - Avoid a runtime `invalid regular expression` failure on GNU Bash 5.3. ## Root cause `launcher.sh` used this expression in `check_path_special_chars`: ```bash [[ "$PWD" =~ [\!\#\$\%\&\*\+\,\;\<\=\>\?\@\[\]\^\`\{\|\}\~] ]] ``` On GNU Bash 5.3.9, the regex backend rejects the escaped braces inside the bracket expression with: ```text invalid regular expression ... Invalid content of \{\} ``` `bash -n launcher.sh` does not report the problem because `-n` validates shell syntax without executing commands. The right-hand side of `[[ string =~ regex ]]` is compiled by Bash's regex engine only when that conditional executes, so the script can pass the syntax check and still fail at startup. The error appeared in a Zsh terminal, but Zsh was not parsing this expression during normal `./launcher.sh` execution. The script has a `#!/bin/bash` shebang, so Zsh launched Bash as the child interpreter and displayed Bash's runtime diagnostic on the terminal. Sourcing the launcher into Zsh would be a separate, unsupported execution mode. ## Fix Store a standards-compliant bracket expression in a single-quoted variable and pass that variable to `=~`: ```bash local special_chars_re='[][!#$%&*+,;<=>?@^`{|}~]' if [[ $PWD =~ $special_chars_re ]]; then ``` Placing `]` first makes it literal inside the bracket expression. The braces are already literal inside the class and must not be escaped. Keeping the regex in a single-quoted variable also avoids shell-parser ambiguity around the punctuation. ## Verification No canonical launcher test suite was detected, so I ran focused behavioral verification against the function extracted from the modified `launcher.sh`: - `bash -n launcher.sh` - `git diff --check` - Confirmed a normal path is accepted - Confirmed all 22 intended forbidden characters are rejected - Confirmed none of those executions produce an invalid-regex diagnostic Test environment: GNU Bash 5.3.9. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 18:07:12 +00:00