…ansion

`GLOB_SHELL_SPECIAL` omitted `~`,
so a `{ op: 'glob', pattern }` token emitted a leading tilde unescaped and the shell expanded it to an absolute path.

The omission was inherited, not chosen:
the glob branch (4378a6e, v1.8.4)
was written a month before `~` was added to the string branch (v1.9.0, #9),
when neither class escaped it, and was never revisited.
The resulting inconsistency was observable in the round-trip -
`quote(parse('cat ~/foo.txt'))` already yielded `cat \~/foo.txt`,
while `quote(parse('cat ~/*.txt'))` yielded `cat ~/*.txt` unchanged,
so adding a glob character silently decided whether `~` expanded.

Tilde expansion is a shell word-expansion,
not a glob metacharacter,
so escaping it costs no pattern-matching fidelity:
`sh -c 'echo \~x*'` still matches files literally named `~x`.
Glob metacharacters continue to pass through unescaped.

`{`, `}`, and `,` are deliberately left alone:
brace patterns are glob syntax to minimatch/node-glob,
and their pass-through is pinned by an existing test.

`{ op: 'glob', pattern: '' }` emitted an empty string,
which `join(' ')` then collapsed,
so the token silently vanished from the output:
three tokens in, two arguments out.
The `s === ''` check only ever tested raw string tokens,
never `s.pattern`.

Emit `''` instead,
matching what a bare empty string token already does,
so the token keeps its argv slot.

The special-parameter branch of `parseEnvVar` advanced the scanner once too many,
so the character right after `$?`, `$#`, `$$`, `$-`, `$!`, `$*`, or `$@` was dropped:
`parse('$?suffix', { '?': '1' })` returned `['1uffix']`.
When that character was an opening quote, the rest of the word was unquoted:
`$?"a;b"` parsed as a bogus `{ op }` token, and `$?'#x' y` swallowed `y` into a comment.

…y text

`_` is a name character in POSIX shells,
so `$_foo` is the variable `_foo`, not `$_` followed by `foo`.
The special-parameter class included `_`, which split the name after one character.
Without `_` in that class, the identifier branch reads the whole name,
and a bare `$_` still resolves to `_`.

A `{ comment }` token emits `#...`, which comments out the rest of the line,
including the opening quote of any later string token.
A line terminator inside that later string ends the comment,
and the rest of the string is parsed as shell input:
`quote(['echo', { comment: 'x' }, 'a\nid;#'])` runs `id` in sh, bash, zsh, ksh, and dash.

`parse` emits a comment for a mid-word `#` (e.g. `http://x/#frag`),
so appending tokens to `parse` output is enough to reach it.

The line-terminator check added for `comment` in 4378a6e only covered the comment's own text.
Now any string after a comment is checked with the same line-terminator set.
Tokens after a comment without line terminators are unchanged.

An argument containing `'` is double-quoted, where `!` was escaped as `\!`.
Inside double quotes, POSIX shells keep that backslash
(sh, bash, dash, ksh, and zsh, when non-interactive),
so `quote(["O'Brien!"])` produced `O'Brien\!`.

Such arguments are now single-quoted, with each `'` written as `'"'"'` (as Python's `shlex.quote` does),
so `!` needs no escape and is not history-expanded in interactive shells.
No double-quoted output contains `!` anymore, so it is dropped from that branch's escape class.
The existing test/quote.js assertion changed here pinned the corrupt output.

…, `evalmd`

…er it

The chunker never paired `\\`, so it treated the second backslash as escaping the next character,
while the scanner, like bash, pairs them.
Unquoted, `a\\ b` parsed as one word,
and `a\;echo b` and `x\\|cat` returned a malformed `{ op }` token that hid the operator.
Inside double quotes, the pattern could run past a closing `"` that followed `\\` whenever another `"` came later,
so `"a\\" "b"` parsed as one word and `"a\\";echo "b"` as one malformed `{ op }`.

Pair escaped characters in barewords, including the escape character itself,
and build the double-quote pattern from the escape character, as `BAREWORD` already is,
with disjoint alternatives (an escape pairs with any next character), as the scanner does.

`parse` now decodes bash ANSI-C quoted strings,
the form Chrome/Edge DevTools emit from "Copy as cURL (bash)"
(e.g. `--data-raw $'...'`).
Previously the `$` was kept,
escapes were not decoded,
and an escaped quote (`\'`) ended the string early.

Escapes are decoded as bash does (`\n`, `\t`, `\'`, `\"`, `\\`, `\a`, `\b`, `\e`, `\E`, `\f`, `\r`, `\v`, `\?`,
`\nnn`, `\xHH`, `\uHHHH`, `\UHHHHHHHH`, `\cx`);
an unrecognized escape keeps its backslash,
and a NUL ends the string.
The contents are never split, globbed, or expanded,
and `$'...'` is not special inside other quotes.

zsdycs: the feature, its README section, and the original tests.
Jordan Harband: the linear-time implementation in `parse.js`, word-boundary and `splitUnquoted` handling, and the added tests.

Closes #32

Co-authored-by: zsdycs <mail@lipk.org>
Co-authored-by: Jordan Harband <ljharb@gmail.com>

…-quote branch

That branch is only reached when the string contains no `'`,
so `s.replace(/(['])/g, '\\$1')` was a no-op;
output is unchanged for every string.
It also encoded the wrong idiom (`\'` does not escape inside single quotes),
and CodeQL's `js/incomplete-sanitization` kept flagging it,
asking for the backslash escaping that #20 removed to fix #15.