After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693201 - don't include white space in connection names by default; don't prepend connection type to connection name
don't include white space in connection names by default; don't prepend conne...
Status: RESOLVED WONTFIX
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-02-05 14:10 UTC by David Jaša
Modified: 2014-02-05 00:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Jaša 2013-02-05 14:10:42 UTC
don't include white space in connection names by default; don't prepend connection type to connection name

As NM starts being usable on CLI, white space in identificators starts being a nuisance. In addition, prepending connection type (Auto/System/Bridge/...) to connection name makes commands unnecessarily verbose and all UIs I know do distinguish connection types sufficiently well without it.
Comment 1 Pavel Simerda 2013-02-05 15:21:53 UTC
Sounds reasonable.
Comment 2 Pavel Simerda 2013-07-07 20:54:33 UTC
I've heard about changes in this direction. I'm curious about the current status in master and whether this was generally accepted or the GUIs are expected to be an exception.
Comment 3 Dan Williams 2013-08-13 21:46:19 UTC
I actually don't agree with this.  The names are mean to be human-readable, "friendly" names that can be shown in any kind of UI and are nice to look at.  That implies things like spaces, non-shell characters, etc.  If the name gets transformed into a filename, then the settings plugin should ensure that it's somewhat type-able by replacing whitespace and special characters with things the filesystem likes.

On the CLI end, nmcli should just tab-complete connection names.  No, we shouldn't name things like "My Fancy Wired Connection" by default, because that is just rediculous to type, but if we name things like "bond0" or "bridge0" or "bridge0 slave1", and have tab completion, that should be sufficient.
Comment 4 Pavel Simerda 2013-08-13 21:51:46 UTC
(In reply to comment #3)
> I actually don't agree with this.
> ...
> No, we
> shouldn't name things like "My Fancy Wired Connection" by default, because that
> is just rediculous to type, but if we name things like "bond0" or "bridge0" or
> "bridge0 slave1", and have tab completion, that should be sufficient.

So now I'm not sure if you're more for "Fancy Names for the Pleasure of Human Eyes" or for bridge0 and similar stuff... ;).
Comment 5 Pavel Simerda 2013-10-01 18:21:17 UTC
Any progress towards either FIXED or WONTFIX?
Comment 6 Jiri Klimes 2013-10-02 17:52:58 UTC
I vote for WONTFIX/NOTABUG now. The report is too general and vague.

nmcli doesn't put spaces to self-generated names.
But there is not only nmcli here. Connections can be created via nm-connection-editor, nm-applet, and many many other tools. And they can choose arbitrary names.
NM itself create connections, e.g. the default ones and they actually contain spaces ("Wired connection 1"). That could be changed perhaps if there is a better name. However, that's not a common situation.
Comment 7 Pavel Simerda 2013-10-04 10:23:06 UTC
(In reply to comment #6)
> The report is too general and vague.

I don't agree here. The bug report is about *never* autogenerating any connection names including white space, which is a pretty well-defined request. 

> nmcli doesn't put spaces to self-generated names.
> But there is not only nmcli here.

I think the primary concern here is about NetworkManager daemon (pavlix/runtime branch, at the least), nmcli and similar. In 'pavlix/runtime', we now generate names *with* whitespace as requested by Dan Williams. If 'nmcli' generates names without white space, then I'm curious why they don't use the same format.

> Connections can be created via nm-connection-editor,

That one is more or less part of the NetworkManager project and we could possibly decide to avoid whitespace there.

> nm-applet, and many many other tools.

Same as above.

> And they can choose arbitrary names.

Where arbitrary is one or more formats that are deliberately chosen by the developers. For tools developed within the project, we can define the policy here, for tools developed outside the project, we can at least issue a recommendation.

> NM itself create connections, e.g. the default ones and they actually contain
> spaces ("Wired connection 1").

Exactly. That's up to developer's decision.

> That could be changed perhaps if there is a
> better name.

You'd have to first decide whether whitespace is used for generated connection names.

> However, that's not a common situation.

How so?

I think this bug report is mostly about a decision whether we want to have whitespace in generated names or not. Ideally with reasons behind the decision. Then we can make sure the generated names match the decision.
Comment 8 Thomas Haller 2013-10-04 12:04:16 UTC
As Dan Williams said, I also think that these are friendly-names for the users. So they should contain special characters, including whitespace, non-ascii characters and translation(!).

If people care about it (because they use the command line) they are advanced users anyway and can easily change these names.

IMO, that client applications generate different names than NetworkManager, is fine. Especially, because they might have a different LOCALE setting. Of course, we should strive for uniformity and if there is a particular place where this differs for no good reason it should be adjusted.


nmcli bash completion does not work nicely with special characters. I opened bug #709426 for that.
Comment 9 Pavel Simerda 2014-02-04 21:11:51 UTC
With the given information, I nominate this bug for WONTFIX.
Comment 10 Thomas Haller 2014-02-05 00:03:06 UTC
(In reply to comment #9)
> With the given information, I nominate this bug for WONTFIX.

I agree