C Shell for Windows: baixar versions anteriors

The theme of this release is **silent success** — the shell accepting something,
reporting 0, and doing something other than what was asked. An alias that did
nothing. An unterminated `if` that ran its body. A `$dir/$file` that came out as
`$dir`. A `-n` that was accepted and ignored, so a syntax check *ran* the script.
A `--help` that hung. Most of what follows is one of those.

245 built-in commands; 159 test suites.

### ⚠️ Behaviour change: `==` and `!=` compare text

This is the one most likely to change what an existing script does, so it is
first.

In csh, `==` and `!=` compare **strings**; `<`, `>`, `<=` and `>=` compare
**numbers**. That split is the whole of the language's type system. cshw
honoured the second half and not the first: it tried a numeric comparison
first whenever both operands looked like numbers. Measured against tcsh
6.24.13, every one of these disagreed:

```
tcsh cshw was cshw now
5 == 05 false true false
0 == 00 false true false
10 == 010 false true false
007 == 7 false true false
-5 == -05 false true false
1e2 == 100 false true false
```

It reads as a convenience — `if ($day == "07")` matching day 7 — right up to
the moment the same rule makes `if ($ver == "1.0")` and `if ($ver == "1.00")`
disagree about the same version, or decides two zero-padded ids are the same
id.

It is not theoretical. Turning it on found five assertions in cshw's own test
suite that were passing *because* of it: two expected `100^20` with one zero
too many, and both sides overflowed a 64-bit parse to the same value, so a
numeric `==` called a wrong answer right. Three more compared a byte count
against `"0"` and passed on an **empty** string, because empty counted as
numeric zero — a missing file read as a passing test.

**If you want the numeric reading, say so.** Three cast keywords, on either
operand, set the comparison for the whole expression:

```
if ( num $month == "01" ) # 1 == 1 true
if ( @ $month == "01" ) # same, spelled the way @ already means
if ( str $month == "01" ) # "1" vs "01" false -- the default, said aloud
```

`@` is spelled that way because it is already cshw's arithmetic tier; the cast
is that same idea pulled into a condition. It compares as a float when either
side has a fraction or an exponent, so `@ 5 == 5.0` is true and
`@ 0.5 == 0.4` is not.

A numeric comparison has **no range limit**. Two whole numbers are compared as
decimal text -- sign, then length, then digits -- so nothing overflows:

```
num 100000000000000000000 == 100000000000000000001 false
100000000000000000000 < 100000000000000000001 true
```

This matters more than it looks. Going through a 64-bit parse SATURATES, so
every value past that range collapses onto one number and compares equal --
which is the exact defect `==` became a string comparison to remove. It is
what let two of cshw's own tests expect `100^20` with one zero too many and
still pass.

Radix prefixes read the same here as everywhere else in the shell, so `base`,
`@` and a comparison agree on what a number says:

```
num 0x100 == 256 true 0b and 0o too
0x100 < 100 false it reads 256, not 0
0x100 == 256 false plain == is still TEXT
```

`str` also works on the relational operators, where it makes them
lexicographic — so the keyword means one thing on all six rather than being
silently ignored on four:

```
if ( str "10" < str "9" ) # true
if ( "10" < "9" ) # false -- numeric, as before
```

A cast keyword is only a cast when something follows it to cast. `num` and
`str` remain ordinary words otherwise, so none of these changed meaning:

```
if ( num == 5 ) # the WORD "num", compared with 5
if ( numeric == numeric ) # a longer word is untouched
set num = 5
if ( $num == 5 ) # a variable named num reads normally
```

One deliberate divergence: `@ x = ( 5 == 05 )` stays **numeric** in cshw,
where tcsh routes `@` through the same string-comparing parser. Inside `@`
everything is a number — that is what `@` is, and what makes it readable as
the numeric cast.

### ⚠️ Be

**Fixed: a quoted argument starting with `<` or `>` was treated as a redirect.**
Upgrade for this one. The redirect parser looked only at the first character of
each token and never at the token's type, so a quoted string beginning with an
angle bracket was parsed as a redirect operator rather than as data. The lexer
had always distinguished the two; the parser simply never asked.

It failed in two ways, and the quiet one is the reason this is a same-day
release.

When the text after `>` was not a legal Windows filename, the open failed and
you saw `'echo' failed (errno 22)` with the command's output silently dropped.
That is how it was found: `tests/run_all_tests.cshw` prints
`echo ">>> Running: $1"` before each suite, and all 81 of those lines were being
destroyed, along with the matching `<<< PASSED` / `<<< FAILED` lines.

When the text *was* a legal filename there was no error at all. `echo
">notes.txt"` truncated `notes.txt`, consumed the token as a redirect, and left
`echo` with no arguments -- so `echo` wrote its own `Echo is ON` status into the
file it had just destroyed. A line written to print a string destroyed a file
instead, silently. Anything quoting an angle bracket was exposed: markdown
blockquotes, `grep "<div>" page.html`, generated HTML or XML.

Quoted tokens are now skipped when scanning for redirects. Real redirects are
unaffected.

v1.0.8.1 is a correctness and packaging release.

Fixed: output could cross between concurrently running commands. Command
substitution closed the real stdout handle when redirecting, and Windows
recycled that handle value for the next capture file -- so a background
command's output could land inside an unrelated backtick capture, and a child
process could inherit an already-closed handle. Separately, a background
command using > took over the shell's own stdout for the duration, so
interactive output could vanish. Redirection state is now per-thread.

New: spawn opens another cshw in a new console window, inheriting the current
directory and exported environment (-c/-k payloads, /d, /title, /min, /max,
/wait, /here). New -k switch runs a command then stays interactive, matching
cmd's /K.

Fixed: cshw -c "exit 7" returned 0 instead of 7. The start command's
documented /min /max /wait /b /d /i switches were silently ignored; all six
work now. tokenize reported failure on success.

Packaging: quicsrv.exe and the bundled nghttp2 / msquic / nghttp3 libraries
shipped unsigned in 1.0.8.0 -- everything in this release is signed, and the
portable zip now carries the native libraries it was missing, so HTTP/2 and
HTTP/3 work for portable and Scoop installs.

Note: the code-signing certificate changed to correct a malformed publisher
name, so Windows treats this as a new publisher and SmartScreen reputation
restarts.

v1.0.8.0: the server family ships. The tsrvd supervisor launches and manages
out-of-process protocol handlers -- native SMTP, POP3, and IMAP over a shared
Maildir mailstore, FTP, and a real HTTP/HTTPS/CGI server (http.dll) that speaks
HTTP/1.1 and HTTP/2 (ALPN + nghttp2). A new quicsrv worker serves HTTP/3 over QUIC
(msquic + nghttp3) through the same static + CGI serving core, and the fetch client
adds native --http2 and --http3 modes that guarantee the protocol instead of
best-effort negotiation. All server binaries are signed and packaged in both the
installer and the portable zip. No breaking changes to the shell language.

v1.0.7.1-alpha: cosmetic version-display fixes. `cshw --version` now prints
"C-Shell for Windows version 1.0.7.1" and exits (previously fell into REPL
mode -- noticed by the winget validator). The `ver` / `version` builtins
now show all four components ("1.0.7.1" instead of "1.0.7"). No behavior
changes; underlying shell is identical to 1.0.7.0.

v1.0.7.0-alpha (carried over): concurrent pipelines. Each segment of
`a | b | c` runs on its own thread with bounded Win32 pipes between
adjacent stages. Streaming early-termination -- `seq 1 10000000 | head -1`
now stops the producer near-instantly instead of running to completion.
External commands stream too via STARTF_USESTDHANDLES. Pipelines inside
procs see $1/$argv correctly. `set pipemode = sequential` preserved as
the user-selectable opt-out that restores 1.0.6.x semantics.

bc -x exact rationals plus matrix tier and complex numbers, POSIX dc with
conditional macros and register arrays, cascading settings layer
(settings.csh > HKCU > HKLM > built-in default), 79/79 test suites green
in both pipeline modes.

v1.0.7.0-alpha: concurrent pipelines. Each segment of `a | b | c` runs on its
own thread with bounded Win32 pipes between adjacent stages. Streaming
early-termination -- `seq 1 10000000 | head -1` now stops the producer
near-instantly instead of running to completion. External commands stream too
via STARTF_USESTDHANDLES with per-stage handles. Pipelines inside procs see
$1/$argv correctly via per-thread scope snapshot. Backtick capture of
pipelines works under load. `set pipemode = sequential` preserved as the
user-selectable opt-out that restores 1.0.6.x semantics byte-for-byte.

Carries over from 1.0.6.x: bc -x exact rationals plus matrix tier and complex
numbers, POSIX dc with conditional macros and register arrays, cascading
settings layer (settings.csh > HKCU > HKLM > built-in default), 79/79 test
suites green in both pipeline modes.