The present version of the specification is somewhat unclear at times,
Unclear points were discussed with the maintainers [1] and probably
some new version will address those.
https://www.spinics.net/lists/util-linux-ng/msg15222.html
Until then here's how the implementation copes with ambiguities
(after the discussion with util-linux maintainers):
1.) It is unclear whether multiple .schem files should override each
other or be merged. We use the overriding behavior -- take the
highest priority one and ignore the rest.
2.) We assume "name.schem" is more specific than "@term.schem".
3.) We assume the "Color name" are to be used as aliases for the color
sequences and translate them to ANSI escape sequences.
4.) The "Escape sequences" are of no use since the specification
pretty much assumes an ANSI terminal and none of the sequences make
any sense in ANSI color codes. We don't support them.
accept that.
5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
what should it do.
This basically replaces the (NMMetaTermColor, NMMetaTermFormat) combo
with NMMetaColor that describes the colored element semantically as
opposed to storing the raw attributes.
A (currently static) paletted is used to translate the semantic color
code to the actual ANSI controle sequence. This matches what
terminal-colors.d(5) schemes use, making it convenient to implement
customizable palettes.
This actually makes very little difference at the moment, but will make
things more confortable later on, when the logic of enabling/disabling
coloring will involve terminal-colors.d(5).
Instead of deciding whether to use colors lazily with use_colors(), it's
done very early on nmcli initialization and a boolean use_colors field
is stored in the NmcConfig instance instead of the raw tristate option
of NmcColorOption type (which is now confined to nmcli.c).
Wherever the NmcColorOption was used previously, the whole NmcConfig
instance is passed around. That might seem pointless (since only the
use_colors boolean is actually used at the moment), but will be utilized
to pass around the actual color palette in future.
It's undocumented, useless, somewhat expensive in volume of code and
probably just downright stupid. We'll get a more general way to set
colors.
Hacking in some code to keep this working wouldn't be too difficult, but
it seems entirely pointless.
Instead of setting multiple callbacks, just let the user set one
vtable with callbacks. Usually, GObject would implement this via
signals. While that makes sense for public objects, for example to
work better with GIR and allow intercepting the signal, this is
overkill for our internal type. And NMPolkitListener already did
not make use of signals, for good reason.
Instead of passing multiple callbacks, must pass one structure with
callback pointers.
Also, extend the signature of the callbacks to always contain a
@self argument and a @user_data.
Some cleanup of the includes. For example, immediately after
"nm-default.h" include the header file for the current source.
Also, move the use of the "#if WITH_POLKIT_AGENT" conditionals
closer together. E.g. don't use the #if in "nmcli.h".
Add a new 'overview' command line option to make the output more
compact and display only properties that have non-default
values. Currently the option has only effect for the "connection show
$CON" sub-command.
$ nmcli -o connection show wifi-home
connection.id: wifi-home
connection.uuid: 8308c425-f2a7-4021-9afc-37bde7253c6d
connection.type: 802-11-wireless
connection.timestamp: 1519264421
connection.permissions: user:me
802-11-wireless.ssid: home
802-11-wireless.mode: infrastructure
802-11-wireless-security.key-mgmt: wpa-psk
802-11-wireless-security.auth-alg: open
ipv4.method: auto
ipv6.method: auto
https://bugzilla.redhat.com/show_bug.cgi?id=1434527
This makes it a lot more convenient to deal with long outputs (such as
"nmcli c show id ...").
The implementation is essentially jacked from systemd. The bugs are
mine.
The show-secrets flag can be toggled in edit mode
nmcli> nmcli show-secrets yes
There is no point in tracking two separate flags for it. Inside
edit mode, when the user toggles the show-secrets flag, it should
overwrite the command line option.
These two flags can be merged.
The show-secret property is basically a part of the current
configuration, relevant during printing. It will be passed
on to nmc_print(), and hence must be part of NmcConfig.
When generating output data, nmcli iterates over a list of
property-descriptors (nmc_fields_ip4_config), creates an intermediate
array (output_data) and finally prints it.
However, previously both the meta data (nmc_fields_ip4_config) and
the intermediate format use the same type NmcOutputField. This means,
certain fields are relevant to describe a property, and other fields
are output/formatting fields.
Split this up. Now, the meta data is tracked in form of an NMMetaAbstractInfo
lists. This separates the information about properties from intermediate steps
during creation of the output.
Note that currently functions like print_ip4_config() still have all the
knowledge about how to generate the output. That is wrong, instead, the
meta data (NMMetaAbstractInfo) should describe how to create the output
and then all those functions could be replaced. This means, later we want
to add more knowledge to the NMMetaAbstractInfo, so it is important to
keep them separate from NmcOutputField.
We should not violate the global data to track the output data
while it is constructed and printed.
Most of the time, we actually clear the output data anyway --
either before constructing it, or after printing it.
In some cases we didn't, but I think that is a bug. It's really
hard to keep track of this.
The output data should belong to a certain scope and get destroyed
afterwards. Passing it around is very confusing. Don't do that.
The NmCli structure is passed around everywhere and contains all
the state of the program. It is very hard to follow which parts
are used where.
Split out more configuration options to a NmcConfig field. This field
is mostly immutable, and modified at particular places that now can be
easily found.
nmc contains all options and collects output data. It is very hard to
understand what it does. Start splitting it up, and pass arguments along
-- as needed.
Otherwise, changing the structure is difficult because it all depends
on the order (and you don't immdiately see which field is used where).
Also, drop the name_l10n field.
They will be moved out of nmcli as they are generally useful.
Even if they happen to be used only inside nmcli, there should
be a better separation between logic (nmcli) and setting decriptions.
Add an improved way of tracking meta data about settings.
E.g. it is wrong to generate for each property a nmc_property_*_get_*()
function. Instead, there should be a meta data about the property
itself, and a mechanism to retrieve the property.
For now, only do this for NMSettingConnection and keep all the existing
infrastructure in place. Later on all settings shall be moved.
Especially to accomodate NmcOutputField mangles the concept of
setting-meta data, formatting options, and collecting output results.
It's a total hack, that will be need fixing later.
In practice, this should only matter when there are multiple
header files with the same name. That is something we try
to avoid already, by giving headers a distinct name.
When building NetworkManager itself, we clearly want to use
double-quotes for including our own headers.
But we also want to do that in our public headers. For example:
./a.c
#include <stdio.h>
#include <nm-1.h>
void main() {
printf ("INCLUDED %s/nm-2.h\n", SYMB);
}
./1/nm-1.h
#include <nm-2.h>
./1/nm-2.h
#define SYMB "1"
./2/nm-2.h
#define SYMB "2"
$ cc -I./2 -I./1 ./a.c
$ ./a.out
INCLUDED 2/nm-2.h
Exceptions to this are
- headers in "shared/nm-utils" that include <NetworkManager.h>. These
headers are copied into projects and hence used like headers owned by
those projects.
- examples/C
Currently the editor runs in a dedicated thread so that the blocking
call to readline() doesn't stop the processing of D-Bus events in the
main loop. The editor thread can access objects concurrently with the
main thread and this can cause races and crashes.
Remove the editor thread and use the non-blocking readline API.
https://bugzilla.gnome.org/show_bug.cgi?id=732097https://bugzilla.redhat.com/show_bug.cgi?id=1368353
nmcli bash autocompletion leveraged on "nmcli connection edit", "print"
to retrieve the specific properties of a connection. Anyway, the
interactive editor is smart and just prints the used components, so in a
connection where 802.1x is not enabled we had no autocompletion.
Solved adding an "hidden" command "nmcli --complete connection modify"
as suggested in bgo #724860 in order to retrieve ALL the available
properties for use in autocompletion.
Here patch from L.Rintel has been merged to make che --complete option
global to nmcli (first version was local to "connection modify").
https://bugzilla.gnome.org/show_bug.cgi?id=724860https://bugzilla.redhat.com/show_bug.cgi?id=1301226
When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1291785
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
- it controls echoing passwords input on terminal
- it replaces --show-secrets in 'nmcli connection show', which is deprecated now
- it replaces --show-password in 'nmcli device wifi hotspot', which is deprecated now
nmcli -c auto -> colors will only be used when stdout is a terminal
nmcli -c yes -> colors will be enabled unconditionally
nmcli -c no -> colors will be disabled unconditionally
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
libnm mostly used GPtrArrays in its APIs, except that arrays of
connections were usually GSLists. Fix this and make them GPtrArrays
too (and rename nm_client_list_connections() to
nm_client_get_connections() to match everything else).
