Hi,
Ashish Gokhale, le Sun 05 Feb 2006 19:07:17 +, a écrit :
> I checked for the error message "cvs [checkout
> aborted]: could not chdir to gnumach/i386/aux: Invalid
> argument"
> I am using windows2000 to download & study the GnuMach
> source code. It seems 'aux' is a reserved word & its
Ah
On Mon, Feb 06, 2006 at 09:59:08PM +0100, Samuel Thibault wrote:
> Ashish Gokhale, le Sun 05 Feb 2006 19:07:17 +, a ?crit :
> > I checked for the error message "cvs [checkout
> > aborted]: could not chdir to gnumach/i386/aux: Invalid
> > argument"
> > I am using windows2000 to download & study
hi folks,
I've somewhat successfully ported the pcmcia-core, the i82365 bridge
driver as well as the pcnet_cs (NE-2000 compatible cards) driver from
Linux's card services to gnumach (not oskit, but the gnumach-1-branch).
The "success" already has been announced on #hug last wednesday,
however az
when you build a program to work on an directory, all that you will need
from that package is the binary location.
I do not understand any of that. I think you need to give labels
to the various entities that you are talking about, and describe their
relationships clearly.
What you
What he's saying is,
rather than doing this, you should just have a utility that keeps the
PATH environment variable updated (by adding hte packages' bin/ and
sbin/ directories), updates ld.so.conf, and so on.
This would be a big step backward. It would result in gigantic PATH
val
I do not think that keep a loop symlink of USR->/ is a good idea,
since you will never be able to do a "find / -name
*something*". So, we need to correct those scripts. (* There are
scripts with references to /usr/python or /usr/local/perl)
Doesn't find know enough not
Doesn't find know enough not to follow symlinks to directories?
Indeed, by default, it does not follow symlinks to directories.
I would think it ought to.
find / -P -name FOO
What does -P do? I don't see it in the documentation of find
on my machine.
It's in the info m
I do not think that keep a loop symlink of USR->/ is a good idea,
I admit I'm not sure of all the context here, but is there some proposal
that /usr will not resolve in GNU? That seems impractical to me.
Virtually everything ever written uses /usr, one way or another.
___