Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#24356 - [initscripts] rc.d arguments should have another order

Attached to Project: Arch Linux
Opened by Filipp Andjelo (scorp) - Friday, 20 May 2011, 07:38 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 24 May 2011, 20:44 GMT
Task Type Feature Request
Category Arch Projects
Status Closed
Assigned To Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I've decided to write and commit the bash_completion for newly added /sbin/rc.d script. It works good for default initscript actions like start|stop|restart, but many initscripts have their own actions, like force-restart or reload. Some of the scripts, f.e. network, has even actions with additional arguments, like 'ifup eth0', which would not work with current version of rc.d
Back to the bash_completion, the order of rc.d arguments is not good for it. If you type rc.d and call completion you want to see all of possible actions, for which you have to search all of the initscripts first (it goes very slow). A better solution would be to have a name of the initscript first and than the actions and arguments following. This way you can find very fast which actions are now possible for desired iniscript. You could f.e. even filter-out the start action if the daemon is already started, or the same for the stop.

Since rc.d is very new, it is still not too late to make some changes yet. My suggestion is, rc.d should have following usage:

rc.d [--list|--help] <daemon> <action> ...

Write please if you agree with this solution, then I would commit the patches with a new rc.d script and accordant bash_completion. We should also fix the scripts, which are already using rc.d, if any.

Additional info:
* initscripts 2011.05.2-1
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 24 May 2011, 20:44 GMT
Reason for closing:  Won't implement
Comment by Gaetan Bisson (vesath) - Friday, 20 May 2011, 08:27 GMT
What do you mean by "..." in your proposed usage? Currently, rc.d takes one action, and a list of daemons to which to apply it; this is very handy and the order makes a lot of sense to me.
Comment by Karol Błażewicz (karol) - Friday, 20 May 2011, 08:35 GMT
The current way is certainly useful if you want to do sth with many daemons at once - RPN-style ;P
Comment by Tom Gundersen (tomegun) - Friday, 20 May 2011, 14:30 GMT
While I like the aim of what you are doing with the bash completion, I think we should keep the syntax as it is now. It makes a lot of sense to be able to do "rc.d start daemon1 daemon2 daemon3". If you would like to filter out the already started ones, that would be cool, and if you would like to add all possible actions (and it is possible to do this without killing performance) that would be even cooler. The syntax should not change though. What do you think Seblu?
Comment by Filipp Andjelo (scorp) - Friday, 20 May 2011, 15:53 GMT
Ok, thank you for your replies. I agree, it's very handy to start a list of daemons in time. Even if some scripts don't fit rc.d
As I said /etc/rc.d/network is such one, it has action arguments, f.e. /etc/rc.d/network ifup eth0
If you going to use it with current rc.d it would fail: rc.d ifup eth0 network, since eth0 is unknown daemon.

I can commit bash_completion now for default {start|stop|restart} actions with "already running" lookup. I've already implemented the lookup for possible actions too, but it is killing performance like hell. Pleas take a look.
   rc.d_actions_lookup (0.9 KiB)
   rc.d_no_actions_lookup (0.6 KiB)
Comment by Gaetan Bisson (vesath) - Friday, 20 May 2011, 16:04 GMT
Note: `rc.d 'ifup eth0' network` works for me.
Comment by Sébastien Luttringer (seblu) - Saturday, 21 May 2011, 19:29 GMT
Filipp,

as you can imagine the choice of the arguments was not done at random.

it was inspired by what is happening elsewhere. systemctl and invoke-rc.d.

I also think it's better like that

Loading...