Message-ID: <4a89b8680801222033y6dad8c6dw31f71e10896117c5@mail.gmail.com>
Date: Tue, 22 Jan 2008 22:33:30 -0600
From: paul DOT hermeneutic AT gmail DOT com
To: cygwin AT cygwin DOT com
Subject: Re: ps executable does not appear to match source
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

>That said, however, the other way of dealing with this is to modify
>procps to deal with Windows pids.  Then we wouldn't need the cygwin ps.
>If you want to provide a patch to do that, then it's likely that the
>procps maintainer would accept it -- assuming that it isn't so intrusive
>as to cause an ongoing maintenance problem.
>
>If procps can be made to do all of the things that ps now does then
>there would be no reason to keep ps around.

I am interested.  However, I would want to ensure from the beginning
the it is possible to achieve.  Would Cygwin accept a ps that did not
produce identically formatted output for each option of the
historically older version?  What about all those people who have
crafted their shell or Perl or Python code to interpret the output of
the historically older version?

For example, consider the -s switch; ps and the historically older
version have a different usage for this switch.

If equivalent functionality is acceptable, then I would like to
investigate further.  If not, then I am having a difficult time seeing
this as achievable.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/