Permalink
Browse files

Spelling: Replace “behaviour” with “behavior”

  • Loading branch information...
sanssecours committed Sep 19, 2017
1 parent 5a207cf commit b64c37d8449f66f76b2ba7d5ae94936ad0f022df
View
@@ -26,7 +26,7 @@ Elektra consists of three parts:
hierarchical key database. The building blocks are:
- language bindings (inclusive high-level interfaces)
- GenElektra, the code generator for type-safe bindings
- plugins for configuration access behaviour and validation
- plugins for configuration access behavior and validation
2. *SpecElektra* is a configuration specification language
that is easy to use and self-contained in the same key database (i.e.
written in any of the configuration file formats Elektra supports).
@@ -128,12 +128,12 @@ You can read the documentation for the kdb tool, either
you can even roll your own plugins to provide exactly the same behavior
as your application has now.)
- Make configuration storage more safe: avoid that applications
receive wrong or unexpected values that could lead to undefined behaviour.
receive wrong or unexpected values that could lead to undefined behavior.
And in terms of quality, we want:
1. Simplicity (make configuration tasks, like access of configuration settings, simple),
2. Robustness (no undefined behaviour of applications), and
2. Robustness (no undefined behavior of applications), and
3. Extensibility (gain control over configuration access)
[Read more about the goals of Elektra](doc/GOALS.md)
View
@@ -173,7 +173,7 @@ by `dataSize`.
Elektra’s function share common error codes. Every function must return
`-1` on error, if its return type is integer (like `int`, `ssize_t`). If
the function returns a pointer, `0` (`NULL`) will indicate an error.
This behaviour can't be used for functions that return integers, since
This behavior can't be used for functions that return integers, since
`0` is a valid size and can also be used to represent the boolean value
`false`.
View
@@ -51,11 +51,11 @@ Special care for simplicity is taken for the users:
Configuration systems today suffer badly from:
- Different behaviour on different systems
- Different behavior on different systems
- Weak input validation
- Faulty transformations from strings to other types
- No error messages
- Undefined behaviour
- Undefined behavior
- Migration from one version to another
We want to tackle this problem by introducing an abstraction layer where
View
@@ -48,7 +48,7 @@ The convenience plugin should transform (it might be combined with a plugin that
- most easy to implement
- allows presence to be true
- plugins allow us to convert to any other behaviour
- plugins allow us to convert to any other behavior
## Implications
@@ -8,7 +8,7 @@ and another backend. (For POSIX file systems a similar technique is
`pathconf()`. It allows the user to query the capabilities of a specific
mounted file system given by path.) Capabilities made it possible
to implement a backend different from the way `filesys` works and let
the backend still have predictable behaviour. The user could query a
the backend still have predictable behavior. The user could query a
backend if it was capable of a specific detail of file system semantics.
Capabilities were initially introduced to make backend development easier,
@@ -11,7 +11,7 @@ are all linked together to libelektra.org.
## Constraints
- have a legacy libelektra that is identical to current behaviour
- have a legacy libelektra that is identical to current behavior
- full and static libraries remain unchanged
## Assumptions
@@ -2,7 +2,7 @@
## Issue
There is a different behaviour of various plugins whether their name is
There is a different behavior of various plugins whether their name is
absolute or relative, including:
1. mounting the same file somewhere else does not work
@@ -52,7 +52,7 @@ the assertion that failed).
- In the end we have to write a lot of functionality ourselves anyway (e.g. comparing Keys and KeySets)
- Testsuite execution are already handled by cmake and kdb run-all.
- The selection of tests within a test suite does not play well with ctest.
- Rewriting all current tests to have unified behaviour is a lot of work
- Rewriting all current tests to have unified behavior is a lot of work
- Wont work for ABI compatibility tests
- Mock only by extra framework
View
@@ -46,7 +46,7 @@ key database. Elektra could not guarantee that every application
retrieves the same configuration with the same key names any longer.
In `kdbOpen()`, nearly no checks are done regarding the expected
behaviour of the backend. The contract checker guarantees that only
behavior of the backend. The contract checker guarantees that only
appropriate mountpoints are written into the mountpoint configuration.
`kdbOpen()` checks only if the opening of plugin was successful. If not,
the backend enclosing the plugin is not mounted at all.
@@ -59,7 +59,7 @@ single `Key` object could be removed from the database. For configuration
files this method is inapplicable. For `filesys`, however, it was easy
to implement.
In Elektra version 0.7, the behaviour changed. Removing keys was
In Elektra version 0.7, the behavior changed. Removing keys was
integrated into `kdbSet()`. The user tagged keys that should be removed.
After the next `kdbSet()`, these keys were removed from the key database.
On the one hand, backends writing configuration files simply ignored
@@ -83,7 +83,7 @@ properties for `kdbSet()`. The same `KeySet` can be applied multiple
times, but after the first time, the key database will not be changed
anymore. (Note that `kdbSet()`) actually detects that
there are no changes and will do nothing. To actually show the idempotent
behaviour the KeySet has to be regenerated or the key database needs to
behavior the KeySet has to be regenerated or the key database needs to
be reopened.
It is, however, not known if keys should be removed permanently
@@ -140,7 +140,7 @@ can happen that more than one backend delivers a key with the same name.
`kdbGet()` ensures that a key is uniquely identified by its name.
Elektra’s core will [pop](/doc/help/elektra-glossary.md) keys that are
outside of the backend's responsibility. Hence, these keys will not be
passed to the user and we get the desired behaviour: The nearest mounted
passed to the user and we get the desired behavior: The nearest mounted
backend to the key is responsible.
For example, a generator plugin in the backend (A) always emits
@@ -276,7 +276,7 @@ and `kdbGet()` works as expected.
## kdbSet
Not performance, but robust and reliable behaviour is the most
Not performance, but robust and reliable behavior is the most
important issue for `kdbSet()`. The design was chosen so that some
additional in-memory comparisons are preferred to a suboptimal sequence
of `syscalls`. The algorithm makes sure that keys
@@ -395,7 +395,7 @@ such a acyclic r-partite hypergraph is 0.
### Assignment
The `opmphmAssignment ()` function assigns either your order (set at `OpmphmGraph->edges[i].order`) or a default order.
The default order is the order of `OpmphmInit->data`. The `defaultOrder` parameter indicates the behaviour.
The default order is the order of `OpmphmInit->data`. The `defaultOrder` parameter indicates the behavior.
When the OPMPHM is build with the default order, `OpmphmGraph->edges[i].order` must not be set.
After the build the OpmphmInit and OpmphmGraph should be freed.
@@ -28,7 +28,7 @@ also leave any description out. In this situation it is unclear what
the plugin will do. Such a plugin can add or remove keys, and changes
values and metadata regardless what other plugins expect. If only such
plugins existed there would be chaos. It would be impossible to determine
the behaviour of a backend which uses a multiple of such plugins.
the behavior of a backend which uses a multiple of such plugins.
To avoid this situation, every plugin exports a contract describing how
the plugin modifies the `KeySet` `returned`. Most often it is enough
@@ -42,12 +42,12 @@ guaranteed by data structures do not need to be stated in the contract.
Plugins should not be burdened to check too many postconditions. Instead,
plugins focus on their task. The plugin does not need to check the sync
flag of keys or if the keys are below the mountpoint. The core already
guarantees correct behaviour as described
guarantees correct behavior as described
in [algorithm](/doc/dev/algorithm.md).
To sum up, contracts give the information how a plugin interacts with
others. It describes if, and how, the `KeySet` `returned` is changed.
Using contracts, we get a predictable behaviour, but still support every
Using contracts, we get a predictable behavior, but still support every
kind of plugin.
@@ -138,7 +138,7 @@ not in a productive environment.
But the plugin's implementation is allowed to change without being
remounted if it is a subtype of the earlier version. Only in this
situation it can be a drop-in replacement. With a good testing framework
the behaviour can be checked to some extent.
the behavior can be checked to some extent.
We also see in the listing above that the code responsible for generating
the contract and the code for the implementation are next to each other.
@@ -5,7 +5,7 @@ One important aspect of a configuration library is the out-of-the-box
experience. How does the system work before anything is configured?
The optimal situation is that everything fully works, and applications,
that just want to load and store configuration, do not see any difference
between out-of-the-box behaviour and a well-configured, fine-tuned system.
between out-of-the-box behavior and a well-configured, fine-tuned system.
To support that experience, a so-called **default backend** is
responsible in the case that nothing was configured so far. It must
@@ -4,7 +4,7 @@ elektra-mounting(7) -- mounting
**Mounting** is the process of integrating a backend that reads and writes
a specific configuration file into the global key database.
Mounting allows you to use different configuration files but also
allows you to change the behaviour of writing/reading keys
allows you to change the behavior of writing/reading keys
to/from the global key database. For example, you need to mount if you want to:
- change the syntax of a configuration file,
@@ -26,7 +26,7 @@ inheritance. We see that plugins are able to add more semantics to
Elektra.
There are no symbolic links, hard links, device files or anything else
different from key value pairs. Again, most of these behaviours can be
different from key value pairs. Again, most of these behaviors can be
mimicked using metadata. Especially, links are available using the metadata
`override` and `fallback`.
View
@@ -25,7 +25,7 @@ and maybe give a description for them (we use ini syntax in this document):
[mykey]
[folder/anotherkey]
description = set this key if you want another behaviour
description = set this key if you want another behavior
```
So Keys in `spec` allow us to specify which keys are read by the application.
View
@@ -10,7 +10,7 @@ kdb-help(1) -- Show man page for elektra tools
## DESCRIPTION
Show a man page for one of Elektra’s tools.
Note that `kdb <tool> --help` might have a different behaviour, depending on the tool.
Note that `kdb <tool> --help` might have a different behavior, depending on the tool.
Also note that, no additional commandline options are allowed for this kind of
invocation. If you want that use `--help` or `-H` after `<tool>`.
View
@@ -52,7 +52,7 @@ is also in Elektra’s key database, stored in metadata and e.g. below
system/elektra/mountpoints. In Elektra validators can be
written in any language (because the specification is just data)
and can enforce constraints on any access (because plugins define
the behaviour of the key database).
the behavior of the key database).
@@ -560,7 +560,7 @@ not be used anymore.
POSIX compatibility and handling of multi-process conflicts has
been improved. Now the HOME environment variable will be used. The
old behaviour (USER environment variable) is still available as
old behavior (USER environment variable) is still available as
fallback. Additionally there is a fallback for embedded systems to the
hard coded variant. In case of these fallbacks a warning will be added.
@@ -4,7 +4,7 @@ This tutorial assumes that you are already familiar with [namespaces](/doc/tutor
When Elektra looks up a _cascading key_ (i.e. key names without a namespace and a leading slash `/`, the namespaces are searched in the following order:
* [spec](https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#spec) (contains metadata, e.g. to modify elektra lookup behaviour)
* [spec](https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#spec) (contains metadata, e.g. to modify elektra lookup behavior)
* [proc](https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#proc) (process-related information)
* [dir](https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#dir) (directory-related information, e.g. `.git` or `.htaccess`)
* [user](https://github.com/ElektraInitiative/libelektra/blob/master/doc/help/elektra-namespaces.md#user) (user configuration)
@@ -92,10 +92,10 @@ The **spec** namespace is used to store metadata about keys and therefore Elektr
The `spec` namespace is special as it can completely change how the cascading
lookup works.
During a cascading lookup for a specific key, the default Elektra behaviour can be changed by a corresponding `spec-key`, i.e. a key in the **spec** namespace **with the same name**.
During a cascading lookup for a specific key, the default Elektra behavior can be changed by a corresponding `spec-key`, i.e. a key in the **spec** namespace **with the same name**.
For example, the metadata `override/#0` of the respective `spec-key`
can be specified to use a different key in favor of the key itself. This way, we can implement a redirect or symlink like behaviour and therefore even
can be specified to use a different key in favor of the key itself. This way, we can implement a redirect or symlink like behavior and therefore even
config from current folder (`dir` namespace) can be overwritten.
The cascading lookup will consider the following **metadata keys** of `spec-key`:
View
@@ -161,9 +161,9 @@ sudo kdb mount /.git/config dir/git ini multiline=0
As git uses the `ini` format for its configuration we use the [ini plugin](/src/plugins/ini/README.md).
You can pass parameters to plugins during the mount process. This is what
we did with `multiline=0`. Git intents the entries in its configuration
files and the default behaviour of the `ini` plugin is to interpret these indented
files and the default behavior of the `ini` plugin is to interpret these indented
entries as values that span multiple lines. The passed parameter disables
this behaviour and makes the ini-plugin compatible with git configuration.
this behavior and makes the ini-plugin compatible with git configuration.
Now let us see how smoothly the ini plugin sets and gets the git configuration.
View
@@ -1,3 +1,13 @@
# ==============================
# = British → American English =
# ==============================
s/behaviour/behavior/g
# ===================
# = Technical Terms =
# ===================
s/\<meta[- ]key\>/metakey/g
s/\<meta[- ]name\>/metaname/g
s/\<meta[- ]value\>/metavalue/g
@@ -227,7 +227,7 @@ Some more examples:
Will permanently and user-wide change MANOPT to include --regex, and -LC so
that regular expressions will be used (note `man echo` will return many man
pages then) and that they will be shown in English.
This feature is handy to change the default behaviour of
This feature is handy to change the default behavior of
applications (either system, user or directory-wide).
@@ -13,7 +13,7 @@
Plugins (should) rarely return an error or warnings, e.g. writing
the configuration basically only fails on file system problems. Such
behaviour is difficult to produce for tests.
behavior is difficult to produce for tests.
This plugin tackles this issue by yielding error/warnings on request.
@@ -66,7 +66,7 @@ As with most configuration file formats, some characters carry special meaning.
1. the `=` sign, which separates keys from values and
2. `#` and `;`, the characters that denote a comment.
In case of **key values** you do not need to care about the special meaning of these characters most of the time, since the plugin handles escaping and unescaping of them for you. Since mINI use the backslash character (`\`) to escape values, the backspace character will be escaped too (`\\`). The following example shows the escaping behaviour.
In case of **key values** you do not need to care about the special meaning of these characters most of the time, since the plugin handles escaping and unescaping of them for you. Since mINI use the backslash character (`\`) to escape values, the backspace character will be escaped too (`\\`). The following example shows the escaping behavior.
```sh
kdb mount mini.ini /examples/mini mini
@@ -99,7 +99,7 @@ kdb rm -r /examples/mini
kdb umount /examples/mini
```
In the case of **key names** you **must not use any of the characters mentioned above** (`;`, `#` and `=`) at all. Otherwise the behaviour of the plugin will be **undefined**.
In the case of **key names** you **must not use any of the characters mentioned above** (`;`, `#` and `=`) at all. Otherwise the behavior of the plugin will be **undefined**.
## Limitations
@@ -30,7 +30,7 @@ interrelations of keys are called structure checker. They can require that
various subkeys have to or must not exist. This can happen recursively
to specify any structure.
The struct plugin implements such a behaviour. It allows enforcement of
The struct plugin implements such a behavior. It allows enforcement of
a strong consistency within the keys of one backend.
## Usage

0 comments on commit b64c37d

Please sign in to comment.