Fix typos
This commit is contained in:
parent
133905b309
commit
c34cc5e488
|
@ -401,7 +401,7 @@ of a derivation `x` by looking at their respective `name` attributes.
|
|||
The names (e.g., `gcc-3.3.1` are split into two parts: the package name
|
||||
(`gcc`), and the version (`3.3.1`). The version part starts after the
|
||||
first dash not followed by a letter. `x` is considered an upgrade of `y`
|
||||
if their package names match, and the version of `y` is higher that that
|
||||
if their package names match, and the version of `y` is higher than that
|
||||
of `x`.
|
||||
|
||||
The versions are compared by splitting them into contiguous components
|
||||
|
|
|
@ -125,7 +125,7 @@ Special exit codes:
|
|||
|
||||
- `104`\
|
||||
Not deterministic, the build succeeded in check mode but the
|
||||
resulting output is not binary reproducable.
|
||||
resulting output is not binary reproducible.
|
||||
|
||||
With the `--keep-going` flag it's possible for multiple failures to
|
||||
occur, in this case the 1xx status codes are or combined using binary
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
## Goals
|
||||
|
||||
Purpose of this document is to provide a clear direction to **help design
|
||||
delightful command line** experience. This document contain guidelines to
|
||||
delightful command line** experience. This document contains guidelines to
|
||||
follow to ensure a consistent and approachable user experience.
|
||||
|
||||
## Overview
|
||||
|
@ -230,8 +230,8 @@ Now **Learn** part of the output is where you educate users. You should only
|
|||
show it when you know that a build will take some time and not annoy users of
|
||||
the builds that take only few seconds.
|
||||
|
||||
Every feature like this should go though a intensive review and testing to
|
||||
collect as much a feedback as possible and to fine tune every little detail. If
|
||||
Every feature like this should go through an intensive review and testing to
|
||||
collect as much feedback as possible and to fine tune every little detail. If
|
||||
done right this can be an awesome features beginners and advance users will
|
||||
love, but if not done perfectly it will annoy users and leave bad impression.
|
||||
|
||||
|
@ -272,11 +272,11 @@ not know which `ARGUMENTS` and `OPTIONS` are required or which values are
|
|||
possible for those options.
|
||||
|
||||
In cases, the user might not provide the input or they provide wrong input,
|
||||
rather then show the error, prompt a user with an option to find and select
|
||||
rather than show the error, prompt a user with an option to find and select
|
||||
correct input (see examples).
|
||||
|
||||
Prompting is of course not required when TTY is not attached to STDIN. This
|
||||
would mean that scripts wont need to handle prompt, but rather handle errors.
|
||||
would mean that scripts won't need to handle prompt, but rather handle errors.
|
||||
|
||||
A place to use prompt and provide user with interactive select
|
||||
|
||||
|
@ -300,7 +300,7 @@ going to happen.
|
|||
```shell
|
||||
$ nix build --option substitutors https://cache.example.org
|
||||
------------------------------------------------------------------------
|
||||
Warning! A security related question need to be answered.
|
||||
Warning! A security related question needs to be answered.
|
||||
------------------------------------------------------------------------
|
||||
The following substitutors will be used to in `my-project`:
|
||||
- https://cache.example.org
|
||||
|
@ -311,14 +311,14 @@ $ nix build --option substitutors https://cache.example.org
|
|||
|
||||
# Output
|
||||
|
||||
Terminal output can be quite limiting in many ways. Which should forces us to
|
||||
Terminal output can be quite limiting in many ways. Which should force us to
|
||||
think about the experience even more. As with every design the output is a
|
||||
compromise between being terse and being verbose, between showing help to
|
||||
beginners and annoying advance users. For this it is important that we know
|
||||
what are the priorities.
|
||||
|
||||
Nix command line should be first and foremost written with beginners in mind.
|
||||
But users wont stay beginners for long and what was once useful might quickly
|
||||
But users won't stay beginners for long and what was once useful might quickly
|
||||
become annoying. There is no golden rule that we can give in this guideline
|
||||
that would make it easier how to draw a line and find best compromise.
|
||||
|
||||
|
@ -508,7 +508,7 @@ can, with a few key strokes, be changed into and advance introspection tool.
|
|||
|
||||
### Progress
|
||||
|
||||
For longer running commands we should provide and overview of the progress.
|
||||
For longer running commands we should provide and overview the progress.
|
||||
This is shown best in `nix build` example:
|
||||
|
||||
```shell
|
||||
|
@ -553,7 +553,7 @@ going to happen.
|
|||
```shell
|
||||
$ nix build --option substitutors https://cache.example.org
|
||||
------------------------------------------------------------------------
|
||||
Warning! A security related question need to be answered.
|
||||
Warning! A security related question needs to be answered.
|
||||
------------------------------------------------------------------------
|
||||
The following substitutors will be used to in `my-project`:
|
||||
- https://cache.example.org
|
||||
|
|
|
@ -237,7 +237,7 @@ Derivations can declare some infrequently used optional attributes.
|
|||
- `preferLocalBuild`\
|
||||
If this attribute is set to `true` and [distributed building is
|
||||
enabled](../advanced-topics/distributed-builds.md), then, if
|
||||
possible, the derivaton will be built locally instead of forwarded
|
||||
possible, the derivation will be built locally instead of forwarded
|
||||
to a remote machine. This is appropriate for trivial builders
|
||||
where the cost of doing a download or remote build would exceed
|
||||
the cost of building locally.
|
||||
|
|
|
@ -26,7 +26,7 @@ elements (referenced from the figure by number):
|
|||
called with three arguments: `stdenv`, `fetchurl`, and `perl`. They
|
||||
are needed to build Hello, but we don't know how to build them here;
|
||||
that's why they are function arguments. `stdenv` is a package that
|
||||
is used by almost all Nix Packages packages; it provides a
|
||||
is used by almost all Nix Packages; it provides a
|
||||
“standard” environment consisting of the things you would expect
|
||||
in a basic Unix environment: a C/C++ compiler (GCC, to be precise),
|
||||
the Bash shell, fundamental Unix tools such as `cp`, `grep`, `tar`,
|
||||
|
|
|
@ -64,7 +64,7 @@ Nix has the following basic data types:
|
|||
the start of each line. To be precise, it strips from each line a
|
||||
number of spaces equal to the minimal indentation of the string as a
|
||||
whole (disregarding the indentation of empty lines). For instance,
|
||||
the first and second line are indented two space, while the third
|
||||
the first and second line are indented two spaces, while the third
|
||||
line is indented four spaces. Thus, two spaces are stripped from
|
||||
each line, so the resulting string is
|
||||
|
||||
|
|
|
@ -127,7 +127,7 @@ $ nix-env --install firefox
|
|||
|
||||
_could_ cause quite a bit of build activity, as not only Firefox but
|
||||
also all its dependencies (all the way up to the C library and the
|
||||
compiler) would have to built, at least if they are not already in the
|
||||
compiler) would have to be built, at least if they are not already in the
|
||||
Nix store. This is a _source deployment model_. For most users,
|
||||
building from source is not very pleasant as it takes far too long.
|
||||
However, Nix can automatically skip building from source and instead
|
||||
|
|
Loading…
Reference in a new issue