There was a recent question for which the answer was to use the
`-compileonly` flag but the user didn't realize that because there was
no mention on https://elv.sh/ref/command.html. Similarly, other flags,
like `-decpreation-level`, would benefit from more verbiage than shown by
`elvish -help`.
Instead of putting all possible flags in prog.Flags, flags are now registered by
the individual subprograms. The 3 flags -sock, -db and -json are shared by
multiple subprograms and still handled by the prog package.
This new design allows separating the support for -cpuprofile into a separate
subprogram, which is no longer included by the default entry point, making the
binary slightly smaller. A new entrypoint "withpprof" is created.
Also include the LSP subprogram in the nodaemon entry point.
Now that v0.17-release has been branched, the HEAD build will show deprecations
intended for 0.17.0, and be considered a pre-release version of 0.18.0.
POSIX shells have a `-i` short option to force interactive mode. Some
programs, such as the `script` command, assume that option is recognized
by the shell it spawns. There isn't any reason elvish shouldn't silently
ignore that option.
Resolves#1292
* Rebrand NEXT-RELEASE.md to the release notes for 0.15.0, and publish it.
* Bump default deprecation level to 15.
* Add download links in website/get/prelude.md.
Previously, to avoid showing deprecation warnings for the next release when the
user is running on HEAD, a boolean CLI flag -show-deprecations is introduced,
and is set to false in the master branch. The idea is that release branches will
have this default to true, so people running released versions will see
deprecations.
However, this means that people running on HEAD will never see any deprecations
unless they use this CLI flag, which is not ideal. This commit replaces the flag
bool -show-deprecations with a numerical -deprecation-level flag, which requests
deprecations that are active as of release 0.X to be shown. The default value of
this flag will be the minor version number of the *last* release, so that people
running HEAD will see as many deprecation warnings as people running the last
release would. This number will be bumped just before releases.
The Elvish daemon should not inherit file descriptors open on the tty.
Make the daemon's stdin open on the null device and its stdout/stderr
open on a predictable file.
Fixes#1191
As with commit #eb2a792 I acknowledge that `golint` recommendations are
controversial and should not automatically be acted on. Nonetheless,
this change fixes legitimate lint issues such as copy/paste cleanups,
style problems I introduced (`i += 1` versus `i++`) or method/var comments
that are not in the preferred form.
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.
The behavior is controlled by a global flag that will be flipped for the release
branch. A flag is available to force deprecations to be shown or hidden.
