monitor-connection-files was deprecated and disabled by default for a long
time. In the meantime, it has no effect at all.
Remove references from the manual pages.
A quick overview of the currently connected Wi-Fi network, including
credentials. Comes handy if someone wants to connect more devices to
their Hotspot or the same network as they are connected to.
Try to locate an existing connection before creating a new one when
handling "nmcli device wifi connect". This allows WPA-Enterprise
networks to be activated this way, consistent with the comment that this
command is equivalent to clicking on an SSID in a GUI client.
Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.
Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.
Manually disconnecting a profile of course blocks autoconnect of the
same profile. Otherwise, the profile would likely re-activate right
away, which is clearly against the users intention. If the users just
want to re-activate the profile, they should issue `nmcli connection up`
instead, with does a full down and up cycle.
This is more interesting for profiles that have 'connection.multi-connect'
set to 'multiple'. Would you expect that manually deactivating such a
profile blocks autoconnect of the profile on all devices? Maybe
yes, maybe not. Currently that is indeed the case and autoconnect gets
blocked regardless of multi-connect.
Already since 1.0.0 release and commit "3784678177 cli: create a connection
if none exist in 'nmcli dev connect' (rh #1113941)", device-connect can
also create a profile.
That is useful, in particular as opposed to
$ nmcli connection up ifname "$DEVICE"
which wouldn't create a profile (ever).
Document it.
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.
nmcli has a heuristic when setting the team-config to accepting both
a filename or the plain json text.
Add support for two schemes "file://" and "json://" to explicitly
determine whether to read from file or from json.
Also, no longer silently ignore an all-whitespace word. That is an
error (unless you have a file named " ").
Also, no longer replace newlines with space. Don't mangle the input
text at all.
It allows us to clean up the nmcli "c add" section considerably.
We list the old-fashioned aliases in a separate section that applies to both
"nmcli c add" and "nmcli c modify".
The section is now nicely cross-linked with nm-settings in HTML
rendering.
This improves the HTML rendering.
But it also causes a lot of non-resolvable linkends warning when rendering a
separate manual pages into roff/mman. The messages are harmless, but still
a bit ugly.
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
