8:44 p.m.
Vin, Stephen,
I'm sorry if I've missed something here, but I cannot think of any benefit
from trying to identify whether a file is executable under windows. Surely
the sensible approach it to try and execute it if requested, and report any
resulting failures.
I appreciate that the Unix approach of having an "executable attribute" has
benefits. Furthermore programs like xemacs should obviously respect this
attribute. However windows does not have this attribute. The OS shell and
all other systems, assume that all files are executable.
I can see no end of problems with this proposed function. Where the function
successfully identifies an executable file there will be no benefit. Where
the function fails to recognise a file as executable, the user will
presumably be told that his / her file is not marked as executable. This
will presumably cause loads of grief and no benefit.
Cheers,
Steve
-----Original Message-----
From: ethersoft(a)gmail.com [mailto:ethersoft＠gmail.com] On Behalf Of Vin
Shelton
Sent: 29 April 2007 13:12
To: Stephen J. Turnbull
Cc: Steve Higham; Benson Margulies; xemacs-beta(a)xemacs.org
Subject: Re: [Bug: 21.4.20] Network Drives
On 4/29/07, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Steve Higham writes:
> My machine contains several perl scripts (*.pl) which are certainly
> executable. Can the "executable extension list" be modified as a
standard
> lisp variable?
No, that's precisely why I consider it bogus, even though I haven't
used Windows in years. The list is implicit in a series of if ... else
if ... clauses in the function.
On the other hand, since I haven't been using Windows, I'm unsure
whether there's a way to register an extension as executable, and how
XEmacs could determine that at runtime. So I need somebody who knows
about that kind of thing to look at it.
I looked at the function; you're right - it's totally bogus. There is
a registry key which defines file associations and we could
potentially use that. I'll investigate a bit further.
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:47 a.m.
New subject: [Bug: 21.4.20] Network Drives
"Steve Higham" <steve(a)sjlt.co.uk> writes:
Vin, Stephen,
I'm sorry if I've missed something here, but I cannot think of any
benefit from trying to identify whether a file is executable under
windows. Surely the sensible approach it to try and execute it if
requested, and report any resulting failures.
I appreciate that the Unix approach of having an "executable
attribute" has benefits. Furthermore programs like xemacs should
obviously respect this attribute. However windows does not have this
attribute. The OS shell and all other systems, assume that all files
are executable.
I can see no end of problems with this proposed function. Where the
function successfully identifies an executable file there will be no
benefit. Where the function fails to recognise a file as executable,
the user will presumably be told that his / her file is not marked
as executable. This will presumably cause loads of grief and no
benefit.
This afternoon I coded up 21.4 and 21.5 versions of a patch to check
the PATHEXT environment variable in mswindows_is_executable(). Those
patches are attached, largely for reference purposes. The patches
correct the existing XEmacs brain-damage where it thinks only .BAT,
.COM, .EXE and .CMD are valid executable suffixes.
On thinking it over, I've come to the conclusion that I think that
Steve Higham is right. Checking for executable access on windows is
fundamentally wrong.
Steve, try this simple patch to see if it gets past the access
problems on building a debug build with MSVC 2005:
--- src/nt.c~ 2007-04-29 21:31:57.000000000 -0400
+++ src/nt.c 2007-04-29 21:37:18.734375000 -0400
＠＠ -1642,18 +1642,7 ＠＠
else
permission = _S_IREAD | _S_IWRITE;
- if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
- permission |= _S_IEXEC;
- else
- {
- char * p = strrchr (name, '.');
- if (p != NULL &&
- (stricmp (p, ".exe") == 0 ||
- stricmp (p, ".com") == 0 ||
- stricmp (p, ".bat") == 0 ||
- stricmp (p, ".cmd") == 0))
- permission |= _S_IEXEC;
- }
+ permission |= _S_IEXEC;
buf->st_mode |= permission | (permission >> 3) | (permission >> 6);
Steve - please let me know how this works for you. I'm very
interested in fixing the problems you're seeing with your network
drives, so I hope this helps you make progress.
Thanks,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:57 p.m.
New subject: [Bug: 21.4.20] Network Drives
Vin,
Thanks for your help. It's really appreciated.
Your fix does not work. The stack dump is listed below. As you can see,
mswindows_stat (...) is not being called. This is using version 21.4.20
code. The crash is invoked by temacs as it happens during the build process.
My network drive issue has disappeared. This doesn't 100% surprise me. My
(home) network doesn't have a domain controller and I connect over a
wireless LAN. I believe there is some kind of race condition at login that
makes the network rights inconsistent.
I do dream of turning my server into a dedicated Linux box. Unfortunately
the kids insist on using it to play "The Simms" :-(
I still believe there is a network drive issue (with xemacs). This is
because Xemacs regarded a file as read only in the same (network) session,
that other editors could edit the file and successfully save the edited
version. It just means that I cannot investigate until the problem
reappears. I will keep you posted :-)
As you know, I am not convinced that this approach is sensible. Consider the
following scenario: -
I could download a CPAN Perl script "my_perl_script" and open it in xemacs.
However it will not execute because it has no extension. Even though Xemacs
has correctly recognised it as a Perl Script and invoked CPerl mode.
However trying to "execute" a my_book.doc file will work just fine and
launch Word.
This behaviour does not strike me as logical or helpful :-(
My fix of defining X_OK as 2 (under WIN32) is working fine and will enable
me to debug my drive issue if / when it reappears.
I've also come across another issue when building a DEBUG version of Xemacs
on MSVC. The (DEBUG) version of "close" throws an exception if an attempt is
made to close a file that is not open. This happens in the following places:
-
--- callproc.c 2007/04/30 20:36:25 1.2
***************
*** 430,436 ****
/* Close most of our fd's, but not fd[0]
since we will use that to read input from. */
close (filefd);
! if (fd1 >= 0)
close (fd1);
}
--- 430,436 ----
/* Close most of our fd's, but not fd[0]
since we will use that to read input from. */
close (filefd);
! if ((fd1 >= 0) && (fd1 != fd_error))
close (fd1);
}
*** dumper.c 2007/04/27 21:42:10 1.1
--- dumper.c 2007/04/28 08:36:54 1.2
***************
*** 1067,1073 ****
pdump_dump_root_objects ();
fclose (pdump_out);
! close (pdump_fd);
free (pdump_buf);
--- 1067,1073 ----
pdump_dump_root_objects ();
fclose (pdump_out);
! //close (pdump_fd); already closed by fclose (pdump_out)
free (pdump_buf);
Cheers,
Steve
msvcr80d.dll!_access_s(const char * path=0x0082a860, int amode=1)
Line 81 + 0x2f bytes C
msvcr80d.dll!_access(const char * path=0x0082a860, int amode=1)
Line 47 + 0xd bytes C
temacs.exe!locate_file_in_directory_mapper(char * fn=0x0082a860,
void * arg=0x0082a904) Line 1023 + 0x11 bytes C lread.c
temacs.exe!locate_file_map_suffixes(long filename=52548764, long
suffixes=51893316, int (char *, void *)* fun=0x010faa00, void *
arg=0x0082a904) Line 993 + 0xb bytes C lread.c
temacs.exe!locate_file_in_directory(long directory=52536612, long
str=52536436, long suffixes=51893316, long * storeptr=0x0082abe4, int
mode=1) Line 1089 + 0x16 bytes C lread.c
temacs.exe!locate_file(long path=52546504, long str=52536436, long
suffixes=51893316, long * storeptr=0x0082abe4, int mode=1) Line 1265 + 0x19
bytes C lread.c
temacs.exe!Fold_call_process_internal(int nargs=103, long *
args=0x0082ecc4) Line 224 + 0x22 bytes C callproc.c
temacs.exe!Ffuncall(int nargs=104, long * args=0x0082ecc0) Line
3558 + 0x10 bytes C eval.c
temacs.exe!Fapply(int nargs=6, long * args=0x0082ef48) Line 3811 +
0xd bytes C eval.c
temacs.exe!Ffuncall(int nargs=7, long * args=0x0082ef44) Line 3558
+ 0x10 bytes C eval.c
temacs.exe!execute_optimized_program(const unsigned char *
program=0x03210930, int stack_depth=9, long * constants_data=0x03201040)
Line 748 + 0x10 bytes C bytecode.c
temacs.exe!funcall_compiled_function(long fun=52436320, int
nargs=103, long * args=0x0082f234) Line 519 + 0x33 bytes C bytecode.c
temacs.exe!Ffuncall(int nargs=104, long * args=0x0082f230) Line
3572 + 0x11 bytes C eval.c
temacs.exe!Fapply(int nargs=6, long * args=0x0082f430) Line 3811 +
0xd bytes C eval.c
temacs.exe!Feval(long form=52546252) Line 3361 + 0x16 bytes C
eval.c
temacs.exe!Fprogn(long args=52546396) Line 775 + 0x9 bytes C
eval.c
temacs.exe!Fif(long args=52533520) Line 693 + 0x9 bytes C
eval.c
temacs.exe!Feval(long form=52533424) Line 3309 + 0xf bytes C
eval.c
temacs.exe!Fprogn(long args=52533304) Line 775 + 0x9 bytes C
eval.c
temacs.exe!Feval(long form=52533268) Line 3309 + 0xf bytes C
eval.c
temacs.exe!Fif(long args=52533256) Line 691 + 0x9 bytes C
eval.c
temacs.exe!Feval(long form=52533244) Line 3309 + 0xf bytes C
eval.c
temacs.exe!readevalloop(long readcharfun=52035992, long
sourcename=52019812, long (long)* evalfun=0x01072c60, int printflag=0) Line
1449 + 0x7 bytes C lread.c
temacs.exe!Fload_internal(long file=52019812, long noerror=16687156,
long nomessage=16687156, long nosuffix=16687156, long codesys=16687156, long
used_codesys=16687156) Line 737 + 0x17 bytes C lread.c
temacs.exe!Feval(long form=51995092) Line 3335 + 0x181 bytes C
eval.c
temacs.exe!condition_case_1(long handlers=16687252, long (long)*
bfun=0x01072c60, long barg=51995092, long (long, long)* hfun=0x01051360,
long harg=16687156) Line 1652 + 0x7 bytes C eval.c
temacs.exe!top_level_1(long dummy=16687156) Line 206 + 0x23 bytes
C cmdloop.c
temacs.exe!internal_catch(long tag=51778124, long (long)*
func=0x01051300, long arg=16687156, int * volatile threw=0x00000000) Line
1318 + 0x7 bytes C eval.c
temacs.exe!initial_command_loop(long load_me=52019812) Line 285 +
0x19 bytes C cmdloop.c
temacs.exe!STACK_TRACE_EYE_CATCHER(int argc=9, char * *
argv=0x00fe5f48, char * * envp=0x00fe3980, int restart=0) Line 2462 C
emacs.c
temacs.exe!main(int argc=9, char * * argv=0x00fe5f48, char * *
envp=0x00fe3980) Line 2832 C emacs.c
temacs.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C crtexe.c
temacs.exe!mainCRTStartup() Line 414 C crtexe.c
kernel32.dll!7d4e7d2a()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
-----Original Message-----
From: Vin Shelton [mailto:acs＠xemacs.org]
Sent: 30 April 2007 02:47
To: Steve Higham
Cc: 'Stephen J. Turnbull'; 'Benson Margulies'; xemacs-beta(a)xemacs.org
Subject: Re: [Bug: 21.4.20] Network Drives
"Steve Higham" <steve(a)sjlt.co.uk> writes:
Vin, Stephen,
I'm sorry if I've missed something here, but I cannot think of any
benefit from trying to identify whether a file is executable under
windows. Surely the sensible approach it to try and execute it if
requested, and report any resulting failures.
I appreciate that the Unix approach of having an "executable
attribute" has benefits. Furthermore programs like xemacs should
obviously respect this attribute. However windows does not have this
attribute. The OS shell and all other systems, assume that all files
are executable.
I can see no end of problems with this proposed function. Where the
function successfully identifies an executable file there will be no
benefit. Where the function fails to recognise a file as executable,
the user will presumably be told that his / her file is not marked
as executable. This will presumably cause loads of grief and no
benefit.
This afternoon I coded up 21.4 and 21.5 versions of a patch to check
the PATHEXT environment variable in mswindows_is_executable(). Those
patches are attached, largely for reference purposes. The patches
correct the existing XEmacs brain-damage where it thinks only .BAT,
.COM, .EXE and .CMD are valid executable suffixes.
On thinking it over, I've come to the conclusion that I think that
Steve Higham is right. Checking for executable access on windows is
fundamentally wrong.
Steve, try this simple patch to see if it gets past the access
problems on building a debug build with MSVC 2005:
--- src/nt.c~ 2007-04-29 21:31:57.000000000 -0400
+++ src/nt.c 2007-04-29 21:37:18.734375000 -0400
＠＠ -1642,18 +1642,7 ＠＠
else
permission = _S_IREAD | _S_IWRITE;
- if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
- permission |= _S_IEXEC;
- else
- {
- char * p = strrchr (name, '.');
- if (p != NULL &&
- (stricmp (p, ".exe") == 0 ||
- stricmp (p, ".com") == 0 ||
- stricmp (p, ".bat") == 0 ||
- stricmp (p, ".cmd") == 0))
- permission |= _S_IEXEC;
- }
+ permission |= _S_IEXEC;
buf->st_mode |= permission | (permission >> 3) | (permission >> 6);
Steve - please let me know how this works for you. I'm very
interested in fixing the problems you're seeing with your network
drives, so I hope this helps you make progress.
Thanks,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:14 a.m.
New subject: [Bug: 21.4.20] Network Drives
Hi, Steve,
First, thanks for the patches on closing file descriptors. I took
your patches, made a few changes and will submit something to
xemacs-patches quickly. I'll CC: you when I submit.
On 4/30/07, Steve Higham <steve(a)sjlt.co.uk> wrote:
Your fix does not work. The stack dump is listed below. As you can
see,
mswindows_stat (...) is not being called. This is using version 21.4.20
code. The crash is invoked by temacs as it happens during the build process.
Thanks for the stack trace - it was a big help.
mswindows_stat (...) is not being called
To be a bit more
precise, mswindows_stat() has already been called
before access() gets called. My thinko was that if the code had
already called ...stat(), a call to a function like access() would be
superfluous. After thinking it over a little bit, I'm back to
thinking that the right way to handle this (without significant code
surgery) is to redefine X_OK as you had previously suggested.
My fix of defining X_OK as 2 (under WIN32) is working fine and will
enable
me to debug my drive issue if / when it reappears.
... except you mean 4 (R_OK), right?
Here's the patch I'm currently trying out under Windows (native and
cygwin) and linux:
--- src/ChangeLog~ 2007-04-29 22:16:11.000000000 -0400
+++ src/ChangeLog 2007-05-01 22:20:19.218750000 -0400
＠＠ -0,0 +1,6 ＠＠
+2007-05-01 Vin Shelton <acs(a)xemacs.org>
+
+ * nt.c (mswindows_stat): Tie _S_IEXEC permission to read access.
+ (mswindows_fstat): Ditto.
+ * sysfile.h: Under Windows, define X_OK to be the same as R_OK.
+
Index: src/sysfile.h
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/sysfile.h,v
retrieving revision 1.9.2.1
diff -a -u -r1.9.2.1 sysfile.h
--- src/sysfile.h 2001/07/25 07:45:39 1.9.2.1
+++ src/sysfile.h 2007/05/02 18:38:51
＠＠ -261,12 +261,18 ＠＠
#endif
/* The following definitions are needed under Windows, at least */
-#ifndef X_OK
-# define X_OK 1
-#endif
-
#ifndef R_OK
# define R_OK 4
+#endif
+
+/* Under native Windows, there is no concept of execute permission,
+ so redefine execute permissions to be the same as read permission */
+#ifndef X_OK
+# ifdef WIN32_NATIVE
+# define X_OK R_OK
+# else
+# define X_OK 1
+# endif
#endif
#ifndef W_OK
Index: src/nt.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/nt.c,v
retrieving revision 1.21.2.4
diff -a -u -r1.21.2.4 nt.c
--- src/nt.c 2005/01/31 02:55:24 1.21.2.4
+++ src/nt.c 2007/05/02 18:39:05
＠＠ -1449,9 +1449,9 ＠＠
/* determine rwx permissions */
if (info.dwFileAttributes & FILE_ATTRIBUTE_READONLY)
- permission = _S_IREAD;
+ permission = _S_IREAD | _S_IEXEC;
else
- permission = _S_IREAD | _S_IWRITE;
+ permission = _S_IREAD | _S_IEXEC |_S_IWRITE;
if (info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
permission |= _S_IEXEC;
＠＠ -1638,22 +1638,12 ＠＠
/* determine rwx permissions */
if (wfd.dwFileAttributes & FILE_ATTRIBUTE_READONLY)
- permission = _S_IREAD;
+ permission = _S_IREAD | _S_IEXEC;
else
- permission = _S_IREAD | _S_IWRITE;
+ permission = _S_IREAD | _S_IEXEC |_S_IWRITE;
if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
permission |= _S_IEXEC;
- else
- {
- char * p = strrchr (name, '.');
- if (p != NULL &&
- (stricmp (p, ".exe") == 0 ||
- stricmp (p, ".com") == 0 ||
- stricmp (p, ".bat") == 0 ||
- stricmp (p, ".cmd") == 0))
- permission |= _S_IEXEC;
- }
buf->st_mode |= permission | (permission >> 3) | (permission >> 6);
Comments welcome.
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:46 p.m.
New subject: [Bug: 21.4.20] Network Drives
Hi Vin,
This all looks fine. I set X_OK to 0 on the basis that "if it exists, you
can execute it". I believe that testing for existence (0) is identical to
testing for read access (4). Detailed argument below.
According to the command "attrib /?" the valid file attributes are as
follows: -
S:\Dev\ConsoleTest>attrib /?
Displays or changes file attributes.
ATTRIB [+R | -R] [+A | -A ] [+S | -S] [+H | -H] [drive:][path][filename]
[/S [/D]]
+ Sets an attribute.
- Clears an attribute.
R Read-only file attribute.
A Archive file attribute.
S System file attribute.
H Hidden file attribute.
[drive:][path][filename]
Specifies a file or files for attrib to process.
/S Processes matching files in the current folder
and all subfolders.
/D Processes folders as well.
According to this, any file that exists allows read access.
Note that the WIN32 API does allow file permissions on a per file, per user
basis. File permissions do include "Read & Execute", "Read",
"Write" and
other permissions. According to MS, file permissions are only implemented
within the NTFS file system. They are not implemented within the FAT32 file
system.
Strictly speaking I believe this is incorrect. I believe that COM allows
developers to implement their own file systems that support File Permissions
(I haven't read the documentation for ages...). Therefore it may well be
possible to store an NTFS file (including permissions) inside a zip file
located on a FAT32 partition. I haven't tested this.
Opinion - I don't believe it is appropriate for the code we are discussing
to attempt to access file permissions. Please respond if you disagree.
Cheers,
Steve
-----Original Message-----
From: ethersoft(a)gmail.com [mailto:ethersoft＠gmail.com] On Behalf Of Vin
Shelton
Sent: 03 May 2007 02:15
To: Steve Higham
Cc: Stephen J. Turnbull; Benson Margulies; xemacs-beta(a)xemacs.org
Subject: Re: [Bug: 21.4.20] Network Drives
Hi, Steve,
First, thanks for the patches on closing file descriptors. I took
your patches, made a few changes and will submit something to
xemacs-patches quickly. I'll CC: you when I submit.
On 4/30/07, Steve Higham <steve(a)sjlt.co.uk> wrote:
Your fix does not work. The stack dump is listed below. As you can
see,
mswindows_stat (...) is not being called. This is using version 21.4.20
code. The crash is invoked by temacs as it happens during the build
process.
Thanks for the stack trace - it was a big help.
mswindows_stat (...) is not being called
To be a bit more
precise, mswindows_stat() has already been called
before access() gets called. My thinko was that if the code had
already called ...stat(), a call to a function like access() would be
superfluous. After thinking it over a little bit, I'm back to
thinking that the right way to handle this (without significant code
surgery) is to redefine X_OK as you had previously suggested.
My fix of defining X_OK as 2 (under WIN32) is working fine and will
enable
me to debug my drive issue if / when it reappears.
... except you mean 4 (R_OK), right?
Here's the patch I'm currently trying out under Windows (native and
cygwin) and linux:
--- src/ChangeLog~ 2007-04-29 22:16:11.000000000 -0400
+++ src/ChangeLog 2007-05-01 22:20:19.218750000 -0400
＠＠ -0,0 +1,6 ＠＠
+2007-05-01 Vin Shelton <acs(a)xemacs.org>
+
+ * nt.c (mswindows_stat): Tie _S_IEXEC permission to read access.
+ (mswindows_fstat): Ditto.
+ * sysfile.h: Under Windows, define X_OK to be the same as R_OK.
+
Index: src/sysfile.h
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/sysfile.h,v
retrieving revision 1.9.2.1
diff -a -u -r1.9.2.1 sysfile.h
--- src/sysfile.h 2001/07/25 07:45:39 1.9.2.1
+++ src/sysfile.h 2007/05/02 18:38:51
＠＠ -261,12 +261,18 ＠＠
#endif
/* The following definitions are needed under Windows, at least */
-#ifndef X_OK
-# define X_OK 1
-#endif
-
#ifndef R_OK
# define R_OK 4
+#endif
+
+/* Under native Windows, there is no concept of execute permission,
+ so redefine execute permissions to be the same as read permission */
+#ifndef X_OK
+# ifdef WIN32_NATIVE
+# define X_OK R_OK
+# else
+# define X_OK 1
+# endif
#endif
#ifndef W_OK
Index: src/nt.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/nt.c,v
retrieving revision 1.21.2.4
diff -a -u -r1.21.2.4 nt.c
--- src/nt.c 2005/01/31 02:55:24 1.21.2.4
+++ src/nt.c 2007/05/02 18:39:05
＠＠ -1449,9 +1449,9 ＠＠
/* determine rwx permissions */
if (info.dwFileAttributes & FILE_ATTRIBUTE_READONLY)
- permission = _S_IREAD;
+ permission = _S_IREAD | _S_IEXEC;
else
- permission = _S_IREAD | _S_IWRITE;
+ permission = _S_IREAD | _S_IEXEC |_S_IWRITE;
if (info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
permission |= _S_IEXEC;
＠＠ -1638,22 +1638,12 ＠＠
/* determine rwx permissions */
if (wfd.dwFileAttributes & FILE_ATTRIBUTE_READONLY)
- permission = _S_IREAD;
+ permission = _S_IREAD | _S_IEXEC;
else
- permission = _S_IREAD | _S_IWRITE;
+ permission = _S_IREAD | _S_IEXEC |_S_IWRITE;
if (wfd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
permission |= _S_IEXEC;
- else
- {
- char * p = strrchr (name, '.');
- if (p != NULL &&
- (stricmp (p, ".exe") == 0 ||
- stricmp (p, ".com") == 0 ||
- stricmp (p, ".bat") == 0 ||
- stricmp (p, ".cmd") == 0))
- permission |= _S_IEXEC;
- }
buf->st_mode |= permission | (permission >> 3) | (permission >> 6);
Comments welcome.
- Vin
--
The Journey by Mary Oliver
http://www.poemhunter.com/p/m/poem.asp?poet=6771&poem=30506
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6413
days inactive
6417
days old
4 comments
2 participants
participants (2)
-
Steve Higham -
Vin Shelton