This adds basic tests for three functions in pkg/eval/builtin_fn_cmd.go
that implement the `external`, `has-external`, and `search-external`
builtin commands. TBD is how to test those commands on MS Windows.
Related #1062
I stumbled across a comment that began with "XXX". It was clearly meant as
a "TODO" comment. This changes all such occurrences. However, a few "XXX"
comments are ambiguous and a better prefix might be "WARNING". The "TODO"
prefix at least ensures someone, eventually, looks into the situation
and either rewords the comment or fixes the problem. This change means
everyone can assume searching for "// TODO" will find all such comments
rather than requiring they also know to search for "// XXX".
I started by writing tests for sys.Ioctl but after I had 100% coverage
of that function it occurred to me the function could be eliminated.
Related #1062
* pkg/eval/str: move builtin ord and chr to str
Move builtin string function ord and chr to the str module and rename to
to str:to-codepoints and str:from-codepoints respectively as suggested
in #851.
* pkg/eval/str: add from-utf8-bytes & to-utf8-bytes
Add from-utf8-bytes and to-utf8-bytes functions to the str module. This
functions differ from their *-codepoints in that they handle utf8 bytes
instead of whole codepoints. Closes#851
* pkg/eval/str: range check for codepoint and bytes
str:from-codepoints
Add check if arguments codepoints are within valid unicode range, return
an OutOfRange error otherwise. Return a BadValue error if the codepoint
isn't valid. Add/change testcases.
str:from-utf8-bytes
Add check if byte arguments are within valid range, return an OutOfRange
error otherwise. Return a BadValue error if the byte sequence isn't a
valid UTF-8 sequence. Add/change testcases.
Add additional test if piping from str:to-codepoints/str:to-utf8-bytes
to str:from-codpoints/str:from-utf8-bytes returns the original input.
If the shell outputs more data than can be buffered the test will
deadlock. I noticed this when working on issue #661. The tests I was
writing would deadlock because a tty can buffer significantly less data
than a pipe. Even using a pipe, which typically buffers 8 to 128 KiB, this
is theoretically a problem. So use a goroutine to capture the output as it
is generated rather than reading it all at once when the test terminates.
While working on my next commit, to prevent I/O deadlocks, I experienced
some problems because I had a syntax error in the Elvish code to generate
the output. That wasn't immediately obvious because I had copied another
test that only tested the stdout of the shell and the syntax error was
written to stderr. This change modifies existing tests to verify both
stdout and stderr have the expected content.
Note that there are three interactive tests for which we still do not
verify the content of stderr. That's because stderr for those tests only
contains a shell prompt whose content changes each time the test is run.
TBD is modifying the interactive tests to have a predictable prompt.
Since `break`, `continue`, and `return` are builtin commands, rather
than language keywords, they should be documented on the builtin module
reference page.
In addition to an uncontroversial spelling fix this addresses several,
related, warnings produced by the `golint` tool. In general I agree with
golint that unnecessary "else" blocks should be avoided. So this change
refactors those cases.
Note: I recognize that `golint` is deprecated (see
https://github.com/golang/go/issues/38968) since it is no longer being
maintained and there is controversy about its set of warnings. Nonetheless,
it appears that the warnings it emits for this project are all reasonable
and actionable with one potential exception: the naming of the `map_`
method in pkg/eval/compile_value.go.
The `test-race-works && go test -race || go test` formulation causes
tests to be run twice on platforms that support the `-race` option if
any test fails.
Fixes#1085
