[arch-projects] [INITSCRIPTS][PATCH] rc.d: list [started|stopped|auto|noauto|daemon]

[Lukas Fleischer]

On Tue, Aug 23, 2011 at 10:36:27AM +0200, Seblu wrote:
> On Tue, Aug 23, 2011 at 10:01 AM, Lukas Fleischer
> <archlinux at cryptocrack.de> wrote:
> >
> > Hm, wouldn't that mean we would never be able to explicitly list daemons
> > called "started", "stopped", "auto" and "noauto"? I know that this is
> > nit-picking, but I would prefer another argument "daemons" or "all",
> > followed by a list of daemons, so we could use:
> >
> > * `rc.d list daemons` to list all daemons (or just `rc.d list`).
> > * `rc.d list started` to list all running daemons.
> > * `rc.d list daemons sshd gpm` to list specific daemons only.
> > * `rc.d list started sshd gpm` to list specific running daemons only.
> Bof. I prefer something like rc.d list \auto to list auto deaemons.
> It's less complicated.

Uh? :) Not sure if you misunderstood me, `rc.d list auto`, as well as
`rc.d list noauto` and `rc.d list stopped` will still work with what I
suggested. The only difference to your proposal is that there is a
separate keyword to use if you want to list specific daemons.

You actually already support listing specific running daemons via `rc.d
list started sshd gpm`, specific auto daemons via `rc.d list auto sshd
gpm` etc., so having another keyword to list *all* daemons felt like the
right thing to do here. Anyway, this is/was just a thought.

> 
> >
> > Also, you should not indent mixing tabs and spaces. This breaks
> > indentation for everyone using a different tab width.
> I checked but i don't see mixing tabs and space.
> The only point where i use space for indentation is in string of
> usage. Where it's correct to ensure a proper display.
> 
> Can you be more precise.

Not talking about the actual indentation itself, but about the mixing of
spaces and tabs between the matching patterns in the case statement and
the code.

> 
> >
> >> +             esac
> >> +     done
> >> +     # if no daemon are specified take all executable file in /etc/rc.d
> >> +     if ! [[ $daemons ]]; then
> >
> > "[[ ! $daemons ]]". Or any reason to do the negation outside the
> > conditional expression here?
> Reason to do it inside ?

Only a matter of clarity and coding style. If we want to check for a
false value explicitly, having the negation inside the conditional
expression makes things clearer. "! [[ $daemons ]]" looks like "Check if
$daemons is defined. If that is not true, do [...]". "[[ ! $daemons ]]"
looks like "If $daemons is undefined, do [...]". If you don't feel like
doing it or if you always use negations outside the conditional brackets
in initscripts, just keep it :)

> 
> >
> >> +             cd /etc/rc.d
> >> +             for d in *; do
> >> +                     [[ -x "$d" && ! -d "$d" ]] && daemons=(${daemons[@]} "$d")
> >
> > 'daemons=("${daemons[@]}" "$d")'. Just to be sure we don't fail here if
> > a daemon ever contains a space (and since you used proper quoting
> > everywhere else).
> i tested with a daemon with space. np.

----
$ touch "bar foo" foobar
$ typeset -a daemons
$ for d in *; do daemons=(${daemons[@]} "$d"); done
$ IFS=,
$ echo "${daemons[*]}"
bar,foo,foobar
----

Funny part is that it works correctly if you run it a second time. This
is due to the input field separator being set to ",", though. We should
not make assumptions on the IFS. Using quotes is the right thing to do
here.

> 
> >> --- a/zsh-completion
> >> +++ b/zsh-completion
> >> @@ -19,7 +19,7 @@ _rc.d () {
> >>                                       _arguments "*: :"
> >>                                       ;;
> >>                               list)
> >> -                                     _arguments "2: :(started stopped)"
> >> +                                     _arguments "*: :(started stopped auto noauto $(echo /etc/rc.d/*(N-*:t)))"
> >
> > Whey, another winner of the "Useless use of echo" award [1]! :)
> For a weird reason, some daemons are missing without the use of echo
> here. I doesn't succeed to reproduce it, so i will change this.
> 
> Thanks for review!

You're welcome!