> -----Original Message----- > From: linux-btrfs-ow...@vger.kernel.org <linux-btrfs- > ow...@vger.kernel.org> On Behalf Of Hugo Mills > Sent: Monday, 18 June 2018 9:44 PM > To: dste...@suse.cz; Qu Wenruo <quwenruo.bt...@gmx.com>; linux- > bt...@vger.kernel.org > Subject: Re: About more loose parameter sequence requirement > > On Mon, Jun 18, 2018 at 01:34:32PM +0200, David Sterba wrote: > > On Thu, Jun 14, 2018 at 03:17:45PM +0800, Qu Wenruo wrote: > > > I understand that btrfs-progs introduced restrict parameter/option > > > order to distinguish global and sub-command parameter/option. > > > > > > However it's really annoying if one just want to append some new > > > options to previous command: > > > > > > E.g. > > > # btrfs check /dev/data/btrfs > > > # !! --check-data-csum > > > > > > The last command will fail as current btrfs-progs doesn't allow any > > > option after parameter. > > > > > > > > > Despite the requirement to distinguish global and subcommand > > > option/parameter, is there any other requirement for such restrict > > > option-first-parameter-last policy? > > > > I'd say that it's a common and recommended pattern. Getopt is able to > > reorder the parameters so mixed options and non-options are accepted, > > unless POSIXLY_CORRECT (see man getopt(3)) is not set. With the more > > strict requirement, 'btrfs' option parser works the same regardless of > > that. > > I got bitten by this the other day. I put an option flag at the end of the > line, > after the mountpoint, and it refused to work. > > I would definitely prefer it if it parsed options in any position. (Or at > least, > any position after the group/command parameters).
Same with me - I do it all the time. I type the arguments as I think of them, which is usually back-to-front of what is required. Eg. Btrfs check this mountpoint, oh yeah, and use this specific option = fail. Arrow arrow arrow arrow arrow.... Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
