init_buffer PWD fix

init_buffer PWD fix

[Keiichiro Nagano]

Dear all,

init_buffer uses environmental variable PWD to identify current
working directory.  I think we should not use it on Windows.  On
Windows with Cygwin, PWD is unreliable and confusing, because

* Cygwin bash treats it
* Cygwin sh (ash) doesnot
* to say nothing of command.com, cmd.exe, nmake.exe and so on

How do you think?

-- 
Keiichiro Nagano



Index: buffer.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/buffer.c,v
retrieving revision 1.381
diff -u -u -r1.381 buffer.c
--- buffer.c	   16 Apr 2002 07:34:36 -0000	1.381
+++ buffer.c	   21 Apr 2002 20:13:58 -0000
@@ -4973,6 +4973,7 @@
   if (NILP (buffer_defaults.enable_multibyte_characters))
     Fset_buffer_multibyte (Qnil);
 
+#ifndef WINDOWSNT
   /* If PWD is accurate, use it instead of calling getwd.  This is faster
      when PWD is right, and may avoid a fatal error.  */
   if ((pwd = getenv ("PWD")) != 0
@@ -4990,6 +4991,13 @@
   else if (getwd (buf) == 0)
     fatal ("`getwd' failed: %s\n", buf);
 #endif
+#else /* not WINDOWSNT */
+  /* We do not use PWD on Windows because it's unreliable and
+     confusing (Cygwin bash treats it, Cygwin sh (ash) doesnot, to say
+     nothing of command.com, cmd.exe, nmake.exe and so on) */
+  if (getwd (buf) == 0)
+    fatal ("`getwd' failed: %s\n", buf);
+#endif /* not WINDOWSNT */
 
 #ifndef VMS
   /* Maybe this should really use some standard subroutine

Re: init_buffer PWD fix

[Keiichiro Nagano]

At Mon, 22 Apr 2002 05:15:17 +0900,
knagano wrote:
> Windows with Cygwin, PWD is unreliable and confusing, because
> 
> * Cygwin bash treats it
> * Cygwin sh (ash) doesnot
> * to say nothing of command.com, cmd.exe, nmake.exe and so on

So when you invoke 'sh', 'make' or 'nmake' from the bash shell, you
cannot trust PWD.  You will meet with this kind of situations quite
often when you try to 'make' Emacs Lisp products which do chdir(cd) in
Makefile.

(For instance, see
* http://lists.airs.net/semi-gnus/archive/200101/msg00057.html
* http://www.ysnb.net/meadow/meadow-users-jp/2001/msg01014.html
if you can read Japanese.)

-- 
Keiichiro Nagano

Re: init_buffer PWD fix

[Paul Eggert]

> From: Keiichiro Nagano (=?ISO-2022-JP?B?GyRCMUpMbjc9MGxPOhsoQg==?=) <knagano@sodan.org>
> Date: Mon, 22 Apr 2002 05:15:17 +0900
> 
> init_buffer uses environmental variable PWD to identify current
> working directory.  I think we should not use it on Windows.  On
> Windows with Cygwin, PWD is unreliable and confusing

PWD is unreliable on all platforms, but Emacs works around the problem
with a similar method on all platforms by statting $PWD and ".", and
using $PWD only if stat results agree.  What is the problem with
this workaround on Windows?

Re: init_buffer PWD fix

[Keiichiro Nagano]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

At Sun, 21 Apr 2002 23:18:38 -0700 (PDT),
Paul Eggert wrote:
> > init_buffer uses environmental variable PWD to identify current
> > working directory.  I think we should not use it on Windows.  On
> > Windows with Cygwin, PWD is unreliable and confusing
> 
> PWD is unreliable on all platforms, but Emacs works around the problem
> with a similar method on all platforms by statting $PWD and ".", and
> using $PWD only if stat results agree.  What is the problem with
> this workaround on Windows?

You cannot get st_ino which makes sence (without cygwin1.dll).
Compile stattest.c on Windows by MSVC (cl.exe), and you will see:

----
$ ./stattest
stattest.c: 0
stattest.exe: 0
.: 0
..: 0
C:\: 0
C:\WINNT: 0
nonexist: stat failed
----

I wrote, compiled and run this code on Windows 2000 SP2 SRP1 with NTFS
partition.

-- 
Keiichiro Nagano



[-- Attachment #2: stattest.c --]
[-- Type: text/plain, Size: 468 bytes --]

/* compile: cl stattest.c */

#include <stdio.h>
#include <sys/stat.h>

void
print_ino (char *target)
{
  struct stat statbuf;
  if (stat (target, &statbuf) == 0)
    printf ("%s: %d\n", target, statbuf.st_ino);
  else
    printf ("%s: stat failed\n", target);
}

int
main (void)
{
  print_ino ("stattest.c");
  print_ino ("stattest.exe");
  print_ino (".");
  print_ino ("..");
  print_ino ("C:\\");
  print_ino ("C:\\WINNT");
  print_ino ("nonexist");
  return 0;
}

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Keiichiro Nagano wrote:

> You cannot get st_ino which makes sence (without cygwin1.dll).

There's code to do that in src/w32.c in the Emacs distribution, but it's 
disabled for some reason.

Re: init_buffer PWD fix

[Jason Rumney]

Keiichiro Nagano (永野圭一郎) <knagano@sodan.org> writes:

> > PWD is unreliable on all platforms, but Emacs works around the problem
> > with a similar method on all platforms by statting $PWD and ".", and
> > using $PWD only if stat results agree.  What is the problem with
> > this workaround on Windows?
> 
> You cannot get st_ino which makes sence (without cygwin1.dll).
> Compile stattest.c on Windows by MSVC (cl.exe), and you will see:

Emacs does not use the system stat() on Windows.  It is redefined in
w32.c, because we know the standard Windows one is buggy.  Are you
saying there are bugs in that implementation of stat()?


-- 
Jason Rumney

Re: init_buffer PWD fix

[Eli Zaretskii]

On Sun, 21 Apr 2002, Paul Eggert wrote:

> PWD is unreliable on all platforms, but Emacs works around the problem
> with a similar method on all platforms by statting $PWD and ".", and
> using $PWD only if stat results agree.  What is the problem with
> this workaround on Windows?

The problem is probably what you'd guess: the inode comparison doesn't 
work on Windows as well as it does on Posix platforms...

But even so, I still don't see how this would cause a failure.

Re: init_buffer PWD fix

[Paul Eggert]

> Date: Mon, 22 Apr 2002 10:53:47 +0300 (IDT)
> From: Eli Zaretskii <eliz@is.elta.co.il>
> 
> > PWD is unreliable on all platforms, but Emacs works around the problem
> > with a similar method on all platforms by statting $PWD and ".", and
> > using $PWD only if stat results agree.  What is the problem with
> > this workaround on Windows?
> 
> The problem is probably what you'd guess: the inode comparison doesn't 
> work on Windows as well as it does on Posix platforms...

If memory serves, that problem occurs on some Windows platforms but
not on others, so any workaround should apply only to Windows
platforms where 'stat' is broken.  Fcopy_file uses the conditional
`#if !defined (DOS_NT) || __DJGPP__ > 1' before inspecting st_ino;
would that be appropriate here too?

> But even so, I still don't see how this would cause a failure.

If 'stat' is broken, then Emacs can think that $PWD is correct even
when it is not.

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Paul Eggert wrote:

> > The problem is probably what you'd guess: the inode comparison doesn't 
> > work on Windows as well as it does on Posix platforms...
> 
> If memory serves, that problem occurs on some Windows platforms but
> not on others

It depends on the library used to build Emacs.  Windows filesystems don't 
have inodes, so a library must emulate them, and the emulation should be 
good enough to DTRT in such cases.  IIRC, the stock Windows runtime 
simply returns zero in the inode member.

> so any workaround should apply only to Windows
> platforms where 'stat' is broken.  Fcopy_file uses the conditional
> `#if !defined (DOS_NT) || __DJGPP__ > 1' before inspecting st_ino;
> would that be appropriate here too?

DJGPP emulates the inodes well enough for the code to work, but the 
Windows port is not compiled with DJGPP.  It is compiled with MSVC or 
MinGW, both of which use the Windows runtime.

There's an inode emulation code in src/w32.c, but it seems like it's 
disabled.  Jason, can you tell why (I've read the comments, but it sounds 
like this case contradicts them)?

Personally, I think the code in buffer.c could compare normalized file 
names as either an alternative or a complementary to the inode method.
Then it could be made reliable on more platforms.

> > But even so, I still don't see how this would cause a failure.
> 
> If 'stat' is broken, then Emacs can think that $PWD is correct even
> when it is not.

I understand that, but a specific example might still help.  Thhis is the 
first time I see such a complaint, so I wonder how come no one else sees 
the problem.

Re: init_buffer PWD fix

[Paul Eggert]

> Date: Mon, 22 Apr 2002 11:10:55 +0300 (IDT)
> From: Eli Zaretskii <eliz@is.elta.co.il>
> 
> > any workaround should apply only to Windows
> > platforms where 'stat' is broken.  Fcopy_file uses the conditional
> > `#if !defined (DOS_NT) || __DJGPP__ > 1' before inspecting st_ino;
> > would that be appropriate here too?
> 
> DJGPP emulates the inodes well enough for the code to work, but the 
> Windows port is not compiled with DJGPP.

Hmm, I guess nobody told the author of Fcopy_file....  Perhaps there's
an opportunity for code consolidation/cleanup there.

Anyway, rather than get sucked into st_ino portability hell, how about
checking st_mtime as well?  That is, after doing this:

      && stat (pwd, &pwdstat) == 0
      && stat (".", &dotstat) == 0
      && dotstat.st_ino == pwdstat.st_ino
      && dotstat.st_dev == pwdstat.st_dev

init_buffer can do this:

      && dotstat.st_mtime == pwdstat.st_mtime

This won't hurt much on non-broken systems, and it should fix the vast
majority of the problem on systems where st_ino is broken.

> Personally, I think the code in buffer.c could compare normalized file 
> names as either an alternative or a complementary to the inode method.

What's a "normalized file name"?  Can it be computed as quickly as an
inode number can?

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Paul Eggert wrote:

> > > Fcopy_file uses the conditional
> > > `#if !defined (DOS_NT) || __DJGPP__ > 1' before inspecting st_ino;
> > > would that be appropriate here too?
> > 
> > DJGPP emulates the inodes well enough for the code to work, but the 
> > Windows port is not compiled with DJGPP.
> 
> Hmm, I guess nobody told the author of Fcopy_file....  Perhaps there's
> an opportunity for code consolidation/cleanup there.

Not sure what you mean here: the inode comparison is ifdef'ed away for 
the Windows port, so on Windows Emacs simply doesn't support the feature 
whereby it tells you that the source and destinations are the same file.  
But since there are no symlinks on Windows, the only way this can happen 
is if the user transmogrifies the file name in some way, which is 
something less probable than collisions involving symlinks.

Or did you mean something else?

> Anyway, rather than get sucked into st_ino portability hell, how about
> checking st_mtime as well?  That is, after doing this:
> 
>       && stat (pwd, &pwdstat) == 0
>       && stat (".", &dotstat) == 0
>       && dotstat.st_ino == pwdstat.st_ino
>       && dotstat.st_dev == pwdstat.st_dev
> 
> init_buffer can do this:
> 
>       && dotstat.st_mtime == pwdstat.st_mtime
> 
> This won't hurt much on non-broken systems, and it should fix the vast
> majority of the problem on systems where st_ino is broken.

That would be unreliable, I think: on some Windows filesystems, the time 
stamp of a directory is determined when the directory is created, and 
then never changes (and cannot be changed with any system call, only by 
accessing the disk at the sector level).

> > Personally, I think the code in buffer.c could compare normalized file 
> > names as either an alternative or a complementary to the inode method.
> 
> What's a "normalized file name"?

For DOS/Windows systems, it's roughly a full absolute file name, in some 
standard letter-case (either all uppercase or all lowercase), and with 
all slashes converted to a single style (either all forward slashes or 
all backslashes).

> Can it be computed as quickly as an inode number can?

Every reliable method of inode simulation that I know of begins by 
computing a normalized file name (since you need to assign the same 
inode number when you see the same file).  So it's as fast as a 
simulated inode or faster.

Perhaps it's high time we added a file-name comparison primitive to 
Emacs.  There are few other places where it could be useful.  On Posix 
platforms it could compare inodes, while other platforms will do their 
own magic.

Re: init_buffer PWD fix

[Paul Eggert]

> From: Eli Zaretskii <eliz@is.elta.co.il>
> Date: Mon, 22 Apr 2002 14:14:48 +0300 (IDT)
>
> >       && dotstat.st_mtime == pwdstat.st_mtime
> > 
> > This won't hurt much on non-broken systems, and it should fix the vast
> > majority of the problem on systems where st_ino is broken.
> 
> That would be unreliable, I think: on some Windows filesystems, the time 
> stamp of a directory is determined when the directory is created, and 
> then never changes

I don't see why this would cause a problem.  That code-change would
make st_mtime be a double-check on st_ino.  I think you're suggesting
that st_mtime might be a somewhat random number that never changes,
but that's great: that's just what we want here.

> Perhaps it's high time we added a file-name comparison primitive to 
> Emacs.  There are few other places where it could be useful.  On Posix 
> platforms it could compare inodes, while other platforms will do their 
> own magic.

I suggest looking at the following macros from GNU diffutils/src/system.h:

  same_file
  same_file_attributes

especially the commentary.

Unfortunately, st_ino is not reliable even on many platforms that
nearly conform to POSIX, and this includes GNU/Linux.  The best
workaround for this problem depends on the application.  For some
applications, this is better:

  if (0 < same_file (&stat_buf[0], &stat_buf[1])
      && same_file_attributes (&stat_buf[0], &stat_buf[1]))
    assume_files_are_same ();
  else
    assume_files_are_different ();

and for other applications, this is better:

  if (0 < same_file (&stat_buf[0], &stat_buf[1]))
    assume_files_are_same ();
  else
    assume_files_are_different ();

and there are other possibilities, too, alas.


> > Hmm, I guess nobody told the author of Fcopy_file....  Perhaps there's
> > an opportunity for code consolidation/cleanup there.
> 
> Not sure what you mean here: the inode comparison is ifdef'ed away for 
> the Windows port,

The inode comparison is done if (! defined WINDOWSNT && (!defined
(DOS_NT) || __DJGPP__ > 1)).  Sorry, I don't know the ins and outs of
the Windows ports, but I assumed that there could be a non-WINDOWSNT
port out there.  Maybe I'm confusing Windows and DOS, though.

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Paul Eggert wrote:

> > That would be unreliable, I think: on some Windows filesystems, the time 
> > stamp of a directory is determined when the directory is created, and 
> > then never changes
> 
> I don't see why this would cause a problem.  That code-change would
> make st_mtime be a double-check on st_ino.  I think you're suggesting
> that st_mtime might be a somewhat random number that never changes

No, I'm saying that the probability of several directories to have the 
same time stamp, e.g. if they were created by some program like Tar or 
cp during the same run, is quite high, especially on a fast machine.  And 
since the time stamp doesn't change thereafter, Emacs will forever think 
such two directories are the same.

> The inode comparison is done if (! defined WINDOWSNT && (!defined
> (DOS_NT) || __DJGPP__ > 1)).  Sorry, I don't know the ins and outs of
> the Windows ports, but I assumed that there could be a non-WINDOWSNT
> port out there.

There are no Windows ports of Emacs that don't define WINDOWSNT (even 
though the binary runs on all versions of Windows from Windows 95 and up).
Cygwin simulates inodes in its library, but there's no Cygwin port of 
Emacs yet.  When Emacs is ported to Cygwin, the person who does the port 
will have to take care of all these ifdef's and change them to DTRT; 
that's one of the hardest parts of such a port.

The MS-DOS port defines __DJGPP__ and has a working inode simulation in 
its library (as you know from Diffutils ;-).

Re: init_buffer PWD fix

[Jason Rumney]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> There's an inode emulation code in src/w32.c, but it seems like it's 
> disabled.  Jason, can you tell why.

I don't know.  But there is also a reimplementation of stat() in
w32.c, which is not disabled.  I think that is what we really want,
isn't it?

-- 
Jason Rumney

Re: init_buffer PWD fix

[Eli Zaretskii]

On 22 Apr 2002, Jason Rumney wrote:

> But there is also a reimplementation of stat() in
> w32.c, which is not disabled.  I think that is what we really want,
> isn't it?

Yes.  But our implementation of `stat' always returns zero for inodes of 
directories (because the inodes it computes need a value available via 
GetFileInformationByHandle, and Windows won't let you open a directory).  
So this implementation doesn't help for directories, which is the cause 
of the OP's problem.

So I think in the case of directories, some simulation of inodes is 
necessary.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Primarily, I suggested this change to the ML, but I don't explain
the detail on that to Nagano-san.  Sorry.

Paul Eggert <eggert@twinsun.com> writes:

>> From: Keiichiro Nagano (=?ISO-2022-JP?B?GyRCMUpMbjc9MGxPOhsoQg==?=) <knagano@sodan.org>
>> Date: Mon, 22 Apr 2002 05:15:17 +0900
>> 
>> init_buffer uses environmental variable PWD to identify current
>> working directory.  I think we should not use it on Windows.  On
>> Windows with Cygwin, PWD is unreliable and confusing
>
> PWD is unreliable on all platforms, but Emacs works around the problem
> with a similar method on all platforms by statting $PWD and ".", and
> using $PWD only if stat results agree.  What is the problem with
> this workaround on Windows?

Yes, the current Emacs implementation compares the result of stat("."), but
stat() of Windows could not strictly emulate the behavior especially on inode.
So if "PWD" environment variable is wrongly set, default_directory would be also
wrongly set.

But, in the first place, is this code necessary on all platform?
Even now, is it really efficient on almost all of the platforms?
I don't think we should stick to such hacked code for the simple
job to get the current directory.

FYI, I've tested the following code on Debian GNU/Linux (sid) to check
the efficiency.

----------------------------------------
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

#define MAXPATHLEN 2048

#ifndef DIRECTORY_SEP
#define DIRECTORY_SEP '/'
#endif
#ifndef IS_DIRECTORY_SEP
#define IS_DIRECTORY_SEP(_c_) ((_c_) == DIRECTORY_SEP)
#endif
#ifndef IS_DEVICE_SEP
#ifndef DEVICE_SEP
#define IS_DEVICE_SEP(_c_) 0
#else
#define IS_DEVICE_SEP(_c_) ((_c_) == DEVICE_SEP)
#endif
#endif

char* getcwd_stat(char *buf)
{
  char *pwd;
  struct stat pwdstat, dotstat;

  if ((pwd = getenv ("PWD")) != 0
      && (IS_DIRECTORY_SEP (*pwd) || (*pwd && IS_DEVICE_SEP (pwd[1])))
      && stat (pwd, &pwdstat) == 0
      && stat (".", &dotstat) == 0
      && dotstat.st_ino == pwdstat.st_ino
      && dotstat.st_dev == pwdstat.st_dev
      && strlen (pwd) < MAXPATHLEN)
    strcpy (buf, pwd);
  else
    return NULL;
  return buf;
}

char * getcwd_normal(char *buf)
{
  return getcwd (buf, MAXPATHLEN + 1);
}

int main(int argc, char **argv)
{
  char buf[MAXPATHLEN + 1];
  char *pwd;
  int i;

  if (argv[1][0] == 's')
    {
      for (i = 0;i < 1000000;i++)
	getcwd_stat(buf);
    }
  else
    {
      for (i = 0;i < 1000000;i++)
	getcwd_normal(buf);
    }

  return 1;
}

----------------------------------------
The result are 
[~:] time ./a.out s
./a.out s  1.22s user 2.68s system 100% cpu 3.883 total
[~:] time ./a.out n
./a.out n  0.29s user 0.92s system 100% cpu 1.200 total
----------------------------------------

Of course, this check only covers narrow situation.  It may depends on
the file system the current directly locates.  But at least, I could state
there exist situations that the hacked code is much slower than simple getcwd()
calling.

Therefore, I'd like to propose to remove this hacked optimization from init_buffer().

Do you have any comments?

  With regards,

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

On Tue, 23 Apr 2002, MIYASHITA Hisashi wrote:

> But, in the first place, is this code necessary on all platform?
> Even now, is it really efficient on almost all of the platforms?
> I don't think we should stick to such hacked code for the simple
> job to get the current directory.

I think Emacs does that because the system call invoked by `getcwd' is 
much slower on Unix than an access to the environment variables followed 
by a call to `stat'.  If that is no longer true, we could as well remove 
the `getenv' part and call `getcwd' directly.

However, the case of calling `stat' on directories should be fixed in the 
Windows port anyhow, IMHO, even if it is irrelevant to the issue of PWD.

Re: init_buffer PWD fix

[Richard Stallman]

    I think Emacs does that because the system call invoked by `getcwd' is 
    much slower on Unix than an access to the environment variables followed 
    by a call to `stat'.  If that is no longer true, we could as well remove 
    the `getenv' part and call `getcwd' directly.

I see no reason to think the situation has changed.
Our most important platform is GNU, and this optimization
is useful on GNU, so we will keep it.  There's no need to spend
time arguing about that question.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Richard Stallman <rms@gnu.org> writes:

> I see no reason to think the situation has changed.
> Our most important platform is GNU, and this optimization
> is useful on GNU, so we will keep it.  There's no need to spend
> time arguing about that question.

Excuse me, but I'd like to reconfirm this statement because it's important
not only technically also politically even if my proposal is rejected.
Debian GNU/Linux is important GNU platform, isn't it?  Simple getcwd() call
is much (about three times) faster than this optimization at least on Debian
GNU/Linux(sid) as I've proven that.

  With regards,

from himi

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi <himi@m17n.org>
> Date: Tue, 23 Apr 2002 15:14:31 +0900
> 
> But, in the first place, is this code necessary on all platform?

It's not necessary everywhere, but it's necessary on many platforms
(including GNU/Linux) and would be painful to figure out exactly which
platforms need it and which don't.

> Even now, is it really efficient on almost all of the platforms?

It's pretty efficent on POSIX or near-POSIX platforms, yes.  I suppose
it might be slow on Windows, though I'm not a Windows expert.

> FYI, I've tested the following code on Debian GNU/Linux (sid) to check
> the efficiency.

Efficiency is not the primary concern here.  More important are:

1) Correctness.  The current code works if a parent directory is
   searchable but not readable; on many hosts, getcwd won't work in
   that situation.

2) Using nice names for the working directory in the presence of
   symbolic links.  For example, on my host:

     15-shade $ cd /reb
     16-shade $ echo $PWD
     /reb
     17-shade $ /bin/pwd
     /net/sic/export/ford/reb

   When Emacs starts up, I want the working directory to be "/reb", not
   "/net/sic/export/ford/reb".

Your benchmark indicates that Emacs needs to spend one microsecond to
get the nicer name on your host; that's a win in my book.

> Therefore, I'd like to propose to remove this hacked optimization
> from init_buffer().

I'd rather leave it in, for the above reasons.  However, the code's
comment was misleading since it implies that the $PWD code is there
purely for optimization purposes.  It is faster on many traditional
hosts (for example, it is faster on my Solaris 8 host) but you're
correct that it's not faster on GNU/Linux hosts.

I have checked in a fix to the comment, so that it looks like this
instead:

  /* If PWD is accurate, use it instead of calling getwd.  PWD is
     sometimes a nicer name, and using it may avoid a fatal error if a
     parent directory is searchable but not readable.  */

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

> Efficiency is not the primary concern here.  More important are:

...snip...

> Your benchmark indicates that Emacs needs to spend one microsecond to
> get the nicer name on your host; that's a win in my book.

O.K.  In short, this code is not mainly for optimization, but rather in
order to receive more appropriate pathname from the shell (or any other
invoking program).  I agree on it.

So we should change the comment not to misunderstand the intention.  Thanks.

BTW, on Windows, the current code dose not works correctly because of stat() problem.
In the current implemenation, stat() always return the same value as inode.  Please
see the following, which is cut from stat()@w32.c.

  if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
    {
      buf->st_mode = _S_IFDIR;
      buf->st_nlink = 2;	/* doesn't really matter */
      fake_inode = 0;		/* this doesn't either I think */
    }

I think we have three choices to solve it.

(1) Generate a proper inode value as well as for the directory
(2) At the startup, set "PWD" env. to the value of getcwd().
(3) Use always getcwd() when WINDOWSNT(or DOS_NT?) is defined.

As for (1), generate fake_inode from the value of FileIndex obtained
by GetFileInformationByHandle().
But on WINDOWSNT, I'd like to apply (3) change too because on W32
we don't have to (or should not) take such rather profound intentions
into considerations.

  With regards,

from himi

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@m17n.org>
> Date: Wed, 24 Apr 2002 15:52:06 +0900

> But on WINDOWSNT, I'd like to apply (3) change too because on W32
> we don't have to (or should not) take such rather profound intentions
> into considerations.

But don't similar issues arise in Windows ports?

For example, I know that Windows sometimes plays funky games with
letter case in file names.  Suppose the user prefers one case for the
directory name, and sets PWD accordingly.  Won't the user be annoyed if
Emacs uses the different case returned by getcwd?

Similarly, suppose the Windows directory has a mangled file name that
is returned by getcwd, but the user prefers the non-mangled name in
$PWD.

Also, are permissions problems ever an issue on Windows platforms?  In
Unix and GNU/Linux, getcwd can fail because a parent directory is not
readable, and that is an argument for preferring $PWD to getcwd.  Is
such a getcwd failure possible in Windows?

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

> But don't similar issues arise in Windows ports?

I think the answer is "No".

Windows dose not have symbolic link and if the current directory
permission dose not allow to enter, we cannot invoke any programs.

> For example, I know that Windows sometimes plays funky games with
> letter case in file names.  Suppose the user prefers one case for the
> directory name, and sets PWD accordingly.  Won't the user be annoyed if
> Emacs uses the different case returned by getcwd?
> Similarly, suppose the Windows directory has a mangled file name that
> is returned by getcwd, but the user prefers the non-mangled name in
> $PWD.

Unfortunately or fortunately, almost all of Windows programs do not
are "PWD" environment variable.  So we won't obtain better pathname
from "PWD".

And top of that, accoding to my test, GetCurrentDirectory()
holds the straightforward value set by SetCurrentDirectory().
So we don't have to take care of "PWD", and should always use the value of
GetCurrentDirectory().
(Note that GetCurrentDirectory() is W32 API used by getcwd())

You can see the behavior by something like the following code.
--------------------------------------------------------------------------------
#include <windows.h>

int main(int argc, char **argv)
{
  char buf[_MAX_PATH];
  SetCurrentDirectory("c:\\PROGRA~1");
  GetCurrentDirectory(sizeof(buf), buf);
  printf ("GetCurrentDirectory1:%s\n", buf);
  SetCurrentDirectory("c:\\Program Files");
  GetCurrentDirectory(sizeof(buf), buf);
  printf ("GetCurrentDirectory2:%s\n", buf);
}
--------------------------------------------------------------------------------

> Also, are permissions problems ever an issue on Windows platforms?  In
> Unix and GNU/Linux, getcwd can fail because a parent directory is not
> readable, and that is an argument for preferring $PWD to getcwd.  Is
> such a getcwd failure possible in Windows?

If it is, we cannot invoke Emacs because CreateProcess() API would fail. ;-)

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

On Wed, 24 Apr 2002, MIYASHITA Hisashi wrote:

> Windows dose not have symbolic link and if the current directory
> permission dose not allow to enter, we cannot invoke any programs.

True for now.  But suppose we introduce into Emacs support for 
Cygwin-style symlinks some day--are we supposed to go through all the 
primitives and invent Windows-specific code to handle that?

I think computing a simulated inode for a directory is much simpler, and 
will work for a broader class of potential changes in the underlying 
filesystem and in Emacs.  The code already exists, it just needs to be 
activated by removing the #if 0 conditional.  I fail to understand why 
are we still arguing...

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 24 Apr 2002, MIYASHITA Hisashi wrote:
>
>> Windows dose not have symbolic link and if the current directory
>> permission dose not allow to enter, we cannot invoke any programs.
>
> True for now.  But suppose we introduce into Emacs support for 
> Cygwin-style symlinks some day--are we supposed to go through all the 
> primitives and invent Windows-specific code to handle that?

But even if it is true, I previously said that GetCurrentDirectory()
holds the straightforward values set by SetCurrentDirectory(), so we don't
have to stick to "PWD" environemt variable that may be different from
the value of "PWD".  Furthermore, in this view, I think that we MUST NOT
use "PWD" environment variable to obtain the current directory because
it's never standardized.

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Wed, 24 Apr 2002 19:30:35 +0900
> 
> > True for now.  But suppose we introduce into Emacs support for 
> > Cygwin-style symlinks some day--are we supposed to go through all the 
> > primitives and invent Windows-specific code to handle that?
> 
> But even if it is true, I previously said that GetCurrentDirectory()
> holds the straightforward values set by SetCurrentDirectory(), so we don't
> have to stick to "PWD" environemt variable that may be different from
> the value of "PWD".

It's something for the user to decide, I think.  For example, I'm
guessing that GetCurrentDirectory returns a file name with backslashes
and might have some weird letter-case conversions applied to it; users
might not want that.

> Furthermore, in this view, I think that we MUST NOT use "PWD"
> environment variable to obtain the current directory because it's
> never standardized.

Do you know of some Windows application that uses PWD in an
incompatible fashion?  I use Windows for quite some time, and have
never seen such a beast.  The only applications that use PWD are
ported Unix and GNU tools, and they all use it in a consistent manner.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> Furthermore, in this view, I think that we MUST NOT use "PWD"
>> environment variable to obtain the current directory because it's
>> never standardized.
>
> Do you know of some Windows application that uses PWD in an
> incompatible fashion?  I use Windows for quite some time, and have
> never seen such a beast.  The only applications that use PWD are
> ported Unix and GNU tools, and they all use it in a consistent manner.

Almost all of the Windows application do not care about "PWD".  
I can imagin many bad situations.  Suppose the following
situation as an example.

(1) sh or tcsh set "PWD" and the current directory to "c:/PROGRA~1" (this name is
    the short name of "c:/Program Files"), and then invokes a program.

(2) the invoked program set the current directory to "c:/Program Files"
    by SetCurrentDirectory().

(3) then it invokes Emacs.

I confirmed that by invoking tcsh.exe -> cmd.exe -> emacs.exe.

In this case, Emacs set the default directory to "c:/PROGRA~1", which is clearly
different from the expected value.  On the other hand, accoding to POSIX standard,
it's imperative that "PWD" be appropriately set by shell.  And convensionally,
"PWD" is often used to refer current directory on many UNIX systems.  Therefore
Such problem seldom occurs.  Thus, I can agree on the current code on many
UNIX systems.  And surely it's convenient.
(But I remember that some old shells (old bash or tcsh) did not set "PWD"
 environment variable on UNIX. ;-)

On Windows, however, it's not only useless but also harmful, I think.

The above case is an example to affirm relying on "PWD" by obscure convension
is maybe harmful.  Furthermore, the original code is not easy to understand and
seems very platform dependent.  I don't think the follwing change makes
the matters worse.

#if !defined(WINDOWSNT)   /* I think this condition will include more non-POSIX systems
                             in the future. */
  if ((pwd = getenv ("PWD")) != 0
      && (IS_DIRECTORY_SEP (*pwd) || (*pwd && IS_DEVICE_SEP (pwd[1])))
      && stat (pwd, &pwdstat) == 0
      && stat (".", &dotstat) == 0
      && dotstat.st_ino == pwdstat.st_ino
      && dotstat.st_dev == pwdstat.st_dev
      && strlen (pwd) < MAXPATHLEN)
    strcpy (buf, pwd);
  else 
#else
   {
#ifdef HAVE_GETCWD 
     if (getcwd (buf, MAXPATHLEN+1) == 0)
       fatal ("`getcwd' failed: %s\n", strerror (errno));
#else
    else if (getwd (buf) == 0)
      fatal ("`getwd' failed: %s\n", buf);
#endif
  }
#endif

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA
> Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Thu, 25 Apr 2002 02:13:30 +0900
> 
> I can imagin many bad situations.  Suppose the following
> situation as an example.
> 
> (1) sh or tcsh set "PWD" and the current directory to "c:/PROGRA~1"
> (1) (this name is
>     the short name of "c:/Program Files"), and then invokes a
> (1) program.
> 
> (2) the invoked program set the current directory to "c:/Program
> (2) Files"
>     by SetCurrentDirectory().
> 
> (3) then it invokes Emacs.
> 
> I confirmed that by invoking tcsh.exe -> cmd.exe -> emacs.exe.
> 
> In this case, Emacs set the default directory to "c:/PROGRA~1",
> which is clearly
> different from the expected value.

I can throw together an example where the opposite is true: the value
of PWD is better than what GetCurrentDirectory returns.

In any case, both c:/PROGRA~1 and c:/Program Files point to the same
directory, so this is at best an aesthetic annoyance.

> I can agree on the current code on many
> UNIX systems.  And surely it's convenient.
> 
> On Windows, however, it's not only useless but also harmful, I
> think.

OTOH, differences in behavior on different platforms are not a good
idea, either.  It makes the documentation either confusing or
incorrect, and it confuses people who need to work on several
different platforms.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Eli Zaretskii <eliz@fencepost.gnu.org> writes:

> I can throw together an example where the opposite is true: the value
> of PWD is better than what GetCurrentDirectory returns.

But "PWD" is NOT cared by almost all of the Windows application.
On the contrary, Get/SetCurrentDirectory() is always cared.

> OTOH, differences in behavior on different platforms are not a good
> idea, either.  It makes the documentation either confusing or
> incorrect, and it confuses people who need to work on several
> different platforms.

I don't think it's a difference.  I believe that users only want to set 
the prefered current directory, and it's best to use getcwd()
to realize that at least on Windows.

  With regards,

from himi

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Thu, 25 Apr 2002 02:13:30 +0900

> I can imagin many bad situations.  Suppose the following
> situation as an example.
> 
> (1) sh or tcsh set "PWD" and the current directory to "c:/PROGRA~1"

This should happen only if either:

 A) the user types "cd c:/PROGRA~1"; or
 B) getcwd returns "c:/PROGRA~1" when sh starts up.

In case A), the user has indicated a preference for the name "c:/PROGRA~1",
so that is a better name for Emacs to use.

In case B), there's no difference between using PWD and using getcwd,
so there's no problem.


> On Windows, however, it's not only useless but also harmful, I think.

I don't see any extra harm in Windows.  The situation is similar to
that on Unix.

The Unix convention is that PWD is the preferred name for the working
directory.  Most Unix shells obey this convention.  A few older shells
don't, and in that case the user gets a name other than the preferred
name; but the name still works so it's not a major problem.

Windows seems quite similar here, once we fix the bug in w32.c.


> The above case is an example to affirm relying on "PWD" by obscure
> convension is maybe harmful.

It's not an obscure convention; it's in the POSIX standard.

All other things being equal, it's better for w32.c to provide POSIX
behavior; that isolates the Windows-specific stuff into w32.c instead
of requiring Windows-specific changes to the rest of the code.  eliz
has proposed a fix along those lines, and this seems preferable to me
as well.


> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@m17n.org>
> Date: Thu, 25 Apr 2002 03:25:57 +0900
> 
> But "PWD" is NOT cared by almost all of the Windows application.
> On the contrary, Get/SetCurrentDirectory() is always cared.

This is like Unix.  On Unix, most applications don't use $PWD; they
use the working directory.  The only applications that set and use
$PWD are those that care about using a "nice" name for the working
directory.

The situations seem to be analogous.  In both systems, you can
have multiple names for the same directory (because of symbolic
links, or file name mangling, or backslashifying, or whatever).
It's nice to use the user's preferred name for a directory even
if it is not canonical, and $PWD is the standard way to do this.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

> This should happen only if either:
>
>  A) the user types "cd c:/PROGRA~1"; or
>  B) getcwd returns "c:/PROGRA~1" when sh starts up.
>
> In case A), the user has indicated a preference for the name "c:/PROGRA~1",
> so that is a better name for Emacs to use.
>
> In case B), there's no difference between using PWD and using getcwd,
> so there's no problem.

Why are they no problem?  In the example I offered, after doing it, user
type "cd c:/Program Files" during cmd.exe session.  But Emacs set the
default directory to "c:/PROGRA~1".  It must be a problem.

I can imagin lots of similar cases in plausible user operations.
For example, a user may like to invoke explorer.exe to browse a
directory and then invoke emacs.exe by the invoked explorer.exe.
If the user uses a normal pathname on tcsh.exe but uses UNC pathname
to specify the current directory for emacs.exe on explorer.exe, and
those locations are the same.  The user will encounter a problem.

>> The above case is an example to affirm relying on "PWD" by obscure
>> convension is maybe harmful.
>
> It's not an obscure convention; it's in the POSIX standard.

Also I've already said that in the previous mail.

>> But "PWD" is NOT cared by almost all of the Windows application.
>> On the contrary, Get/SetCurrentDirectory() is always cared.
>
> This is like Unix.  On Unix, most applications don't use $PWD; they
> use the working directory.  The only applications that set and use
> $PWD are those that care about using a "nice" name for the working
> directory.

I disagree on it.  According to my knowledge, lots of Unix applications
use "PWD".  Almost all of shells set "PWD" properly.  But on Windows, even
the standard shell program, "cmd.exe" dose not set "PWD".

  With regards,

from himi

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

MIYASHITA Hisashi(宮下 尚:HIMI) <himi@meadowy.org> writes:

> Paul Eggert <eggert@twinsun.com> writes:
>
>> It's not an obscure convention; it's in the POSIX standard.
>
> Also I've already said that in the previous mail.

Note that Windows never be POSIX2 compliant system.
Windows NT has POSIX subsystem that compliant to POSIX1,
never to POSIX2.  Furthermore, the POSIX subsystem is not
fully compatible with W32 environment.  Of course, Emacs
dose not use the subsystem.

from himi

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi <himi@meadowy.org>
> Date: Thu, 25 Apr 2002 04:41:15 +0900
> 
> Why are they no problem?  In the example I offered, after doing it, user
> type "cd c:/Program Files" during cmd.exe session.  But Emacs set the
> default directory to "c:/PROGRA~1".

That is a different scenario.  In this new scenario, you first use a
POSIX shell to set a preferred name with PWD.  You then use a
non-POSIX shell to change the working directory to a different name
for the same directory, without also setting PWD.

Yes, in this case, Emacs will use PWD rather than the name you
specified to the non-POSIX shell.  But this also happens on Unix
platforms with non-POSIX shells.  It is not a problem that is specific
to Windows.  And once we fix the bug in w32.c it will not be that
serious a problem, since Windows Emacs will act like GNU/Linux or Unix
Emacs in this situation.

> > On Unix, most applications don't use $PWD; they use the working
> > directory.  The only applications that set and use $PWD are those
> > that care about using a "nice" name for the working directory.
> 
> I disagree on it.  According to my knowledge, lots of Unix applications
> use "PWD".

Some do, but most don't.  For example, GNU 'tar' doesn't, even though
it uses getcwd (in order to implement the -C option).

> Almost all of shells set "PWD" properly.  But on Windows, even
> the standard shell program, "cmd.exe" dose not set "PWD".

On Solaris 8, the standard shell program /bin/sh is not a POSIX shell,
and it does not set PWD.  The situations are analogous.  I still don't
see why Windows should be treated differently.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

> Yes, in this case, Emacs will use PWD rather than the name you
> specified to the non-POSIX shell.  But this also happens on Unix
> platforms with non-POSIX shells.  It is not a problem that is specific
> to Windows.  And once we fix the bug in w32.c it will not be that
> serious a problem, since Windows Emacs will act like GNU/Linux or Unix
> Emacs in this situation.

I can't understand why you stick to "PWD" environment variable on Windows.
The information almost all of the application dose not set is so important?

On Unix, shell and lots of programs usually put "nicer" pathname to "PWD".
On Windows, most programs put "nicer" pathname to Get/SetCurrentDirectory().

Could you agree on this simple statement?
Otherwise, would you really make convenience for few applications
that set "PWD".  To make matters worse, because of such applications,
"PWD" may has wrong value, thus it may make displeasing inconvenience for
most applications that don't set "PWD".

>> > On Unix, most applications don't use $PWD; they use the working
>> > directory.  The only applications that set and use $PWD are those
>> > that care about using a "nice" name for the working directory.
>> 
>> I disagree on it.  According to my knowledge, lots of Unix applications
>> use "PWD".
>
> Some do, but most don't.  For example, GNU 'tar' doesn't, even though
> it uses getcwd (in order to implement the -C option).
>
>> Almost all of shells set "PWD" properly.  But on Windows, even
>> the standard shell program, "cmd.exe" dose not set "PWD".
>
> On Solaris 8, the standard shell program /bin/sh is not a POSIX shell,
> and it does not set PWD.  The situations are analogous.  I still don't
> see why Windows should be treated differently.

And then, why do you use getcwd() instead of "PWD" on Unix?  It's because
getcwd() normalize pathname, and it's incovenient for many users, isn't it?

But Windows never normalize pathname set by SetCurrentDirectory().  So users
would not encounter the problem if we switch to use getcwd().  And I think it's
more convenient on Windows.

  With regards,

from himi

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi <himi@meadowy.org>
> Date: Thu, 25 Apr 2002 05:41:37 +0900
> 
> I can't understand why you stick to "PWD" environment variable on Windows.
> The information almost all of the application dose not set is so important?

Yes, it's important; and once w32.c is fixed it will not be ignored.

> On Unix, shell and lots of programs usually put "nicer" pathname to "PWD".
> On Windows, most programs put "nicer" pathname to Get/SetCurrentDirectory().

On Windows, if I pass a string to SetCurrentDirectory, and then later
inquire about the string with GetCurrentDirectory, do I always get the
same string back, no matter how it was spelled?  Or do some Windows
platforms return a munged copy of the original string?  If the latter,
then there will be some cases where PWD will be nicer than
GetCurrentDirectory.

> Otherwise, would you really make convenience for few applications
> that set "PWD".  To make matters worse, because of such applications,
> "PWD" may has wrong value

Once w32.c is fixed, the worst that will happen is that Emacs will use
some other name for the working directory, a name that the user
specified at some point (though perhaps not the most recently).  I
don't see this as being a major problem, any more than I see that it's
a major problem that a similar thing happens on Unix.

> > On Solaris 8, the standard shell program /bin/sh is not a POSIX shell,
> > and it does not set PWD.  The situations are analogous.
> 
> And then, why do you use getcwd() instead of "PWD" on Unix?  It's because
> getcwd() normalize pathname, and it's incovenient for many users, isn't it?

Many applications use getcwd because of inertia: getcwd predates PWD.
Also, PWD is more of a pain to get right, so many applications don't
bother to use it since they don't display the name to the user; GNU
'tar' is in this category.

However, programs like Emacs and the shells do tend to use PWD,
because they often present the working directory's name to the user,
and it's more important for them to use a "nice" name.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

>> I can't understand why you stick to "PWD" environment variable on Windows.
>> The information almost all of the application dose not set is so important?
>
> Yes, it's important; and once w32.c is fixed it will not be ignored.

This word forcibly reminds me that it was very hard for me to
persuade Emacs developpers on the issues of Windows.  I think we
should even remove such hard-to-understand code in purely technical view.
But I think users' convenience takes the highest priority, I can agree
on the code.

>> On Unix, shell and lots of programs usually put "nicer" pathname to "PWD".
>> On Windows, most programs put "nicer" pathname to Get/SetCurrentDirectory().
>
> On Windows, if I pass a string to SetCurrentDirectory, and then later
> inquire about the string with GetCurrentDirectory, do I always get the
> same string back, no matter how it was spelled?  Or do some Windows
> platforms return a munged copy of the original string?  If the latter,
> then there will be some cases where PWD will be nicer than
> GetCurrentDirectory.

I've tested that in the previous mail, please see it.

>> Otherwise, would you really make convenience for few applications
>> that set "PWD".  To make matters worse, because of such applications,
>> "PWD" may has wrong value
>
> Once w32.c is fixed, the worst that will happen is that Emacs will use
> some other name for the working directory, a name that the user
> specified at some point (though perhaps not the most recently).  I
> don't see this as being a major problem, any more than I see that it's
> a major problem that a similar thing happens on Unix.

But I think we should not ignore the case by pervading such bizarre code
to any platforms.

>> > On Solaris 8, the standard shell program /bin/sh is not a POSIX shell,
>> > and it does not set PWD.  The situations are analogous.
>> 
>> And then, why do you use getcwd() instead of "PWD" on Unix?  It's because
>> getcwd() normalize pathname, and it's incovenient for many users, isn't it?
>
> Many applications use getcwd because of inertia: getcwd predates PWD.
> Also, PWD is more of a pain to get right, so many applications don't
> bother to use it since they don't display the name to the user; GNU
> 'tar' is in this category.
>
> However, programs like Emacs and the shells do tend to use PWD,
> because they often present the working directory's name to the user,
> and it's more important for them to use a "nice" name.

I hope that you had quater tenderness for Windows users ;-)

  With regards,

from himi

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

MIYASHITA Hisashi(宮下 尚:HIMI) <himi@meadowy.org> writes:

>> Yes, it's important; and once w32.c is fixed it will not be ignored.
>
> This word forcibly reminds me that it was very hard for me to
> persuade Emacs developpers on the issues of Windows.  I think we
> should even remove such hard-to-understand code in purely technical view.
> But I think users' convenience takes the highest priority, I can agree
> on the code.

How about splitting this part into a new function (like getcwd_preferable())
and moving it to sysdep.c?  Could you agree this?

from himi

Re: init_buffer PWD fix

[Stefan Monnier]

> I hope that you had quater tenderness for Windows users ;-)

Assuming that w32.c's stat function gets fixed, what is the actual problem
(from a user's perspective) with Emacs using PWD when available ?


	Stefan

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Thu, 25 Apr 2002 05:41:37 +0900
> 
> I can't understand why you stick to "PWD" environment variable on Windows.

Because it's generally a Good Thing to have the same behavior on all
platforms, unless it's preposterously wrong on some of them.

Re: init_buffer PWD fix

[Paul Eggert]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Wed, 24 Apr 2002 19:30:35 +0900
> 
> I think that we MUST NOT use "PWD" environment variable to obtain
> the current directory because it's never standardized.

I'm not sure what you mean by "it's never standardized".  PWD is part
of the POSIX standard.  It's true that one can have a problem when
mixing POSIX and non-POSIX shells, since the latter don't update PWD
and this can cause PWD to become incorrect; but this is becoming less
of an issue with time, and anyway Emacs does have a workaround for it.

It appears that people who use a POSIX-like environment in Windows are
likely to run into this issue, so the Windows port should act as much
as possible like a standard POSIX port.

I like the idea of fixing w32.c `stat' so that it returns a reasonable
inode for directories; that will fix the problem in general, not just here.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

>> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>>  <himi@meadowy.org>
>> Date: Wed, 24 Apr 2002 19:30:35 +0900
>> 
>> I think that we MUST NOT use "PWD" environment variable to obtain
>> the current directory because it's never standardized.
>
> I'm not sure what you mean by "it's never standardized".  PWD is part
> of the POSIX standard.

Yes, you are correct.  "PWD" is reserved and required to be set by shell on
POSIX compliant systems.  Of course, I supposed the case on Windows in
that mail.

>  It's true that one can have a problem when
> mixing POSIX and non-POSIX shells, since the latter don't update PWD
> and this can cause PWD to become incorrect; but this is becoming less
> of an issue with time, and anyway Emacs does have a workaround for it.

It's one of problems when using Cygwin on Windows ;-).

  With regards,

from himi

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Eli Zaretskii <eliz@is.elta.co.il> writes:

>> Windows dose not have symbolic link and if the current directory
>> permission dose not allow to enter, we cannot invoke any programs.
>
> True for now.  But suppose we introduce into Emacs support for 
> Cygwin-style symlinks some day--are we supposed to go through all the 
> primitives and invent Windows-specific code to handle that?

Hmm...  Sorry, I might partly misread this passage.  Would you like to
set the default directory that is not compatible with Windows API?  If
it's correct, what I said in the previous mail is not correct because 
SetCurrentDirectory() would fail.

But, in this situation(to support Cygwin Symlink), do we have to simply
port Emacs to Cygwin API complient?  I doubt that it's useful...

  With regards,

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Wed, 24 Apr 2002 19:38:41 +0900
> 
> But, in this situation(to support Cygwin Symlink), do we have to simply
> port Emacs to Cygwin API complient?

It's possible to support Cygwin-style symlinks without building Emacs
as a Cygwin application.  (Cygwin symlinks are simply text files with
a special signature recognized and handled by the library primitives.)

Anyway, that was only an example; I don't know about any work being
done on adding such support to Emacs.  The main point is that having
`stat' that simulates inode numbers is useful in a variety of
situations, and reduces maintenance burden in the long run.

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Wed, 24 Apr 2002 19:38:41 +0900
> 
> But, in this situation(to support Cygwin Symlink), do we have to simply
> port Emacs to Cygwin API complient?

It's possible to support Cygwin-style symlinks without building Emacs
as a Cygwin application.  (Cygwin symlinks are simply text files with
a special signature recognized and handled by the library primitives.)

Anyway, that was only an example; I don't know about any work being
done on adding such support to Emacs.  The main point is that having
`stat' that simulates inode numbers is useful in a variety of
situations, and reduces maintenance burden in the long run.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Paul Eggert <eggert@twinsun.com> writes:

> Also, are permissions problems ever an issue on Windows platforms?  In
> Unix and GNU/Linux, getcwd can fail because a parent directory is not
> readable, and that is an argument for preferring $PWD to getcwd.  Is
> such a getcwd failure possible in Windows?

Note that on Windows, we can successfully get the current directory
if we can enter it, to the contrary on Unix, we fail to getcwd() if the
current directory is not readable.

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

On Wed, 24 Apr 2002, Paul Eggert wrote:

> For example, I know that Windows sometimes plays funky games with
> letter case in file names.  Suppose the user prefers one case for the
> directory name, and sets PWD accordingly.  Won't the user be annoyed if
> Emacs uses the different case returned by getcwd?
> 
> Similarly, suppose the Windows directory has a mangled file name that
> is returned by getcwd, but the user prefers the non-mangled name in
> $PWD.

All true and important, IMHO.  Add the slash/backslash schizophreny to it 
as well.

> Also, are permissions problems ever an issue on Windows platforms?  In
> Unix and GNU/Linux, getcwd can fail because a parent directory is not
> readable, and that is an argument for preferring $PWD to getcwd.  Is
> such a getcwd failure possible in Windows?

I don't think so, but I don't think we should hardwire such assumptions 
into Emacs if we can do better by changing a single function in w32.c.

Re: init_buffer PWD fix

[Eli Zaretskii]

On Wed, 24 Apr 2002, MIYASHITA Hisashi wrote:

> (1) Generate a proper inode value as well as for the directory
> (2) At the startup, set "PWD" env. to the value of getcwd().
> (3) Use always getcwd() when WINDOWSNT(or DOS_NT?) is defined.

No, please don't use DOS_NT: it is defined in the MS-DOS port as well, 
where `stat' does return a unique inode for a directory.

> As for (1), generate fake_inode from the value of FileIndex obtained
> by GetFileInformationByHandle().

You cannot do that for directories, because GetFileInformationByHandle 
needs a handle, and Windows doesn't let you open a directory and get a 
file handle for it.

> But on WINDOWSNT, I'd like to apply (3) change too because on W32
> we don't have to (or should not) take such rather profound intentions
> into considerations.

I disagree.  I think it's very important that the Windows port tries to 
return more-or-less meaningful inode numbers, so that we don't have to 
devise a special kludge for each Emacs primitive that needs an inode.

Re: init_buffer PWD fix

[MIYASHITA Hisashi]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> You cannot do that for directories, because GetFileInformationByHandle 
> needs a handle, and Windows doesn't let you open a directory and get a 
> file handle for it.

It's partly incorrect.  We can obtain handle also for directory at least on
Windows NT/2000/XP (I've already tested it).  But on Windows 9x/Me, I remember
that it is unable to obtain directory handle.

from himi

Re: init_buffer PWD fix

[Eli Zaretskii]

> From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=)
>  <himi@meadowy.org>
> Date: Wed, 24 Apr 2002 19:31:08 +0900
> 
> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> > You cannot do that for directories, because GetFileInformationByHandle 
> > needs a handle, and Windows doesn't let you open a directory and get a 
> > file handle for it.
> 
> It's partly incorrect.  We can obtain handle also for directory at least on
> Windows NT/2000/XP

Good--that means Emacs can use GetFileInformationByHandle on those
systems, and fall back on inventing inodes on Windows 9X only.

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Keiichiro Nagano wrote:

> init_buffer uses environmental variable PWD to identify current
> working directory.  I think we should not use it on Windows.  On
> Windows with Cygwin, PWD is unreliable and confusing, because
> 
> * Cygwin bash treats it
> * Cygwin sh (ash) doesnot
> * to say nothing of command.com, cmd.exe, nmake.exe and so on

Sorry, I don't understand the problem.  command.com. cmd.exe etc. don't 
set PWD, so the current Emacs code should DTRT.  I don't know about ash; 
are you saying that it sets PWD to the wrong value?

It's impossible to evaluate your suggestion without understanding the 
details.  Please describe those details.  Thanks in advance.

Re: init_buffer PWD fix

[Keiichiro Nagano]

At Mon, 22 Apr 2002 10:03:22 +0300 (IDT),
Eli Zaretskii wrote:
> > init_buffer uses environmental variable PWD to identify current
> > working directory.  I think we should not use it on Windows.  On
> > Windows with Cygwin, PWD is unreliable and confusing, because
> > 
> > * Cygwin bash treats it
> > * Cygwin sh (ash) doesnot
> > * to say nothing of command.com, cmd.exe, nmake.exe and so on
> 
> Sorry, I don't understand the problem.  command.com. cmd.exe etc. don't 
> set PWD, so the current Emacs code should DTRT.  I don't know about ash; 
> are you saying that it sets PWD to the wrong value?

No.  Cygwin sh (ash) is a lightweight Bourne shell, which does not
update PWD even when it does chdir.  Child processes inherit
environmental variables from their parent processes.  So when you
invoke ash from bash, and do 'cd' in ash, then you have an old and now
wrong PWD.  Same problems happen when you invoke command.com, cmd.exe,
nmake.exe from the bash shell.

> It's impossible to evaluate your suggestion without understanding the 
> details.  Please describe those details.  Thanks in advance.

Ok.

--
bash$ printenv PWD		# in bash...
/home				# now i'm here
bash$ cd work			# chdir to work...
bash$ printenv PWD		# and PWD is updated
/home/work			# it's ok
bash$ sh			# invoke sh (ash)...
sh$ cd ..			# and chdir to /home...
sh$ printenv PWD		# how about the PWD?
/home/work			# Oh God!
--

Same problems happen quite often when you 'make' Emacs Lisp products
which have chdir in their 'Makefile's.

-- 
Keiichiro Nagano

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Keiichiro Nagano wrote:

> Cygwin sh (ash) is a lightweight Bourne shell, which does not
> update PWD even when it does chdir.  Child processes inherit
> environmental variables from their parent processes.  So when you
> invoke ash from bash, and do 'cd' in ash, then you have an old and now
> wrong PWD.

Thanks for the explanation.  But I still don't see how this would cause a 
specific failure in Emacs in some situation.  Can you describe such a 
specific failure, complete with the commands to type outside and inside 
Emacs, and with analysis of what happens inside init_buffer in that case?

> Same problems happen when you invoke command.com, cmd.exe,
> nmake.exe from the bash shell.

Since these programs ignore PWD, I don't see how can this do any harm.  
Again, a specific example will help.

> bash$ cd work			# chdir to work...
> bash$ printenv PWD		# and PWD is updated
> /home/work			# it's ok
> bash$ sh			# invoke sh (ash)...
> sh$ cd ..			# and chdir to /home...
> sh$ printenv PWD		# how about the PWD?
> /home/work			# Oh God!

Yes, I understand this much, but how does this affect Emacs?  You are 
suggesting a change in Emacs, not in Bash or ash.

The mere fact that "printenv PWD" prints a wrong directory is not in 
itself a problem, especially not a problem for Emacs.

> Same problems happen quite often when you 'make' Emacs Lisp products
> which have chdir in their 'Makefile's.

What practical Emacs-related problems happen in those cases?  Can you 
give an example of such a case, and describe the problems you have with 
the current Emacs code in that specific example? 

TIA

Re: init_buffer PWD fix

[Keiichiro Nagano]

At Mon, 22 Apr 2002 11:01:27 +0300 (IDT),
Eli Zaretskii wrote:
> Thanks for the explanation.  But I still don't see how this would cause a 
> specific failure in Emacs in some situation.  Can you describe such a 
> specific failure, complete with the commands to type outside and inside 
> Emacs, and with analysis of what happens inside init_buffer in that case?

For instance,

0. in bash shell...
1. gunzip and untar emacs-21.2.tar.gz and leim-21.2.tar.gz
2. cd to emacs-21.2/nt, and run ./configure.bat.  If you have MSVC,
   configure.bat detects it and configure to use MSVC for compiling
   Emacs.
3. type nmake.  After you have done temacs.exe and emacs.exe, You
   will get an error like this:

        "C:\home\tmp\emacs-21.2\leim/../src/obj-spd/i386/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l C:/home/tmp/emacs-21.2/leim/../lisp/international/titdic-cnv  --eval "(batch-titdic-convert t)"  -dir quail ./CXTERM-DIC

Warning: arch-dependent data dir (c:/emacs/bin/) does not exist.
Warning: arch-independent data dir (c:/emacs/etc/) does not exist.
Converting c:/home/tmp/emacs-21.2/nt/CXTERM-DIC to quail-package...
Opening input file: no such file or directory, c:/home/tmp/emacs-21.2/nt/CXTERM-DIC
NMAKE : fatal error U1077: '"C:\home\tmp\emacs-21.2\leim/../src/obj-spd/i386/emacs.exe"' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\nmake.exe"' : return code '0x2'
Stop.

Why c:/home/tmp/emacs-21.2/nt/CXTERM-DIC?  CXTERM-DIC is at
c:/home/tmp/emacs-21.2/leim.  Because chdir ../leim is done in
makefile, and Emacs uses wrong PWD c:/home/tmp/emacs-21.2/nt to open
./CXTERM-DIC.  With the patch I post, this error will never happen.

Same problems happen quite often with Emacs Lisp products, for
example, T-gnus
(http://lists.airs.net/semi-gnus/archive/200101/msg00057.html if you
can read Japanese), whose 'Makefile's do chdir before try to invoke
Emacs to byte-compile '*.el's,

-- 
Keiichiro Nagano

Re: init_buffer PWD fix

[Eli Zaretskii]

On Mon, 22 Apr 2002, Keiichiro Nagano wrote:

> 3. type nmake.  After you have done temacs.exe and emacs.exe, You
>    will get an error like this:
> 
>         "C:\home\tmp\emacs-21.2\leim/../src/obj-spd/i386/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l C:/home/tmp/emacs-21.2/leim/../lisp/international/titdic-cnv  --eval "(batch-titdic-convert t)"  -dir quail ./CXTERM-DIC
> 
> Warning: arch-dependent data dir (c:/emacs/bin/) does not exist.
> Warning: arch-independent data dir (c:/emacs/etc/) does not exist.
> Converting c:/home/tmp/emacs-21.2/nt/CXTERM-DIC to quail-package...
> Opening input file: no such file or directory, c:/home/tmp/emacs-21.2/nt/CXTERM-DIC
> NMAKE : fatal error U1077: '"C:\home\tmp\emacs-21.2\leim/../src/obj-spd/i386/emacs.exe"' : return code '0xffffffff'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\VC98\bin\nmake.exe"' : return code '0x2'
> Stop.
> 
> Why c:/home/tmp/emacs-21.2/nt/CXTERM-DIC?  CXTERM-DIC is at
> c:/home/tmp/emacs-21.2/leim.  Because chdir ../leim is done in
> makefile, and Emacs uses wrong PWD c:/home/tmp/emacs-21.2/nt to open
> ./CXTERM-DIC.  With the patch I post, this error will never happen.

Thanks.

I think the proper fix for this is to make the test init_buffer does more 
reliable on Windows.  But I'll let Jason and Andrew decide what's the 
best course of action here.