With a /dev/... argument that is a valid device the message changes to:

# vgcreate /dev/sda
  /dev/sda: already exists in filesystem
  Run `vgcreate --help' for more information.

(i.e the single argument is being taken for a VG name).

It's trivial to check this directly in vgcreate.c, changing the above cases to:

# lvm vgcreate 
  Please provide volume group name and physical volumes
  Run `vgcreate --help' for more information.

# lvm vgcreate qux
  Please provide physical volumes for new volume group qux
  Run `vgcreate --help' for more information.

# lvm vgcreate /dev/sda
  Volume group name expected before physical volume arguments
  Run `vgcreate --help' for more information.

Before I commit this though I'll take a look to see if it doesn't make sense to push this down into the existing validation routines (from vgcreate()).

Upstream commit is actually causing regression:

https://www.redhat.com/archives/lvm-devel/2016-July/msg00200.html

# vgcreate /dev/vg /dev/sda1 /dev/sdb1  

is valid syntax.

User is free to use or not use "/dev" prefix (lvm.conf defined) with all lvm2 commands. Obviously  'vgname'  may 'collide' with some other existing device name and such vgname can't be then used (aka  'vgcreate sda'  is bad idea).

But this is well known limitation - even thought some users would like to see this limit to be dropped and lvm2 would not 'create' any /dev/vgname/lvname links and just  /dev/mapper/vgname-lvname....

There is an 'interesting' problem how to deal with 'globally' supported 'envvar'   LVM_VG_NAME  (man lvm).

Regression.  Old code gave:

  Please enter a physical volume path.

With the new command definitions all three cases are caught by the generic required argument/option checking message:

# vgcreate
  Incorrect syntax. Run 'vgcreate --help' for more information.
# vgcreate foo
  Incorrect syntax. Run 'vgcreate --help' for more information.
# vgcreate /dev/foo
  Incorrect syntax. Run 'vgcreate --help' for more information.

Spoke with Dave and although this is a change of behaviour from previous versions, the current behaviour is not incorrect: it correctly points the user to the too --help output which would correct the command misuse.

To address this and cause it to behave as previously, the simplest way that I could see would involve adding dummy command definitions simply to allow the dummy command to output a more exact error message - this seems a fair amount of hack just to slavishly match the original messages.

In the case of vgcreate (unlike many of the new command definitions) there is only one valid syntax accepted (modulo the different ways of expressing the volume group name): Dave suggests that this could be used with the existing "nearest similar syntax" logic to output a more exact message in these single syntax command cases.

This gives us a clear route to improve this in the future without resorting to short term kludges.

I thought I'd seen another commit for this via mail, but didn't spot it when I went to look a moment ago:

commit 86b9c23dbe4a5033eea6667c0274655e7c0c8e68
Author: David Teigland <teigland>
Date:   Thu Apr 27 14:21:01 2017 -0500

    commands: improve syntax suggestion when no command is found
    
    The logic for suggesting the nearest valid command syntax
    was missing the simplest case.  If a command has only one
    valid syntax, that is the one we should suggest.  (We were
    suggesting nothing in this case.)

With this commit the three prior examples now output the expected usage:

# lvm vgcreate
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

# lvm vgcreate foo
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

# lvm vgcreate /dev/foo
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

Marking verified based on the new behavior expected outlined in comment #10.

3.10.0-660.el7.x86_64

lvm2-2.02.171-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
lvm2-libs-2.02.171-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
lvm2-cluster-2.02.171-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
device-mapper-1.02.140-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
device-mapper-libs-1.02.140-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
device-mapper-event-1.02.140-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
device-mapper-event-libs-1.02.140-1.el7    BUILT: Wed May  3 07:05:13 CDT 2017
device-mapper-persistent-data-0.7.0-0.1.rc6.el7    BUILT: Mon Mar 27 10:15:46 CDT 2017



[root@host-126 ~]# pvcreate
  No command with matching syntax recognised.  Run 'pvcreate --help' for more information.
  Correct command syntax is:
  pvcreate PV ...

[root@host-126 ~]# pvcreate foo
  Device foo not found (or ignored by filtering).
[root@host-126 ~]# vgcreate
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

[root@host-126 ~]# vgcreate foo
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

[root@host-126 ~]# vgcreate /dev/foo
  No command with matching syntax recognised.  Run 'vgcreate --help' for more information.
  Correct command syntax is:
  vgcreate VG_new PV ...

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2222