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
The option allows you to specify custom sorting order.
Default order (when no --order is provided) corresponds to -o "active:name:path"
Examples:
nmcli con show -o name
nmcli con show -o +name
- sort connections by name alphabetically
nmcli con show -o -name
- sort connections by name alphabetically in reverse order
mmcli con show -o active:name
- sort connections first by active status, then by name
mmcli con show -o -path
- sort connections by D-Bus path in reverse order
Looks more like 5, not 7, unless a particular mode is selected:
There are 7 optional arguments for 'bond' connection type.
Do you want to provide them? (yes/no) [yes]
Bonding mode [balance-rr]:
Bonding monitoring mode (miimon/arp) [miimon]:
Bonding miimon [100]:
Bonding downdelay [0]:
Bonding updelay [0]:
Previously we would only complete connections given by ID.
The following would work:
$ nmcli connection modify id <ID> <TAB>
$ nmcli connection modify <ID> <TAB>
$ nmcli connection modify uuid <UUID> <TAB>
but the following would not work:
$ nmcli connection modify <UUID> <TAB>
Error: DEADCODE (CWE-561): [#def3]
NetworkManager-0.9.11.0/clients/cli/utils.c:488: cond_notnull: Condition "input", taking true branch. Now the value of "input" is not "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: notnull: At condition "input", the value of "input" cannot be "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_condition: The condition "input" must be true.
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_line: Execution cannot reach the expression """" inside this statement: "g_set_error(error, 1U, 0, d...".
nmcli currently does not wait for the connection to fully deactivate, which
can take some time due to dispatcher scripts or cleanup operations like
DCB. Change it to wait until the connection is deactivated, or until
a short timeout has expired. The user can adjust the timeout with
"--wait" if they want.
https://bugzilla.gnome.org/show_bug.cgi?id=740775https://bugzilla.redhat.com/show_bug.cgi?id=1168383
set_connection_path() is almost always called right before enable(),
and it's unclear why it would be called anywhere else. So just
merge the two methods.
nm_secret_agent_simple_*() functions should take an
NMSecretAgentSimple, not an NMSecretAgent.
The type macros were incorrectly validating against
NM_TYPE_SECRET_AGENT rather than NM_TYPE_SECRET_AGENT_SIMPLE.
If we're activating the device without knowing the connection in advance, defer
servicing the requests for the secrets until we set the path.
[lkundrak@fedora20-2 ~]$ nmcli --ask c ifname wlan0
(process:18405): libnm-CRITICAL **: nm_object_get_path: assertion 'NM_IS_OBJECT (object)' failed
Error: Connection activation failed: The device has no connections available.
[lkundrak@fedora20-2 ~]$
The signals might be delivered in no particular order and we need to wait for
the device to reach stable state (whether it's successfully conntected or not)
as well as the active connection to leave ACTIVATING state.
https://bugzilla.gnome.org/show_bug.cgi?id=740320
Now that nm-setting-docs.xml is more D-Bus-specific, it's less
appropriate for nmcli's internal documentation. So generate a second
copy of the docs without using the overrides file, and use that one
for nmcli's documentation.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
The device status alone is uninteresting as its changes can be due to
deactivation of previously active connection. We should monitor the
active connection changes instead of device state changes.
However the device state changes is still interesting, as it contains the
reason for the change, let's just ignore them while the connection is
activating.
Lastly, we need to handle failures as well. It should be noted that it's
not sufficient to deal with NM_DEVICE_STATE_FAILED as the device will
quickly draverse to NM_DEVICE_STATE_DISCONNECTED. This happens in case of
a failure due to NM_DEVICE_STATE_REASON_NO_SECRETS as soon as the server
makes sure it won't reconnect automatically.
