In local.freebsd.current you write:
>On Mon, 5 Feb 2001, Bruce Evans wrote:
[...]
>> I think procfs never actually implemented this. Program names may
>> have spaces in them too. Of course, the line is too hard to parse if
>> the first "field" has spaces in it. Only MAXCOMLEN and NAME_MAX
>> prevent the command name being the contents of another process's
>> status line :-).
>Ok, then how should this be fixed?
>We could escape the space characters with something:
>swi5:$task$queue 14 0 0 0 -1,-1 noflags 981365276,40 0,0 0,0 nochan 0 0 0,0 -
>and for command name 'my$prog':
>my$$prog 334 1 332 0 -1,-1 noflags 981361691,37404 0,0 0,5748 select 0 0 0,0 -
>or similar...
IMHO a correct solution would be to use a separator that cannot occur
in any of the fields. All fields but the command name can be
considered "well behaved" (= under control by procfs), and the command
name is subject to file name limitations: that leaves NUL, "\n" and
maybe "/" (of only the basename is shown) as safe separators.
The "cmdline" file seems to solve the problem by using NULs.
Come to think of it: another solution, in this case, would be to put
the command name last on the line: anything beyond field N is the
command name, including any spaces.
But, please, no quoting.
$.02,
/Mikko
--
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
