9 messages in org.freebsd.freebsd-fsRe: parsing problem with /proc/N/status| From | Sent On | Attachments |
|---|---|---|
| Josef Karthauser | Aug 17, 2001 2:25 am | |
| Dag-Erling Smorgrav | Aug 17, 2001 3:13 pm | |
| Josef Karthauser | Aug 18, 2001 6:19 am | |
| Arne Dag Fidjestøl | Aug 18, 2001 4:23 pm | |
| Dan Ellard | Aug 18, 2001 5:49 pm | |
| Dag-Erling Smorgrav | Aug 18, 2001 7:14 pm | |
| Robert Watson | Aug 19, 2001 8:09 pm | |
| Josef Karthauser | Aug 22, 2001 12:38 am | |
| Josef Karthauser | Aug 30, 2001 4:43 am |
| Subject: | Re: parsing problem with /proc/N/status | |
|---|---|---|
| From: | Josef Karthauser (jo...@tao.org.uk) | |
| Date: | Aug 30, 2001 4:43:57 am | |
| List: | org.freebsd.freebsd-fs | |
On Wed, Aug 22, 2001 at 08:39:21AM +0100, Josef Karthauser wrote:
On Sun, Aug 19, 2001 at 11:09:35PM -0400, Robert Watson wrote:
I guess my feeling is that fundamentally, this type of process data is "typed" as a nul-terminated string. procfs fails to export all types safely (i.e., unambiguously), including nul-terminated strings. I suppose really, the kernel should export in ASN.1... (run away)
Actually, the right answer is probably simply to use sysctl to get this type of process information, since the results actually do have types respected by the medium.
Accepted, but we do support procfs/status as a method too otherwise we wouldn't implement it.
The procfs manual page says:
status The process status. This file is read-only and returns a single line containing multiple space-separated fields as follows: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [cut] This suggests that whatever we do in addition the minimum is to ensure that 'command name' doesn't contain spaces. If we're not going to replace them with underscores, for example, what are we going to replace them with?
Does anyone have a strong opinion on this? If not I'm going to make this functional change.
Joe