Date: Wed, 22 Aug 2001 08:39:21 +0100 From: Josef Karthauser <joe@tao.org.uk> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: parsing problem with /proc/N/status Message-ID: <20010822083921.A1147@tao.org.uk> In-Reply-To: <Pine.NEB.3.96L.1010819230616.35655A-100000@fledge.watson.org>; from rwatson@FreeBSD.ORG on Sun, Aug 19, 2001 at 11:09:35PM -0400 References: <20010817102549.A712@tao.org.uk> <Pine.NEB.3.96L.1010819230616.35655A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 19, 2001 at 11:09:35PM -0400, Robert Watson wrote:
>=20
> 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)=20
>=20
> 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.=20
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 sing=
le
line containing multiple space-separated fields as follows:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
o command name
o process id
o parent process id
o process group id
o session id
o major,minor of the controlling terminal, or -1,-1 if there=
is
no controlling terminal.
o a list of process flags: ctty if there is a controlling te=
r-
minal, sldr if the process is a session leader, noflags if
neither of the other two flags are set.
o the process start time in seconds and microseconds, comma
separated.
o the user time in seconds and microseconds, comma separated.
o the system time in seconds and microseconds, comma separat=
ed.
o the wait channel message
o the process credentials consisting of the effective user id
and the list of groups (whose first member is the effective
group id) all comma separated.
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?
Joe
--ibTvN161/egqYuK8
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjuDYakACgkQXVIcjOaxUBaqbwCeN2RUBz5LZe+JWl/H2YR2V4pO
g2IAoLbWKFLj60bxtGt6Ka6NmEBvj6Mr
=CVwI
-----END PGP SIGNATURE-----
--ibTvN161/egqYuK8--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822083921.A1147>