Hello everyone,
# Elektra 0.8.12
- 0.8.12 packaged+migrated to testing
(https://packages.qa.debian.org/e/elektra/news/20150726T155000Z.html),
thanks to Pino Toscano
So trying Elektra is only one apt-get away for you!
# Elektra 0.8.13
For a html site visit:
http://doc.libelektra.org/news/3c00a5f1-c017-4555-92b5-a2cf6e0803e3.html
For general information about Elektra, see [http://libelektra.org]
(http://libelektra.org)
## Elektrify-getenv
getenv(3) is one of the most popular ways to retrieve configuration,
even though it has many known problems:
- no standard way to modify it
- relogin (or restart of shell) necessary
- names are flat (no hierarchical structure)
- cannot be set for individual applications
- different in at, cron and similar scripts
With elektrify-getenv we wrote a solution which solves most of the
problems. We use the LD_PRELOAD technique to *additionally* retrieve
values from Elektra, and not only the environment.
You simply can do:
```bash
kdb set user/env/override/HTTP_PROXY "http://my.proxy:8080";
```
This will set the `HTTP_PROXY` environment variable to
`http://my.proxy:8080`.
Configuration can be retrieved with `kdb get`:
```bash
kdb get user/env/override/HTTP_PROXY
lynx # or start another www-browser with the newly set HTTP_PROXY
```
Or using the man pages:
kdb elektrify-getenv man man --elektra:MANWIDTH=40
Will use MANWIDTH 40 for this invocation of man man.
This feature is handy, if an option is only available
by environment, but not by command-line arguments,
because sometimes environment variables are not trivial
to set (e.g. in Makefiles).
Some more examples:
kdb set user/env/override/MANOPT -- "--regex -LC"
kdb elektrify-getenv getenv MANOPT # to check if it is set as expected
kdb getenv MANOPT # if /etc/ld.so.preload is active
So is this the final solution for configuration and manual elektrification
of applications is not needed anymore?
The answer is: no and yes.
It is quite satisfactory for configuration that is inherently sharable
(not different from one application to another) *and* needs the environment
semantics, i.e. some subprocesses should have different configuration
than others, e.g. in a specific terminal.
But it might not be a good solution for your own application, because
libgetenv(3) implies many architectural decision, that other elektrified
applications would decide differently, e.g.:
- it uses global variables (getenv(3) has no handle)
- it uses mutex for multi-threading safety
- the API getenv(3) only returns `char*` and has no support for other data
types
For more information see [src/libgetenv/README.md]
(http://git.libelektra.org/blob/master/src/libgetenv/README.md)
## Compatibility
As always, the API and API is fully forward-compatible, i.e. programs
compiled
against an
older 0.8 versions of Elektra will continue to work.
Because `keyUnescapedName` and `keyGetUnescapedNameSize` is added in this
release, it is not backward-compatible,
i.e. programs compiled against 0.8.13, might *not* work with older 0.8
libraries.
The function `keyUnescapedName` provides access to an unescaped name, i.e.
one
where `/` and `\\` are
literal symbols and do not have any special meaning. `NULL` characters are
used as path separators.
This function makes it trivial and efficient to iterate over all path names,
as
already exploited
in all bindings:
- [jna (java)]
(http://git.libelektra.org/blob/master/src/bindings/jna/HelloElektra.java)
- [lua]
(http://git.libelektra.org/blob/master/src/bindings/swig/lua/tests/test_key.lua)
- [python2]
(http://git.libelektra.org/blob/master/src/bindings/swig/python2/tests/testpy2_key.py)
- [python3]
(http://git.libelektra.org/blob/master/src/bindings/swig/python3/tests/test_key.py)
Other small changes/additions in bindings:
- fix key constructor, thanks to Manuel Mausz
- add copy and deepcopy in python (+examples,+testcases), thanks to Manuel
Mausz
- dup() in python3 returned wrong type (SWIG wrapper), thanks to Toscano
Pino
for reporting, thanks to Manuel Mausz for fixing it
Doxygen 1.8.8 is preferred and the configfile was updated to this version.
The symbols of nickel (for the ni plugin) do not longer leak from the
Elektra
library.
As such, old versions of testmod_ni won't work with Elektra 0.8.13.
A version-script is now in use to only export following symbols:
- kdb*
- key*
- ks*
- libelektra* for module loading system
- elektra* for proposed and other functions (no ABI/API compatibility here!)
In this release, ENABLE_CXX11 was changed to `ON` by default.
Note that in the next release 0.8.14 there will be two changes:
- According to [issue #262](http://git.libelektra.org/issues/262), we plan
to remove the option ENABLE_CXX11
and require the compiler to be C++11 compatible.
If you have any system you are not able to build Elektra with -
DENABLE_CXX11=ON (which is
the default for 0.8.13) please report that immediately.
- the python3 bindings will be
