Re: [systemd-devel] List all available units

2012-08-13 Thread Lennart Poettering
On Mon, 13.08.12 16:01, Václav Pavlín (vpav...@redhat.com) wrote:

  I hope this makes sense?
  
  systemctl complete should probably be considered a hidden feature, so
  not show up in --help or in the man page.
  
  Lennart
  
 
 I think it does make sense. So if we are ok with this solution, I can
 start to work on it.

Please do!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-10 Thread Lennart Poettering
On Thu, 09.08.12 09:39, Václav Pavlín (vpav...@redhat.com) wrote:

  If we present the user with a list like this we probably should show a
  tree view of some kind since the unit file getty@.service might get
  instantiated a couple of times as getty@tty1.service and so on, and
  hence is in a tree-like relationship. 
 
 I like the idea of the tree view, but I cannot imagine how it can help
 to solve autocompletion problem. If I get it right, getty@.service is
 template file, which cannot be manually instantiated, so it can be
 omitted from the output (User cannot do anything with it, right?). On
 the other hand, getty@tty1.service is an instance, which can be stopped,
 restarted etc., and it will be listed in list-units output (and then in
 merged output of new systemctl verb as well).

OK, so, let's focus on the auto completion thing for noiw, and maybe
revisit later if we want to have an additional verb to provide users
with the full list of services and service files.

I'd suggest implementing a new verb complete or so, that would work
like this:

systemctl complete enable foo

invoking this would simply output a new-line separated lists of all unit
files which can be enabled (i.e. excluding static ones, and so on) that
begin with foo.

systemctl complete status

would output the list of loaded units *and* files. Since only two params
are specified it would show all those units/files, wouldn't do any
prefix matching.

And similar for the other commands.

Then, we could update the completion logic for bash to just invoke the
right call.

I hope this makes sense?

systemctl complete should probably be considered a hidden feature, so
not show up in --help or in the man page.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-09 Thread Václav Pavlín
Lennart Poettering píše v St 08. 08. 2012 v 18:31 +0200:
 On Tue, 07.08.12 16:35, Václav Pavlín (vpav...@redhat.com) wrote:
 
 I am not sure we should include the units from list-unit-files in the
 output of list-units, as this would increase the output quite a bit,
 and would be hardly helpful in many cases, and slow.

I didn't really meant to include output of one list-uni* parameter to
another. Those lists does not have much in common and, as You point out,
merged output could be slow.

 So, dunno, I am not entirely sure how to expose this best. We probably
 should get the interface right, and agree how this would be exposed to
 the user, before we actually think about implementing it. Neither of the
 three options I currently see (extend systemctl list-units, extend
 systemctl list-unit-files, add a new systemctl verb) are that
 pretty in my eyes.

I would vote for the new systemctl verb option.

 If we present the user with a list like this we probably should show a
 tree view of some kind since the unit file getty@.service might get
 instantiated a couple of times as getty@tty1.service and so on, and
 hence is in a tree-like relationship. 

I like the idea of the tree view, but I cannot imagine how it can help
to solve autocompletion problem. If I get it right, getty@.service is
template file, which cannot be manually instantiated, so it can be
omitted from the output (User cannot do anything with it, right?). On
the other hand, getty@tty1.service is an instance, which can be stopped,
restarted etc., and it will be listed in list-units output (and then in
merged output of new systemctl verb as well).

 Another option would be to add a notice about systemctl
 list-unit-files in the footer of systemctl list-units. That should
 already be a big imprvoement, since most people probably interrpet the
 current advice of using --all like this.

It would be helpful, but, again, does not solve the autocompletion
problem.

 Another option would be to add systemctl complete as hidden option for
 usage only by bash completion, that does the merging.

This makes sense to me. It could be even something like systemctl
list-autocomplete-units.

 Yes, storing this in a hashmap does make sense. But really, before we
 get hacking we should think about the UI of this.

Ok, I will wait for your agreement.

Václav


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-09 Thread Colin Guthrie
'Twas brillig, and Václav Pavlín at 09/08/12 08:39 did gyre and gimble:
 Lennart Poettering píše v St 08. 08. 2012 v 18:31 +0200:
 If we present the user with a list like this we probably should show a
 tree view of some kind since the unit file getty@.service might get
 instantiated a couple of times as getty@tty1.service and so on, and
 hence is in a tree-like relationship. 
 
 I like the idea of the tree view, but I cannot imagine how it can help
 to solve autocompletion problem. If I get it right, getty@.service is
 template file, which cannot be manually instantiated, so it can be
 omitted from the output (User cannot do anything with it, right?).

A user can actually type systemctl enable getty@.service as it has the
following:

[Install]
Alias=getty.target.wants/getty@tty1.service

Thus enabling the template unit will actually configure an
instantiation of it.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-08 Thread Václav Pavlín
As I noted here:

https://bugzilla.redhat.com/show_bug.cgi?id=790768#c12

this patch doesn't solve my issue. But I think it can be solved in
either systemctl or autocomlete script. 

If we decide to change behaviour of systemctl, the approach, I described
here, can be used. If you prefer to edit autocomplete script, it can be
done with merge of sytemctl output of list-units and list-unit-files and
then pipe to uniq.

Vaclav

Jóhann B. Guðmundsson píše v Út 07. 08. 2012 v 15:21 +:
 On 08/07/2012 02:35 PM, Václav Pavlín wrote:
  https://bugzilla.redhat.com/show_bug.cgi?id=790768
 
 I thought Harald had already fixed this one but perhaps Lennart never 
 committed it.
 
 See [1].
 
 JBG
 
 
 1.http://lists.freedesktop.org/archives/systemd-devel/2012-February/004573.html
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-08 Thread Michal Schmidt

On 08/08/2012 10:21 AM, Václav Pavlín wrote:

If we decide to change behaviour of systemctl, the approach, I described
here, can be used. If you prefer to edit autocomplete script, it can be
done with merge of sytemctl output of list-units and list-unit-files and
then pipe to uniq.


A lot of users find the behaviour of systemctl --all confusing. If you 
can find a nice way to make it display even not-currently-loaded units, 
it would make them happy. And I assume the autocomplete would start 
working as expected too.

See https://bugzilla.redhat.com/show_bug.cgi?id=748512

Michal

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-08 Thread Lennart Poettering
On Tue, 07.08.12 16:35, Václav Pavlín (vpav...@redhat.com) wrote:

 Hi everyone,
 
 I started to work on these two bugs (if I solve the first one, the
 second one will be almost solved as well):
 
 https://bugzilla.redhat.com/show_bug.cgi?id=748512
 https://bugzilla.redhat.com/show_bug.cgi?id=790768
 
 My idea is to get list of loaded units, then list of unit files and then
 get info for units, which are in file list, but not in list of loaded
 units. Then I can print info for all units available in the system
 (whether they are loaded or not).

I am not sure we should include the units from list-unit-files in the
output of list-units, as this would increase the output quite a bit,
and would be hardly helpful in many cases, and slow.

There are differences between the concepts of loaded unit and unit file
on disk. Some units do not exist as unit files, some unit files don't
exist as units. Some files exist in many instances, and so on. 

Yes, it probably make sense to have a way to generate a list of all
units and all unit files, and merge it in some way, but I am not sure
that should be exposed as list-units nor as list-unit-files. Also,
this option is necessarily slow, since (like list-unit-files) goes to
disk and parses a lot of files, hence this is nothing we should confront
the user with on first sight, but only on explicit request.

So, dunno, I am not entirely sure how to expose this best. We probably
should get the interface right, and agree how this would be exposed to
the user, before we actually think about implementing it. Neither of the
three options I currently see (extend systemctl list-units, extend
systemctl list-unit-files, add a new systemctl verb) are that
pretty in my eyes.

If we present the user with a list like this we probably should show a
tree view of some kind since the unit file getty@.service might get
instantiated a couple of times as getty@tty1.service and so on, and
hence is in a tree-like relationship. 

Michal, Kay, do you have any suggestions how we should expose this?

Another option would be to add a notice about systemctl
list-unit-files in the footer of systemctl list-units. That should
already be a big imprvoement, since most people probably interrpet the
current advice of using --all like this.

Another option would be to add systemctl complete as hidden option for
usage only by bash completion, that does the merging.

 I would extract code responsible for loading unit_infos from
 systemctl.c/list_units to the function (so it will be reusable) and do
 the same with the systemctl.c/lis_unit_files.
 
 I would like to use hashmap to store loaded units, because it will be
 faster, than using array, to check it against unit file list. With this
 it would be nice to use hashmap directly in functions list_units and
 output_units_list, so I don't have to move data from array to hashmap
 and back to array.

Yes, storing this in a hashmap does make sense. But really, before we
get hacking we should think about the UI of this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] List all available units

2012-08-07 Thread Václav Pavlín
Hi everyone,

I started to work on these two bugs (if I solve the first one, the
second one will be almost solved as well):

https://bugzilla.redhat.com/show_bug.cgi?id=748512
https://bugzilla.redhat.com/show_bug.cgi?id=790768

My idea is to get list of loaded units, then list of unit files and then
get info for units, which are in file list, but not in list of loaded
units. Then I can print info for all units available in the system
(whether they are loaded or not).

I would extract code responsible for loading unit_infos from
systemctl.c/list_units to the function (so it will be reusable) and do
the same with the systemctl.c/lis_unit_files.

I would like to use hashmap to store loaded units, because it will be
faster, than using array, to check it against unit file list. With this
it would be nice to use hashmap directly in functions list_units and
output_units_list, so I don't have to move data from array to hashmap
and back to array.

I would like to know your opinion and/or suggestions how to solve this
better.

Thanks

Václav Pavlín

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-07 Thread Jóhann B. Guðmundsson

On 08/07/2012 02:35 PM, Václav Pavlín wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=790768


I thought Harald had already fixed this one but perhaps Lennart never 
committed it.


See [1].

JBG


1.http://lists.freedesktop.org/archives/systemd-devel/2012-February/004573.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] List all available units

2012-08-07 Thread Kay Sievers
On Tue, Aug 7, 2012 at 5:21 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
 On 08/07/2012 02:35 PM, Václav Pavlín wrote:

 https://bugzilla.redhat.com/show_bug.cgi?id=790768


 I thought Harald had already fixed this one but perhaps Lennart never
 committed it.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=e2e9329411a3753421e97c084d0f177003b20970

Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel