This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: vmstat
- From: "Chris January" <chris at atomice dot net>
- To: <cygwin-apps at cygwin dot com>
- Date: Thu, 27 Jun 2002 22:38:55 +0100
- Subject: Re: vmstat
- References: <OF9302AC86.0EB950DE-ON85256BE4.005579C2@isn.instinet.com> <00b901c21df9$1c9e3df0$0100a8c0@advent02> <20020627163750.GA27819@redhat.com> <010901c21dfa$de6d74e0$0100a8c0@advent02> <3D1B5A59.7090609@ece.gatech.edu> <3D1B72BF.3070701@ece.gatech.edu>
> >>PLEASE do not differentiate between /bin and /usr/bin. This caused no
> >>end of trouble during the early days of setup.exe when setup didn't
> >>*always* follow the mounts. Granted, setup is much better about that
> >>sort of thing now, but don't tempt fate.
> >>
> >>There's no need for separate /bin and /usr/bin on cygwin.
> >>
> >>(I don't care about the procps/ subdirectory, but I doubt others will be
> >>very happy about it. cf. netpbm packagin discussion on cygwin-apps)
> >>
> > I've regenned the package without /usr/bin.
>
>
> AARRGGHH! No, the *other* way. --prefix=/usr. bindir=/usr/bin.
Whoops - I should have RTFM. Sorry. Regenned again.
> > As for the procps subdirectory in /bin I was following the precedent set
by
> > ncurses-test-dll.
>
>
> Yeah -- a precedent set long ago before the current standards evolved.
> In other words, if I wanted to add ncurses as a new package *today* I
> would probably not be allowed the ncurses-test-dll/ subdir. However, as
> an existing package, it has remained and so far nobody has asked me to
> remove it (there used to be an ncurses-test-static/ subdir, as well as
> two other ncurses-related subdirs whose names and purposes escape me at
> the moment). I have no problems removing that last vestige of
> evolutionary history, however, if necessary -- the only prog in there
> that's useful to endusers is 'ncurses.exe' which helps debugging ACS
> charset display problems...
Ok. Do you have any thoughts on where I should put ps.exe and kill.exe?
They need to be somewhere other than /bin, but available should the user
wish to use them. Perhaps I could rename them instead? procps.exe and
prockill.exe, although those names are a little unweidly.
If anyone has any ideas, then please make a suggestion.
Chris