rfc: openrc init scripts taking command line arguments
 

All,

I have received a request to allow OpenRC's init scripts to take command
line arguments [1]. As noted on the bug, there are some advantages to
this, but implementing it would have to break backward compatibility,
for example:

/etc/init.d/foo stop start

would no longer work the way you might expect because there would be no
way to tell whether start is a command or an argument to stop.

What are your thoughts about this change?

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=427144

rfc: openrc init scripts taking command line arguments
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/07/12 03:49 PM, Peter Stuge wrote:
> William Hubbs wrote:
>> /etc/init.d/foo stop start
>>
>> would no longer work the way you might expect because there would
>> be no way to tell whether start is a command or an argument to
>> stop.
>>
>> What are your thoughts about this change?
>
> /etc/init.d/foo stop start
>
> along with all other commands can work like before.
>
> /etc/init.d/foo stop -- start
>
> can pass start as an argument to the stop command.
>
>
> //Peter


I posted a response about this to the bug, but I don't see why, given
that all 'commands' are predefined anyways, the commandline couldn't
be parsed and split between commands..


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHFCkACgkQ2ugaI38ACPANyAEAnF7ngFvy/lcHPo0A4vEyN0zS
5QFTRmOiFG+GS8cRkyEBAL3ABkRD9M44sVHGs52ioctce+tsBS fLU9bawmBQuuJf
=dzvV
-----END PGP SIGNATURE-----

rfc: openrc init scripts taking command line arguments
 

On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge <peter@stuge.se> wrote:
> William Hubbs wrote:
>> /etc/init.d/foo stop start
>>
>> would no longer work the way you might expect because there would be no
>> way to tell whether start is a command or an argument to stop.
>>
>> What are your thoughts about this change?
>
> /etc/init.d/foo stop start
>
> along with all other commands can work like before.
>
> /etc/init.d/foo stop -- start
>
> can pass start as an argument to the stop command.

I like this approach, because its use of -- continues expected
commandline parsing behaviors from other commands, making it
intuitive.

I.e.

touch -- -an-ugly-filename
ls -l -- -an-ugly-filename
rm -- -an-ugly-filename

--
:wq

rfc: openrc init scripts taking command line arguments
 

On Wed, 18 Jul 2012 15:58:18 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge <peter@stuge.se> wrote:
> > William Hubbs wrote:
> >> /etc/init.d/foo stop start
> >>
> >> would no longer work the way you might expect because there would
> >> be no way to tell whether start is a command or an argument to
> >> stop.
> >>
> >> What are your thoughts about this change?
> >
> > /etc/init.d/foo stop start
> >
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
>
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.

No, it's not intuitive. It's rather counter-intuitive.

GNU command line parsers use '--' to separate options from random
arguments. It's '--' because options start with '-'. For arguments
starting with any other character, GNU option parsers treat them
equally before and after '--'.

And yes, some tools actually use '--' to separate arguments to the tool
itself from arguments which are passed to some other tool. This is not
very intuitive as well, and I really prefer having
'--subtool-one-arguments "--foo --bar"' instead, with embedded
splitting logic. Of course, this is harder to implement.

--
Best regards,
Michał Górny

rfc: openrc init scripts taking command line arguments
 

On 18-07-2012 15:58:18 -0400, Michael Mol wrote:
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
>
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.
>
> I.e.
>
> touch -- -an-ugly-filename
> ls -l -- -an-ugly-filename
> rm -- -an-ugly-filename

yeah, but it means something like "don't treat the '-' as anything
special any more", so if you don't have something starting with -, you
don't need --. Hence, following your "expected" behaviour argument,

/etc/init.d/foo stop start

would do the same as

/etc/init.d/foo stop -- start

or

/etc/init.d/foo -- stop start


Perhaps, one better makes it explicit, inspired by gdb

/etc/init.d/foo stop --args aggressive-kill=yes
(and when using --args, I'd probably disallow using multiple commands to
keep it clear what's going on)


Fabian

--
Fabian Groffen
Gentoo on a different level

rfc: openrc init scripts taking command line arguments
 

On Wed, Jul 18, 2012 at 03:58:18PM -0400, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:49 PM, Peter Stuge <peter@stuge.se> wrote:
> > William Hubbs wrote:
> >> /etc/init.d/foo stop start
> >>
> >> would no longer work the way you might expect because there would be no
> >> way to tell whether start is a command or an argument to stop.
> >>
> >> What are your thoughts about this change?
> >
> > /etc/init.d/foo stop start
> >
> > along with all other commands can work like before.
> >
> > /etc/init.d/foo stop -- start
> >
> > can pass start as an argument to the stop command.
>
> I like this approach, because its use of -- continues expected
> commandline parsing behaviors from other commands, making it
> intuitive.
>
> I.e.
>
> touch -- -an-ugly-filename
> ls -l -- -an-ugly-filename
> rm -- -an-ugly-filename

Theis still breaks backward compatibility though, e.g.

/etc/init.d/foo command1 -- arg1 arg2 command2

has issues.

The other approach, which is on the bug, still has this issue, e.g.

/etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3 arg5

gets pretty ugly pretty quick. which arguments go with which commands is
subject to interpretation.

William

rfc: openrc init scripts taking command line arguments
 

On Wed, 18 Jul 2012 14:41:52 -0500
William Hubbs <williamh@gentoo.org> wrote:

> I have received a request to allow OpenRC's init scripts to take
> command line arguments [1]. As noted on the bug, there are some
> advantages to this, but implementing it would have to break backward
> compatibility, for example:
>
> /etc/init.d/foo stop start
>
> would no longer work the way you might expect because there would be
> no way to tell whether start is a command or an argument to stop.
>
> What are your thoughts about this change?

As I see that the discussion is now in two places, I'd shortly repeat
what I said on the bug.

First of all, I believe that you are focusing too much on your proposed
solution and too little on the actual problem. For example, in this
mail the actual problem is just linked as a footnote. This means that
we are starting to discuss the solution not knowing what it will be for.

As I mentioned there, I see that the problem covers a wide case of
script 'multiplexing', 'templates' or 'virtual script generators',
however you want to call it. I don't really think command-line
arguments can handle that. They will just add complexity to the issue.

For example, how would you consider the state of such a script? Will
every status check require passing additional arguments? Will every
script using this technique be required to re-invent the whole
multiplexing concept?

--
Best regards,
Michał Górny

rfc: openrc init scripts taking command line arguments
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/07/12 04:09 PM, William Hubbs wrote:
>
> The other approach, which is on the bug, still has this issue,
> e.g.
>
> /etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3
> arg5
>
> gets pretty ugly pretty quick. which arguments go with which
> commands is subject to interpretation.

..i don't see how...? anything to the right of [command] but before
{[other-command],$END} is an argument to [command] ...

ie, the above would roll out to:

/etc/init.d/foo command1 arg1 arg2 &&
/etc/init.d/foo command2 arg3 arg4 &&
/etc/init.d/foo command3 arg5

(assuming subsequent commands do not execute if the previous one fails
now, which tbh I have no idea about)

It's not the most pretty syntax ever, but given i doubt it will be
humans running such a commandline I don't see the issue with this..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHGZUACgkQ2ugaI38ACPCXNAD8DR8qHFOQnG Ct2W+sOXYJDsXu
H6pnnFt09ssbuKjKHZwA/2pZxnGnXJTWGVdPySoIsJtr8Pe6Za9yeL4yQ0WHPocr
=G3H9
-----END PGP SIGNATURE-----

rfc: openrc init scripts taking command line arguments
 

Folks,

let's move all of the discussion of this to the bug if possible so that
it is all in one place.

Thanks,

William

rfc: openrc init scripts taking command line arguments
 

On Wed, 18 Jul 2012 23:03:14 +0200
Peter Stuge <peter@stuge.se> wrote:

> William Hubbs wrote:
> > let's move all of the discussion of this to the bug if possible so
> > that it is all in one place.
>
> That's fine and probably good.
>
> Note that you were the one inviting email discussion about the
> change. I guess you wanted rather to focus on the question if
> breaking compatibility was cool or not.
>
> Anything web is *way* too inconvenient for me to participate without
> strong interest. That may be a good thing. Anyway I've mentally
> abandoned init script including openrc long ago. :)
>
> systemd is the future, and truly a leap ahead for systems world wide.

No, it's not. But it's a step ahead.

--
Best regards,
Michał Górny