Where has the rwxr-xr-x gone from dired?

[Davin Pearson]

When I untar my tarball I get the following file list: (ls -l)

-rw------- 1 Davin Pearson None 1114 Jun 17 10:02 Makefile
-rw------- 1 Davin Pearson None 4528 Jun 16 14:29 README.txt
-rwxr-xr-x 1 Davin Pearson None 485 Jun 13 11:53 configure
drwx------+ 1 Davin Pearson None 0 Jun 18 2016 dlisp
drwx------+ 1 Davin Pearson None 0 Jun 18 2016 documentation
drwx------+ 1 Davin Pearson None 0 Jun 17 10:01 install-stuff

But when I view it in Emacs Version 24.5.1 I get the following output:

c:/home/hairy-lemon/output/davinpearson-com/binaries/java-training-wheels:
total used in directory 314 available 63772304
drwxrwxrwx 1 Davin Pearson None 4096 06-17 23:47 .
drwxrwxrwx 1 Administrators Administrators 225280 06-17 23:44 ..
drwxrwxrwx 1 Davin Pearson None 65536 2016-06-18 dlisp
drwxrwxrwx 1 Davin Pearson None 16384 2016-06-18 documentation
drwxrwxrwx 1 Davin Pearson None 4096 06-17 10:01 install-stuff
-rw-rw-rw- 1 Davin Pearson None 485 06-13 11:53 configure
-rw-rw-rw- 1 Davin Pearson None 1114 06-17 10:02 Makefile
-rw-rw-rw- 1 Davin Pearson None 4528 06-16 14:29 README.txt

Where has the -rwxr-xr-x gone from the file configure?

[John Mastro]

On Windows, Emacs by default uses a Lisp implementation of (the
most relevant parts of) ls, since Windows doesn't come with ls. Most
likely, Emacs's `ls-lisp' and your ls binary simply map Windows's
permissions to Unix-like permissions differently.

If that ls binary is on your PATH, you may be able to have Emacs use it
rather than `ls-lisp':

(with-eval-after-load 'ls-lisp
(setq ls-lisp-use-insert-directory-program t))

That's what I do on Windows, using ls from Cygwin. There are a potential
issues from mixing a native Windows Emacs binary with Cygwin binaries,
but it's worked well enough for me.

There's also a Cygwin build of Emacs that uses a native Windows GUI.
I've been meaning to try it and that may be an option for you too.

John

[Eli Zaretskii]

> Date: Fri, 17 Jun 2016 16:53:30 -0700 (PDT)
> From: Davin Pearson <davin....@gmail.com>

It didn't exist in the first place. Your ls.exe invented it (or maybe
it shows the Cygwin-only emulation of that bit); Emacs doesn't. Emacs
only considers a file executable if it can be executed by Windows
itself or by cmd.exe.

A similar issue explains why "ls -l" shows the directories accessible
only by your user, while Emacs doesn't.

[Eli Zaretskii]

> From: John Mastro <john.b...@gmail.com>
> Date: Fri, 17 Jun 2016 17:54:06 -0700
> Cc: Davin Pearson <davin....@gmail.com>

>
> (with-eval-after-load 'ls-lisp
> (setq ls-lisp-use-insert-directory-program t))
>
> That's what I do on Windows, using ls from Cygwin.

Why from Cygwin? Native Windows ports of ls.exe do exist.

> There are a potential issues from mixing a native Windows Emacs
> binary with Cygwin binaries, but it's worked well enough for me.

With respect to ls.exe specifically, the issues are that you might see
access information that doesn't match what Emacs can and cannot access
in fact. The Cygwin emulation of Posix access bits works correctly
only when all the programs involved are Cygwin programs.

[John Mastro]

Eli Zaretskii <el...@gnu.org> wrote:
>> That's what I do on Windows, using ls from Cygwin.
>
> Why from Cygwin? Native Windows ports of ls.exe do exist.

My perception when I first started using this setup was that Cygwin was
the easiest way to get a fairly complete Unix-like command line
environment. Things like a shell, coreutils, findutils, GNU grep, git,
man, etc. Cygwin makes it very easy to install all those, keep them
up-to-date, and use them from Emacs.

> With respect to ls.exe specifically, the issues are that you might see
> access information that doesn't match what Emacs can and cannot access
> in fact. The Cygwin emulation of Posix access bits works correctly
> only when all the programs involved are Cygwin programs.

I've definitely observed that they report different things but the
environment where I'm doing this is simple enough that it hasn't been a
problem. I'm almost always working with files that are on my local
machine and which I put there, so I rarely need to look at the
permissions anyway.

John

[Eli Zaretskii]

> From: John Mastro <john.b...@gmail.com>
> Date: Sat, 18 Jun 2016 13:30:48 -0700

>
> Eli Zaretskii <el...@gnu.org> wrote:
> >> That's what I do on Windows, using ls from Cygwin.
> >
> > Why from Cygwin? Native Windows ports of ls.exe do exist.
>
> My perception when I first started using this setup was that Cygwin was
> the easiest way to get a fairly complete Unix-like command line
> environment.

Easiest doesn't always mean the best.

> > With respect to ls.exe specifically, the issues are that you might see
> > access information that doesn't match what Emacs can and cannot access
> > in fact. The Cygwin emulation of Posix access bits works correctly
> > only when all the programs involved are Cygwin programs.
>
> I've definitely observed that they report different things but the
> environment where I'm doing this is simple enough that it hasn't been a
> problem. I'm almost always working with files that are on my local
> machine and which I put there, so I rarely need to look at the
> permissions anyway.

Even with local files, this is no longer true on modern Windows
systems. In particular, files under C:\Users have non-trivial
protection attributes. So this problem is practically in our face.

[Bob Proulx]

Eli Zaretskii wrote:
> John Mastro wrote:

> > Eli Zaretskii wrote:
> > > Why from Cygwin? Native Windows ports of ls.exe do exist.
> >
> > My perception when I first started using this setup was that Cygwin was
> > the easiest way to get a fairly complete Unix-like command line
> > environment.
>
> Easiest doesn't always mean the best.

My perception is that Cygwin has an active developer base that often
participates on the GNU mailing lists and therefore Cygwin is more
visible to the GNU community than other ports such as MinGW. I don't
recall ever having seen a MinGW developer chatting about MinGW on the
mailing lists I frequent. For example.

As far as I can tell Cygwin tries really hard to create a Unix like
environment on Microsoft Windows. If that requires making some things
that a MS user might expect to be MS-like to be more Unix-like then
that is what they do. Whereas MinGW tries really hard to port GNU
utilities to Microsoft so that within the MS operating system the GNU
utilities are available. As much as possible all MS-like features are
preserved.

As such these two projects have a different design vision. As far as
I can tell this is the difference. If a person is coming from a Unix
background and likes it then Cygwin provides a more Unix like
environment. If a person is coming from a Microsoft background and
likes it then MinGW provides a more Microsoft like environment.

True? False? I don't know. But that seems to be the way of it as
far as I can see. Says me who is happy I am not running Microsoft
myself. Other people can do what they want.

Bob

[Eli Zaretskii]

> Date: Sun, 19 Jun 2016 16:46:19 -0600
> From: Bob Proulx <b...@proulx.com>

>
> Eli Zaretskii wrote:
> > John Mastro wrote:
> > > Eli Zaretskii wrote:
> > > > Why from Cygwin? Native Windows ports of ls.exe do exist.
> > >
> > > My perception when I first started using this setup was that Cygwin was
> > > the easiest way to get a fairly complete Unix-like command line
> > > environment.
> >
> > Easiest doesn't always mean the best.
>
> My perception is that Cygwin has an active developer base that often
> participates on the GNU mailing lists and therefore Cygwin is more
> visible to the GNU community than other ports such as MinGW. I don't
> recall ever having seen a MinGW developer chatting about MinGW on the
> mailing lists I frequent. For example.

I guess we are reading very disjoint sets of lists, then ;-)

> As far as I can tell Cygwin tries really hard to create a Unix like
> environment on Microsoft Windows. If that requires making some things
> that a MS user might expect to be MS-like to be more Unix-like then
> that is what they do. Whereas MinGW tries really hard to port GNU
> utilities to Microsoft so that within the MS operating system the GNU
> utilities are available. As much as possible all MS-like features are
> preserved.
>
> As such these two projects have a different design vision. As far as
> I can tell this is the difference. If a person is coming from a Unix
> background and likes it then Cygwin provides a more Unix like
> environment. If a person is coming from a Microsoft background and
> likes it then MinGW provides a more Microsoft like environment.
>
> True? False? I don't know.

Both true and false. The issue here is not whether to prefer Cygwin
over MinGW. The issue is whether it is a good idea to have a MinGW
build of Emacs use Cygwin ls to produce directory listings on which
the MinGW built Emacs will have to operate. IOW, the issue is mixing
Cygwin and MinGW programs in the same workflow, when it is known that
the way each one represents Posix access bits is radically different.

[John Mastro]

Eli Zaretskii <el...@gnu.org> wrote:
>> My perception when I first started using this setup was that Cygwin was
>> the easiest way to get a fairly complete Unix-like command line
>> environment.
>
> Easiest doesn't always mean the best.

That's certainly true, though it does count for something if it's also
"good enough" for your use case :)

What do you recommend - MinGW and MSYS, supplemented by your ezwinports?
(Sorry if that question doesn't make sense - I'm not very familiar with
the relationships between MinGW, MSYS, ezwinports, MSYS2, etc.)

Thanks

John

[Eli Zaretskii]

> From: John Mastro <john.b...@gmail.com>
> Date: Mon, 20 Jun 2016 12:07:29 -0700

>
> What do you recommend - MinGW and MSYS, supplemented by your ezwinports?

MinGW is a development environment. Any program built in that
environment is a native Windows program. The ezwinports programs are
all built with MinGW. Other MinGW builds of Unix and GNU software can
be found on the official MinGW site.

Native Windows programs can also be built with other toolchains, like
MS Visual Studio, but those alternatives are not Free Software.

My recommendation is to use native Windows programs with native Emacs,
and Cygwin programs with Cygwin Emacs. MSYS I don't recommend at all,
as its only purpose is to allow running Posix build procedures that
build MinGW programs.

[Bob Proulx]

Eli Zaretskii wrote:

> Bob Proulx wrote:
> > As such these two projects have a different design vision. As far as
> > I can tell this is the difference. If a person is coming from a Unix
> > background and likes it then Cygwin provides a more Unix like
> > environment. If a person is coming from a Microsoft background and
> > likes it then MinGW provides a more Microsoft like environment.
> >
> > True? False? I don't know.
>
> Both true and false. The issue here is not whether to prefer Cygwin
> over MinGW. The issue is whether it is a good idea to have a MinGW
> build of Emacs use Cygwin ls to produce directory listings on which
> the MinGW built Emacs will have to operate. IOW, the issue is mixing
> Cygwin and MinGW programs in the same workflow, when it is known that
> the way each one represents Posix access bits is radically different.

I think your point here is very reasonable. :-)

Bob