Hi, John Soo skribis: > Ludovic Courtès writes: > >>> * Still not normalized - how can I search for just the child processes >>> associated with a particular command? >> >> Like: >> >> guix processes | recsel -e 'ClientCommand ~ "xyz"' -p ChildProcess >> >> ? >> >> Actually what does “normalized” mean in this context? > > Excellent question. I was thinking along the lines of database > normalization. The default output has multi-valued fields for child > processes, so the idea is to make them their own record set. Does that > make sense? Yes it does! Initially I wondered if it was a term used in recutils, but apparently it’s not. > An aside - Probably to be entirely honest about normalizing the output, > locks really would be in a separate record set too. Yeah. > Another challenge is making sure the user can understand what > "normalized" means. I am not sure readers of the manual/cli help will > be able to infer what it means from context. On the other hand, it is > such a small use case that it seems imbalanced to provide a lot of > background for the term "normal". What do you think? Sure. Thinking more about it, to me the appeal of recutils is that it’s both human- and machine-readable. But here we end up having a specific machine-readable variant. But yeah, maybe that’s unavoidable. >>> I wouldn't be opposed to splitting ChildProcess into ChildPID and >>> ChildCommand. I would like it best if that change was made in addition >>> to adding the normalized version, since the normalized version allows >>> more functionality. >> >> I would think it’s OK to break compatibility on just these >> “ChildProcess” fields. > > Ok. Would it be ok if I put that in a separate commit? Yes (you mean in addition to ‘-f normalized’, right?). Thanks, Ludo’.