- Don't test for '\\' in u3_unix_safe. Doing otherwise was crashing vere
when unmounting a mountpoint that had come to contain a file with '\\'
in its path. This might mean you can do bad things on Windows if other
checks fail.
- Ignore any files whose names do not pass `(sane %ta)` when scanning
directories. (This reimplements `(sane %ta)` in C. Perhaps it should
instead call `(sane %ta)`.)
- Use '~.' rather than '~' for the escape. We ignore files that end in
'~', probably for vim backup-file reasons.
- Add a _unix_string_to_knot missed in the prior conversion.
unix cannot represent the file with empty name, and it has special
mappings for '.' and '..'. as these three are all valid arvo `+knot`s,
we need to escape them if we come across them.
the method we use to escape is: if we encounter any of those three
`+knot`s, or any `+knot` starting with '~', we prepend its filename with
a '~'. and when going from filename to `+knot`, we do the reverse; i.e.
we ignore a '~' if it is the first character of a filename.
the current implementation just crashes if it encounters a `+knot`
containing '/' or '\\', neither of which are valid under the current
implementation of `@ta` (which only accepts numbers, lowercase, '-',
'~', '.', and '_'.)
it also crashes if it encounters a file containing '\\'. something else
should happen here; most likely vere should just ignore the file.
On M1 Macs, the compiler seems to infinite-loop, consuming ever more RAM
and CPU, while trying to build `noun/allocate.c` with `-O3 -g`. `-O3` is
fine, `-g` is fine. Both at once seems to try to summon demons.
Other possible solutions aside from this:
- try lower levels of optimization until we find one that doesn't hang,
and ship that.
- do not support M1 Mac until the underlying issue here is fixed.
- ship debug binaries on M1 for now.
The path of least resistance is of course the second option, as that's
what is already tacitly happening.
