From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: MIYASHITA Hisashi(=?ISO-2022-JP?B?GyRCNVwyPBsoQiAbJEI+MBsoQjpISU1J?=) Newsgroups: gmane.emacs.devel Subject: Re: init_buffer PWD fix Date: Wed, 24 Apr 2002 16:45:43 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200204220618.g3M6Icg23696@sic.twinsun.com> <200204231745.g3NHjCW00689@shade.twinsun.com> <200204240713.g3O7DgO17536@sic.twinsun.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1019634541 15170 127.0.0.1 (24 Apr 2002 07:49:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 07:49:01 +0000 (UTC) Cc: emacs-devel@gnu.org, knagano@sodan.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 170HWP-0003wL-00 for ; Wed, 24 Apr 2002 09:49:01 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 170HXx-0003yg-00 for ; Wed, 24 Apr 2002 09:50:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170HVf-0007qj-00; Wed, 24 Apr 2002 03:48:15 -0400 Original-Received: from meadow.scphys.kyoto-u.ac.jp ([130.54.54.165]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 170HTF-0007kW-00 for ; Wed, 24 Apr 2002 03:45:46 -0400 Original-Received: (qmail 31073 invoked from network); 24 Apr 2002 07:44:59 -0000 Original-Received: from meadow.scphys.kyoto-u.ac.jp (HELO MILCH.meadowy.org.meadowy.org) (root@130.54.54.165) by meadow.scphys.kyoto-u.ac.jp with SMTP; 24 Apr 2002 07:44:59 -0000 Original-To: Paul Eggert In-Reply-To: <200204240713.g3O7DgO17536@sic.twinsun.com> (Paul Eggert's message of "Wed, 24 Apr 2002 00:13:42 -0700 (PDT)") Original-Lines: 52 User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) (revision 11) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (i386-msvc-nt5.1.2600) MULE/5.0 (SAKAKI) Meadow/1.99 Alpha1 (AWOFUCHI) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3162 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3162 Paul Eggert 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 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