| 1 |
On Wed, 18 Jul 2012 14:41:52 -0500 |
| 2 |
William Hubbs <williamh@g.o> wrote: |
| 3 |
|
| 4 |
> I have received a request to allow OpenRC's init scripts to take |
| 5 |
> command line arguments [1]. As noted on the bug, there are some |
| 6 |
> advantages to this, but implementing it would have to break backward |
| 7 |
> compatibility, for example: |
| 8 |
> |
| 9 |
> /etc/init.d/foo stop start |
| 10 |
> |
| 11 |
> would no longer work the way you might expect because there would be |
| 12 |
> no way to tell whether start is a command or an argument to stop. |
| 13 |
> |
| 14 |
> What are your thoughts about this change? |
| 15 |
|
| 16 |
As I see that the discussion is now in two places, I'd shortly repeat |
| 17 |
what I said on the bug. |
| 18 |
|
| 19 |
First of all, I believe that you are focusing too much on your proposed |
| 20 |
solution and too little on the actual problem. For example, in this |
| 21 |
mail the actual problem is just linked as a footnote. This means that |
| 22 |
we are starting to discuss the solution not knowing what it will be for. |
| 23 |
|
| 24 |
As I mentioned there, I see that the problem covers a wide case of |
| 25 |
script 'multiplexing', 'templates' or 'virtual script generators', |
| 26 |
however you want to call it. I don't really think command-line |
| 27 |
arguments can handle that. They will just add complexity to the issue. |
| 28 |
|
| 29 |
For example, how would you consider the state of such a script? Will |
| 30 |
every status check require passing additional arguments? Will every |
| 31 |
script using this technique be required to re-invent the whole |
| 32 |
multiplexing concept? |
| 33 |
|
| 34 |
-- |
| 35 |
Best regards, |
| 36 |
Michał Górny |
Archives