Because in 'nmcli connection add' the argument keywords are not the exact property names (they are long and ugly sometimes). They are some selected most often used parameters (somebody should maybe review them whether we should and/remove some).

'nmcli connection modify' is a general command that allows modification of arbitrary property.

'nmcli connection modify' can be used as a complementary command to 'add' when some special change is required.

'modify' accepts shortcuts both for setting and property names (man nm-settings)
You can e.g. do:
$ nmcli -p con add type ethernet con-name drat
$ nmcli con modify drat eth.mtu 1400

I actually think that both 'add' and 'modify' should accept exact long names (e.g. ethernet.mac-address) and shortcuts (e.g. mac).

Upon request for more information on IRC:

Currently there are two ways to express connection properties with nmcli.

1) Advanced. Full property name and value as per the library/dbus API

Example: ethernet.mac-address 00:11:22:33:44:55

This way is universal and allows you to specify *any* property, provided that nmcli knows how to parse it and send it to NetworkManager. Therefore it exposes the whole connection setup via 'nmcli'.

2) Simple. Keywords for selected property names

Example: mac 00:11:22:33:44:55

This way is more user friendly and less verbose. It allows you to specify most common settings in a sensible manner.

****

Currently, #1 is used for 'nmcli connection modify' and #2 is used for 'nmcli connection add', which is cool. The basic idea is that when creating a connection, one usually doesn't need the full power of #2 and that one could still use modify to amend the configuration.

So, what is my proposal? My proposal is to keep the above possibilities and still allow #1 for 'modify' and #2 for 'add' but *also* allow #1 for 'add' and '#2' for modify for those who would like to use it.

Therefore I'm *not* inventing an new syntax and I'm *not* asking to remove any of the current possibilities, just merging the power of 'add' and 'modify'. I believe that in the long term this will make our lives (and the administrator lives) much easier.

Example:

The following two commands would be equivalent (provided that we use short 'name', not 'con-name'):

nmcli connection add \
    type ethernet \
    name Ethernet \
    mac 00:11:22:33:44:55 \
    mtu 1492

nmcli connection add \
    connection.type ethernet \
    connection.name Ethernet \
    ethernet.mac-address 00:11:22:33:44:55 \
    ethernet.mtu 1492

I further propose that the documentation and examples always prefer the short syntax for friendly user experience and note that the full syntax is supported.

I just stumbled upon one issue and that is that 'nmcli modify' only supports a single property to be modified at a time and that it works for resetting when value is not provided. I believe this should be solved, too.

Known foreign syntax: Mikrotik RouterOS is praised for its great command-line capabilities. It uses 'set option1=value1 option2=value2' and 'unset option1 option2 ...'.

It could be 'modify/reset', 'set/reset', 'set/unset' or whatever else. The only drawback is that you still can't perform modifying one option and resetting another in a single command. We could either live with it, or find a better solution.

Would for example an empty string work instead of a missing value? Is that a good idea at all? I personally could live with resetting as a separate operation or maybe even without it (explicit value setting being the alternative).

My goal in this RFE was to give nmcli connection add/modify the full power of library/dbus connection adding/modification interface while keeping the simplicity that jklimes put into the 'nmcli connection add' interface.

I think it's probably a good idea to unify the add/modify commands like you describe, would be neat to have both support the short + full syntax.  It should probably be a goal though, rather than some kind of short-term blocker.

NM bugzilla reorganization... sorry for the bug spam.

Possible duplicate: bug 740749

*** Bug 743436 has been marked as a duplicate of this bug. ***

will be implemented by bug 750590

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.

In master you can now "nmcli c add ... -- <property> <value> ..."

Thank you!