Re: Bug in builtin function abspath

2006-06-10 Thread Alessandro Vesely
Eli Zaretskii wrote: Do you think it would be a good idea to use GetFileInformationByHandle[Ex] instead? Sure; but someone already did that: see the libgw32c implementation of stat. Aha, that's probably the right place for this discussion! Thanks __

Re: Bug in builtin function abspath

2006-06-09 Thread Eli Zaretskii
> Date: Fri, 09 Jun 2006 14:57:01 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > Furthermore, the number of functionalities that make their way through the > Unix compatibility layer available via msvcrt is even lower. For example, > the stat64.c source file that comes with the Platform S

Re: Bug in builtin function abspath

2006-06-09 Thread Alessandro Vesely
Eli Zaretskii wrote: There are two kinds of them: the other one is done with linkd, from the resource kit (rktools, 11.8Mb, http://go.microsoft.com/fwlink/?LinkId=4544 ) But this kind is a hard link, right? That is, it is a directory entry that points to the same place on the disk data area.

Re: Bug in builtin function abspath

2006-06-08 Thread Eli Zaretskii
> Date: Thu, 08 Jun 2006 08:25:55 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > There are two kinds of them: the other one is done with linkd, from the > resource kit (rktools, 11.8Mb, http://go.microsoft.com/fwlink/?LinkId=4544 ) But this kind is a hard link, right? That is, it is a d

Re: Bug in builtin function abspath

2006-06-07 Thread Alessandro Vesely
Eli Zaretskii wrote: Date: Wed, 07 Jun 2006 07:57:11 -0400 From: Earnie Boyd <[EMAIL PROTECTED]> Cc: Alessandro Vesely <[EMAIL PROTECTED]>, make-w32@gnu.org With mount points one cannot reach "symlink/../not-in-cwd". To be consistent with that, we should first compute ".."'s and then fail. Corr

Re: Bug in builtin function abspath

2006-06-07 Thread Eli Zaretskii
> Date: Wed, 07 Jun 2006 07:57:11 -0400 > From: Earnie Boyd <[EMAIL PROTECTED]> > Cc: Alessandro Vesely <[EMAIL PROTECTED]>, make-w32@gnu.org > > >> With mount points one cannot reach "symlink/../not-in-cwd". To be > >> consistent with that, we should first compute ".."'s and then fail. > >> Corre

Re: Bug in builtin function abspath

2006-06-07 Thread Earnie Boyd
Quoting Eli Zaretskii <[EMAIL PROTECTED]>: With mount points one cannot reach "symlink/../not-in-cwd". To be consistent with that, we should first compute ".."'s and then fail. Correct? Sorry, I don't follow: what mount points? ``mountvol /?'' on any XP box. There is also something calle

Re: Bug in builtin function abspath

2006-06-06 Thread Eli Zaretskii
> Date: Tue, 06 Jun 2006 16:18:47 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > >> And what about realpath? > > > > The same, except that it should fail if the file or its parent > > directory doesn't exist, and it should ``resolve links'', whatever > > that may mean on Windows. > > Hm

Re: Bug in builtin function abspath

2006-06-06 Thread Alessandro Vesely
Eli Zaretskii wrote: Date: Sun, 04 Jun 2006 13:50:08 +0200 From: Alessandro Vesely <[EMAIL PROTECTED]> I'm not sure what abspath should do on win32. It should produce an absolute file name d:/foo/bar.., similarly to what it does on Unix. Fine. And what about realpath? The same, except th

Re: Bug in builtin function abspath

2006-06-04 Thread Eli Zaretskii
> Date: Sun, 04 Jun 2006 13:50:08 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > I'm not sure what abspath should do on win32. It should produce an absolute file name d:/foo/bar.., similarly to what it does on Unix. > And what about realpath? The same, except that it should fail if the

Re: Bug in builtin function abspath

2006-06-04 Thread Alessandro Vesely
Eli Zaretskii wrote: Date: Thu, 01 Jun 2006 16:02:22 +0200 From: Alessandro Vesely <[EMAIL PROTECTED]> _fullpath is a wrapper around GetFullPathName: it possibly allocates the buffer and maps errors to errno. Since _fullpath is not in OS/2 either, I'd use GetFullPathName directly. I'd like to

Re: Bug in builtin function abspath

2006-06-02 Thread Eli Zaretskii
> Date: Fri, 02 Jun 2006 08:24:56 -0400 > From: Earnie Boyd <[EMAIL PROTECTED]> > > Quoting Eli Zaretskii <[EMAIL PROTECTED]>: > > >> Date: Thu, 01 Jun 2006 08:23:13 -0400 > >> From: Earnie Boyd <[EMAIL PROTECTED]> > >> > >> IMO, make should not consider d:foo as a valid path even though the OS >

Re: Bug in builtin function abspath

2006-06-02 Thread Earnie Boyd
Quoting Eli Zaretskii <[EMAIL PROTECTED]>: Date: Thu, 01 Jun 2006 08:23:13 -0400 From: Earnie Boyd <[EMAIL PROTECTED]> IMO, make should not consider d:foo as a valid path even though the OS does. You mean in $abspath or everywhere? We were talking about the former; I'm not sure the latter is

Re: Bug in builtin function abspath

2006-06-01 Thread Andreas Büning
Eli Zaretskii schrieb: > > Date: Wed, 31 May 2006 20:05:55 +0200 > > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > > CC: grischka <[EMAIL PROTECTED]>, make-w32@gnu.org > > > > > Andreas, is there a _getdcwd function on OS/2? > > > > There is an _abspath(char *out, const char *in, i

Re: Bug in builtin function abspath

2006-06-01 Thread Eli Zaretskii
> Date: Thu, 01 Jun 2006 16:02:22 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > _fullpath is a wrapper around GetFullPathName: it possibly allocates > the buffer and maps errors to errno. Since _fullpath is not in OS/2 > either, I'd use GetFullPathName directly. I'd like to avoid too ma

Re: Bug in builtin function abspath

2006-06-01 Thread Andreas Büning
Eli Zaretskii wrote: > > > From: "grischka" <[EMAIL PROTECTED]> > > Cc: > > Date: Tue, 30 May 2006 20:07:10 +0200 > I deliberately didn't use a Win32 API call, since the bug report came > from an OS/2 user, where GetFullPathName is unlikely to be available. > It would be quite ironic if, in resp

Re: Bug in builtin function abspath

2006-06-01 Thread Alessandro Vesely
Earnie Boyd wrote: Quoting Eli Zaretskii <[EMAIL PROTECTED]>: Date: Wed, 31 May 2006 20:05:55 +0200 From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> CC: grischka <[EMAIL PROTECTED]>, make-w32@gnu.org > Andreas, is there a _getdcwd function on OS/2? There is an _abspath(char *out, c

Re: Bug in builtin function abspath

2006-06-01 Thread Eli Zaretskii
> Date: Thu, 01 Jun 2006 08:23:13 -0400 > From: Earnie Boyd <[EMAIL PROTECTED]> > > IMO, make should not consider d:foo as a valid path even though the OS > does. You mean in $abspath or everywhere? We were talking about the former; I'm not sure the latter is even practical. Anyway, please tel

Re: Bug in builtin function abspath

2006-06-01 Thread Earnie Boyd
Quoting Eli Zaretskii <[EMAIL PROTECTED]>: Date: Wed, 31 May 2006 20:05:55 +0200 From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> CC: grischka <[EMAIL PROTECTED]>, make-w32@gnu.org > Andreas, is there a _getdcwd function on OS/2? There is an _abspath(char *out, const char *in, int s

Re: Bug in builtin function abspath

2006-05-31 Thread Eli Zaretskii
> Date: Wed, 31 May 2006 20:05:55 +0200 > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > CC: grischka <[EMAIL PROTECTED]>, make-w32@gnu.org > > > Andreas, is there a _getdcwd function on OS/2? > > There is an _abspath(char *out, const char *in, int size) function doing > exactly wh

Re: Bug in builtin function abspath

2006-05-30 Thread grischka
Maybe on your way it cant hurt to checkout window's native idea of whats an absolute path: char *abspath(const char *in, char *out) { return in && GetFullPathName(in, MAX_PATH, out, NULL) ? out : NULL; } Looks simplicistic, but works. With current directories c:\foo and d:\geez and current d

Re: Bug in builtin function abspath

2006-05-30 Thread Eli Zaretskii
> From: "grischka" <[EMAIL PROTECTED]> > Cc: > Date: Tue, 30 May 2006 20:07:10 +0200 > > Maybe on your way it cant hurt to checkout window's native idea of > whats an absolute path: > > char *abspath(const char *in, char *out) > { > return in && GetFullPathName(in, MAX_PATH, out, NULL) ? out

Re: Bug in builtin function abspath

2006-05-29 Thread Eli Zaretskii
> Date: Mon, 29 May 2006 22:19:18 +0300 > From: Eli Zaretskii <[EMAIL PROTECTED]> > Cc: make-w32@gnu.org > > BAR = $(abspath d:bar) > all: > make -C d:/fubar mumble > make BAR=$(BAR) Actually, with Windows 2K and XP, I think this example will yield identical results with both interpre

Re: Bug in builtin function abspath

2006-05-29 Thread Eli Zaretskii
> Date: Mon, 29 May 2006 09:50:03 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > I though that, as $abspath is a function, it could be used much like pwd, > i.e. get the path which is current at the time of the call so that > one can refer to that frozen value even after changing director

Re: Bug in builtin function abspath

2006-05-29 Thread Alessandro Vesely
Eli Zaretskii wrote: . It handles the d:foo case by converting it to d:./foo Just a short comment: the abspath description says that it returns "an absolute name that does not contain any `.' or `..' components". That's true, but we cannot do any better in this case. Why shouldn't we use _get

Re: Bug in builtin function abspath

2006-05-28 Thread Eli Zaretskii
> Date: Sun, 28 May 2006 10:57:33 +0200 > From: Alessandro Vesely <[EMAIL PROTECTED]> > > Eli Zaretskii wrote: > >>> > >>> . It handles the d:foo case by converting it to d:./foo > >> Just a short comment: the abspath description says that it returns > >> "an absolute name that does not contain a

Re: Bug in builtin function abspath

2006-05-28 Thread Alessandro Vesely
Eli Zaretskii wrote: . It handles the d:foo case by converting it to d:./foo Just a short comment: the abspath description says that it returns "an absolute name that does not contain any `.' or `..' components". That's true, but we cannot do any better in this case. Why shouldn't we use _

Re: Bug in builtin function abspath

2006-05-27 Thread Eli Zaretskii
> Date: Sat, 27 May 2006 19:57:53 +0200 > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], make-w32@gnu.org > > Eli Zaretskii wrote: > > > Apart of simpler code (IMHO), this patch also has 2 other advantages: > > > > . It handles the d:foo case by converting

Re: Bug in builtin function abspath

2006-05-27 Thread Andreas Büning
Eli Zaretskii wrote: > Apart of simpler code (IMHO), this patch also has 2 other advantages: > > . It handles the d:foo case by converting it to d:./foo Just a short comment: the abspath description says that it returns "an absolute name that does not contain any `.' or `..' components". > .

Re: Bug in builtin function abspath

2006-05-27 Thread Andreas Büning
Eli Zaretskii schrieb: > > > Date: Fri, 26 May 2006 21:52:05 +0200 > > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > > Cc: > > > > make 3.81 has a new builtin function 'abspath' which doesn't support > > drive letters. > > Could you please provide examples of this non-support? At

Re: Bug in builtin function abspath

2006-05-27 Thread Eli Zaretskii
> Date: Fri, 26 May 2006 23:39:33 +0200 > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > CC: make-w32@gnu.org > > > (Yes, I see in the source code that it will not DTRT with "d:/foo" and > > will not add a drive letter to "/foo", but I wonder whether there are > > other examples.) >

Re: Bug in builtin function abspath

2006-05-26 Thread Eli Zaretskii
Paul, I don't understand the advice to move the w32 code into some of the w32 specific files. abspath is a general-purpose function, not limited to w32, its definition is on function.c. We don't have an established mechanism in the Make sources to overload functions with OS-specific variants. So

Re: Bug in builtin function abspath

2006-05-26 Thread Eli Zaretskii
> Date: Fri, 26 May 2006 21:52:05 +0200 > From: Andreas =?iso-8859-1?Q?B=FCning?= <[EMAIL PROTECTED]> > Cc: > > make 3.81 has a new builtin function 'abspath' which doesn't support > drive letters. Could you please provide examples of this non-support? At least the simple example below works fo

Bug in builtin function abspath

2006-05-26 Thread Andreas Büning
Hello! make 3.81 has a new builtin function 'abspath' which doesn't support drive letters. I mailed this to the bug-make mailing list but I got redirected here by the maintainer: - %% Andreas Büning <[EMAIL PROTECTED]> writes: > ab> In July 2005 I se