From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nils Gillmann Subject: Re: [shepherd] herd status suggestion Date: Sun, 10 Jun 2018 14:31:53 +0000 Message-ID: <20180610143153.juzeulj2cruytwsc@abyayala> References: <20180610103459.txzk5aydng6bzwdi@abyayala> <87po0yzxld.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fS1NI-0002mK-Hw for guix-devel@gnu.org; Sun, 10 Jun 2018 10:31:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fS1NH-0007p6-JT for guix-devel@gnu.org; Sun, 10 Jun 2018 10:31:20 -0400 Received: from conspiracy.of.n0.is ([2a01:4f8:1c0c:7ad0::1]:51832) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fS1NH-0007od-8l for guix-devel@gnu.org; Sun, 10 Jun 2018 10:31:19 -0400 Content-Disposition: inline In-Reply-To: <87po0yzxld.fsf@elephly.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org, Nils Gillmann Ricardo Wurmus transcribed 982 bytes: > > Hi Nils, > > > abyayala$ sudo herd status tor > > Status of tor: > > It is stopped. > > It is disabled. > > Provides (tor). > > Requires (user-processes loopback syslogd). > > Conflicts with (). > > Will be respawned. > > Last respawned on Sun Jun 10 08:08:45Z 2018. > > > > > > Would it be an option to change the status output to, > > if it conflicts with no other service: > > > > Conflicts with no other services. > > > > instead of the representation of an empty list? > > This sounds like a good idea. The only argument in favour of keeping it > the way it is now is too weak to take serious: it makes it slightly > easier to parse the output of “herd status”. > > Could you please prepare a patch to change the output? It’s also worth > checking how gettext is used in shepherd (I don’t know more than that it > uses “l10n” as a “gettext” alias) to make sure that the string can be > translated. > > Thanks for this proposal! > > -- > Ricardo > > Thanks! I will look into this, I've looked at the file for the first time (ever? in a long time?) today. If I can't figure out how to do all of it, I'll send further questions. Related and similar: Would it be reasonable to change the output from list-style, like: Depends on: (foo bar irks boot) to the probably tiny bit better readable: Depends on: foo, bar, irks, boot for humans? I'm thinking that even though it is very obvious what we are looking at, we could almost entire sentences? However, it's "interesting" to form sentences here without sounding like Captain Obvious... Status of the service 'tor': It is stopped. It is disabled. Provides (tor). <- 'tor' provides a service for running tor. (? I haven't looked at the shepherd and our use of it, so this is just assuming this is possible.) Requires (user-processes loopback syslogd). <- 'tor' requires these services: uer-processes, loopback, syslogd. Conflicts with (). <- There are no conflicting services./Conflicts with no other services. (when empty) | alternative, when at least 1 element: 'tor' conflicts with: element. Will be respawned. <- Upon crash, tor will be respawned. Last respawned on Sun Jun 10 08:08:45Z 2018. But it could be that his is too long for output, and maybe could even be reduced to the simple statements we have. Is there any documented work besides the code and documentation on why shepherd produces this output, any logical conclusions or...?