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]:
Program received signal SIGSEGV, Segmentation fault.
0x000000000041b3e5 in nmt_page_dsl_constructed (object=0x7fffec0228c0 [NmtPageDsl]) at nmt-page-dsl.c:109
109 priv->ethernet_page = nmt_page_ethernet_new (conn, nmt_editor_page_device_get_device_entry (NMT_EDITOR_PAGE_DEVICE (dsl)));
Missing separate debuginfos, use: debuginfo-install libffi-3.0.10-3.fc18.x86_64 newt-0.52.15-1.fc19.x86_64
(gdb) bt
#0 0x000000000041b3e5 in nmt_page_dsl_constructed (object=0x7fffec0228c0 [NmtPageDsl]) at nmt-page-dsl.c:109
#1 0x0000003e9ac161e3 in g_object_newv (object_type=1, object_type@entry=16203872, n_parameters=n_parameters@entry=2, parameters=parameters@entry=0xf74350)
at gobject.c:1741
#2 0x0000003e9ac16560 in g_object_new_valist (object_type=object_type@entry=16203872, first_property_name=first_property_name@entry=0x42e524 "connection",
var_args=var_args@entry=0x7fffffffcef8) at gobject.c:1830
#3 0x0000003e9ac16894 in g_object_new (object_type=16203872, first_property_name=first_property_name@entry=0x42e524 "connection") at gobject.c:1545
#4 0x000000000041b504 in nmt_page_dsl_new (conn=<optimized out>, deventry=deventry@entry=0x974690 [NmtDeviceEntry]) at nmt-page-dsl.c:47
#5 0x000000000041808e in nmt_editor_constructed (object=<optimized out>) at nmt-editor.c:355
#6 0x0000003e9ac161e3 in g_object_newv (object_type=1, object_type@entry=16174256, n_parameters=n_parameters@entry=4, parameters=parameters@entry=0xf6cec0)
at gobject.c:1741
...
(gdb) p priv
$1 = (NmtPageDslPrivate *) 0x0
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...".
We wait for each deletion to complete, so the connections were getting
removed from the connections array as we edited it (unlike with the
old transfer-container GSList-based code). Fix this by copying the
slaves out into their own list first.
Coverity: Defect type: SWAPPED_ARGUMENTS
clients/tui/newt/nmt-newt-section.c:328: swapped_arguments: The positions of arguments in the call to "nmt_newt_widget_size_request" do not match the ordering of the parameters: * "&border_height" is passed to "width" * "&border_width" is passed to "height"
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.
nmt-editor.c: In function ‘nmt_editor_constructed’:
nmt-editor.c:365:2: error: ‘page’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
add_sections_for_page (editor, grid, page);
^
If an NmtEditorGrid row has a widget, but no label, then we make the
widget span both the label and widget columns. But previously we
weren't doing the same for rows with labels but no widgets. (In fact,
we didn't even allow rows with no widgets; label-only rows had to
specify dummy widgets.)
Fix it so that labels will span into an empty widget column. (This
ensures that a long section name won't force the entire grid to have
an overwide label column).
Also, in both the "no label" and "no widget" cases, still show the
"extra" column if it's present.
Rather than having NmtEditor need to know that DSL requires a DSL
page, and Ethernet page, and a PPP page, just have the DSL page itself
return multiple sections.
Instead of having NmtEditorPage be a widget itself, have it just be an
object that returns a list of NmtEditorSections, where
NmtEditorSection is a subclass of NmtNewtSection.
(This will be important when adding VPN pages, which will be split up
into multiple sections, but with the different sections needing to
cooperate on updating the NMSettingVpn. This reorganization lets us
have an NMPageVpn containing multiple sections, with the NMPageVpn
object handling the coordination between the sections.)
All page types except NmtPageMain are displayed as collapsible
sections. NmtPageMain behaved quite differently from everything else.
So merge it into its container, NmtEditor.
Rename NmtPageDevice to NmtEditorPageDevice, and rename NmtPageGrid to
NmtEditorGrid.
Now all types with names starting with "NmtPage" are instantiable page
types, not abstract classes or low-level widgets.
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
We were refreshing the list when the set of available devices changed,
or the set of active connections changed, but not when the set of
available connections changed.
https://bugzilla.gnome.org/show_bug.cgi?id=740333
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.
