Re: [systemd-devel] List all available units
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
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
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
'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
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
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
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
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
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
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