| 1 |
On Wed, 18 Jul 2012 15:58:18 -0400 |
| 2 |
Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
|
| 4 |
> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge <peter@×××××.se> wrote: |
| 5 |
> > William Hubbs wrote: |
| 6 |
> >> /etc/init.d/foo stop start |
| 7 |
> >> |
| 8 |
> >> would no longer work the way you might expect because there would |
| 9 |
> >> be no way to tell whether start is a command or an argument to |
| 10 |
> >> stop. |
| 11 |
> >> |
| 12 |
> >> What are your thoughts about this change? |
| 13 |
> > |
| 14 |
> > /etc/init.d/foo stop start |
| 15 |
> > |
| 16 |
> > along with all other commands can work like before. |
| 17 |
> > |
| 18 |
> > /etc/init.d/foo stop -- start |
| 19 |
> > |
| 20 |
> > can pass start as an argument to the stop command. |
| 21 |
> |
| 22 |
> I like this approach, because its use of -- continues expected |
| 23 |
> commandline parsing behaviors from other commands, making it |
| 24 |
> intuitive. |
| 25 |
|
| 26 |
No, it's not intuitive. It's rather counter-intuitive. |
| 27 |
|
| 28 |
GNU command line parsers use '--' to separate options from random |
| 29 |
arguments. It's '--' because options start with '-'. For arguments |
| 30 |
starting with any other character, GNU option parsers treat them |
| 31 |
equally before and after '--'. |
| 32 |
|
| 33 |
And yes, some tools actually use '--' to separate arguments to the tool |
| 34 |
itself from arguments which are passed to some other tool. This is not |
| 35 |
very intuitive as well, and I really prefer having |
| 36 |
'--subtool-one-arguments "--foo --bar"' instead, with embedded |
| 37 |
splitting logic. Of course, this is harder to implement. |
| 38 |
|
| 39 |
-- |
| 40 |
Best regards, |
| 41 |
Michał Górny |
Archives