Date: Sun, 18 Mar 2012 09:18:57 +0200 From: Mikolaj Golub <trociny@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: Kostik Belousov <kib@FreeBSD.org>, freebsd-hackers@freebsd.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: a sysctl for process binary osreldate Message-ID: <86d38apeam.fsf@kopusha.home.net> In-Reply-To: <20120317212901.GA44534@stack.nl> (Jilles Tjoelker's message of "Sat, 17 Mar 2012 22:29:01 %2B0100") References: <8662e3m3eq.fsf@kopusha.home.net> <20120317212901.GA44534@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Mar 2012 22:29:01 +0100 Jilles Tjoelker wrote: JT> On Sat, Mar 17, 2012 at 09:30:05PM +0200, Mikolaj Golub wrote: >> I added osrel output to procstat -b option: >> kopusha:~% procstat -b 2975 >> PID COMM OSREL PATH >> 2975 emacs 1000001 /usr/local/bin/emacs-23.3 >> Would this be ok or someone see a better way? JT> Hmm, this means that procstat is not supposed to be used from scripts as JT> it is apparently OK to change its output format like this? Yes, breaking output compatibility worries me too. Although I already broke it recently for '-s' option, adding umask output. Let me cite Robert (taken from our then discussion about procstat umask output): > if we add too many arguments we'll start looking like ps(1), whereas the > point of procstat(1) is that it's *not* ps(1) :-). That is why I decided to not introduce yet another option here too at the cost of breaking compatibility. But I am open for any suggestions. JT> In some ways, querying via ps would be better for scripts since it JT> allows things like JT> ps -p PID -o KEYWORD= JT> which do not need additional parsing except that many of the newer JT> things in procstat do not have ps keywords. JT> -- JT> Jilles Tjoelker -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86d38apeam.fsf>