GNU bug report logs -
#53739
28.0.91; "C-x d" fails when "emacs -Q" starts on NetBSD with plan9/bin on head of PATH
Previous Next
Reported by: Van Ly <van.ly <at> sdf.org>
Date: Wed, 2 Feb 2022 22:13:02 UTC
Severity: normal
Tags: wontfix
Found in version 28.0.91
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53739 in the body.
You can then email your comments to 53739 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Wed, 02 Feb 2022 22:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Van Ly <van.ly <at> sdf.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Wed, 02 Feb 2022 22:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
For the following interactive shells:
* /bin/sh
* /usr/pkg/bin/zsh
* /usr/local/plan9/bin/rc
when "/usr/local/plan9/bin" is at the head of the PATH environment
variable and entry to GNU Emacs is by "emacs -Q", inside GNU Emacs the
dired command fails
# steps to reproduce behavior
* start by 'emacs -Q'
* list directory by 'C-x d'
# observed behavior
# minibuffer echo area says
> insert-directory: Listing directory failed but `access-file' worked
# expected behavior
# window displays listing of Dired, for example
'''
/usr/X:
total used in directory 96K available 72 GiB
1966113 drwxr-xr-x 2 501 4.0K Jan 30 15:00 Articles
1977600 drwxr-xr-x 3 501 4.0K Jan 31 07:11 Books
1977546 drwxr-xr-x 2 501 4.0K Jan 26 20:00 Configurations
1977542 -rw-r--r-- 1 501 7.7K Jan 30 17:49 emacs-lisp.text
'''
--
vl
[bug-gnu-emacs-28.0.91--netbsd-amd64.text (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 07:23:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 2 Feb 2022 22:12:31 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
>
> For the following interactive shells:
>
> * /bin/sh
> * /usr/pkg/bin/zsh
> * /usr/local/plan9/bin/rc
>
> when "/usr/local/plan9/bin" is at the head of the PATH environment
> variable and entry to GNU Emacs is by "emacs -Q", inside GNU Emacs the
> dired command fails
>
> # steps to reproduce behavior
> * start by 'emacs -Q'
> * list directory by 'C-x d'
>
> # observed behavior
> # minibuffer echo area says
>
> > insert-directory: Listing directory failed but `access-file' worked
I guess the version of 'ls' there is incompatible or something? The
message means that 'ls' exited with a non-zero status for some reason.
Please investigate more what went wrong there and report here the
details, so we could decide whether we want to support "plan9/bin"
idiosyncrasies, whatever they are. Stepping with Edebug through
insert-directory should help you understand what's going on.
Also, please explain what you mean by "for the following interactive
shells". How does the interactive shell enter this picture? And what
is the value of shell-file-name in the session where "C-x d" fails?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 08:03:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I guess the version of 'ls' there is incompatible or something? The
> message means that 'ls' exited with a non-zero status for some reason.
Yes, Plan 9 from User Space (which provides the ports of Plan 9
utilities to Unix-like systems) provides an ls binary that is
incompatible with what Emacs expects.
> Please investigate more what went wrong there and report here the
> details, so we could decide whether we want to support "plan9/bin"
> idiosyncrasies, whatever they are.
It would be a great deal of trouble to support their version of ls (and
indeed, their versions of many other common Unix utilities such as `rm'
and `cp'), so I think the answer is simply "don't run Emacs with
plan9/bin at the head of your PATH".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 09:19:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Van Ly <van.ly <at> sdf.org>, 53739 <at> debbugs.gnu.org
> Date: Thu, 03 Feb 2022 16:01:51 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I guess the version of 'ls' there is incompatible or something? The
> > message means that 'ls' exited with a non-zero status for some reason.
>
> Yes, Plan 9 from User Space (which provides the ports of Plan 9
> utilities to Unix-like systems) provides an ls binary that is
> incompatible with what Emacs expects.
>
> > Please investigate more what went wrong there and report here the
> > details, so we could decide whether we want to support "plan9/bin"
> > idiosyncrasies, whatever they are.
>
> It would be a great deal of trouble to support their version of ls (and
> indeed, their versions of many other common Unix utilities such as `rm'
> and `cp'), so I think the answer is simply "don't run Emacs with
> plan9/bin at the head of your PATH".
Can you tell more about the incompatibilities, perhaps by comparing
the output of their 'ls' with a compatible one?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 10:02:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Can you tell more about the incompatibilities, perhaps by comparing
> the output of their 'ls' with a compatible one?
I can't remember the specifics, but IIRC their version of ls simply
prints out each file in the current working directory, without any
option to display permission bits, size, or ownership information.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 10:33:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: van.ly <at> sdf.org, 53739 <at> debbugs.gnu.org
> Date: Thu, 03 Feb 2022 18:01:40 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Can you tell more about the incompatibilities, perhaps by comparing
> > the output of their 'ls' with a compatible one?
>
> I can't remember the specifics, but IIRC their version of ls simply
> prints out each file in the current working directory, without any
> option to display permission bits, size, or ownership information.
You are saying that "ls -l" doesn't honor the -l option?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 11:04:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> I can't remember the specifics, but IIRC their version of ls simply
>> prints out each file in the current working directory, without any
>> option to display permission bits, size, or ownership information.
> You are saying that "ls -l" doesn't honor the -l option?
There isn't an -l option, IIRC.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 11:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: van.ly <at> sdf.org, 53739 <at> debbugs.gnu.org
> Date: Thu, 03 Feb 2022 19:02:57 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> I can't remember the specifics, but IIRC their version of ls simply
> >> prints out each file in the current working directory, without any
> >> option to display permission bits, size, or ownership information.
>
> > You are saying that "ls -l" doesn't honor the -l option?
>
> There isn't an -l option, IIRC.
OK. Do they have a replacement program that behaves like "ls -l"?
Maybe 'dir' or somesuch? Then the solution would be to give a
different value to insert-directory-program on that platform.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 11:30:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> OK. Do they have a replacement program that behaves like "ls -l"?
> Maybe 'dir' or somesuch? Then the solution would be to give a
> different value to insert-directory-program on that platform.
I don't know.
But it's not really a special platform, just NetBSD with an IMSHO
misconfigured path full of utilities ported from another very niche
operating system that we don't yet support.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 13:01:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 53739 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 3 Feb 2022, Eli Zaretskii wrote:
>
> I guess the version of 'ls' there is incompatible or something? The
> message means that 'ls' exited with a non-zero status for some reason.
> Please investigate more what went wrong there and report here the
> details, so we could decide whether we want to support "plan9/bin"
> idiosyncrasies, whatever they are. Stepping with Edebug through
> insert-directory should help you understand what's going on.
>
I guess plan9/bin contains many commands identical in name to those
GNU Emacs expects from POSIX but they have plan9's reinvention.
One fix is not to put plan9/bin on the head of PATH but at the tail
and GNU Emacs will succeed at "C-x d" or dired. Maybe a response
like how "dired-use-ls-dired" is handled will point the user in the
right direction.
> Also, please explain what you mean by "for the following interactive
> shells".
The interactive shell is either the shell given at login by setting
as follows then logout, login
> usermod -s /path/to/shell username
and that shell is listed for the username in /etc/passwd
or I "exec /path/to/shell" to change the shell; I think
shell-file-name is set to the value listed in /etc/passwd.
I had the shells sh, zsh and rc running interactively at the command prompt.
> How does the interactive shell enter this picture?
The interactive shell is the environment on the command line where I
launch "emacs -Q".
And what
> is the value of shell-file-name in the session where "C-x d" fails?
Two examples of the value for shell-file-name in the session where
"C-x d" fails are as follows:
'''
;; set shell to sh by usermod, logout and login
Its value is "/bin/sh"
Original value was "/usr/pkg/bin/zsh"
;; set shell to rc by usermod, logout and login
Its value is "/usr/local/plan9/bin/rc"
Original value was "/usr/pkg/bin/zsh"
'''
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 13:06:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Thu, 3 Feb 2022, Po Lu wrote:
>
> It would be a great deal of trouble to support their version of ls (and
> indeed, their versions of many other common Unix utilities such as `rm'
> and `cp'), so I think the answer is simply "don't run Emacs with
> plan9/bin at the head of your PATH".
>
Maybe the user can have their cake and eat it. What if Emacs ignores
the PATH element containing plan9/bin and the shell environment
outside Emacs is allowed to prefer plan9's commands?
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 13:13:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 53739 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, 3 Feb 2022, Po Lu wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Can you tell more about the incompatibilities, perhaps by comparing
>> the output of their 'ls' with a compatible one?
>
> I can't remember the specifics, but IIRC their version of ls simply
> prints out each file in the current working directory, without any
> option to display permission bits, size, or ownership information.
>
The manpage for plan9's ls command is attached.
--
vl
[9-man-ls.text (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 13:22:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Thu, 3 Feb 2022, Po Lu wrote:
>
> But it's not really a special platform, just NetBSD with an IMSHO
> misconfigured path full of utilities ported from another very niche
> operating system that we don't yet support.
>
IIRC I saw mentioned Emacs was ported to Plan9. A basic difference
between UNIX and Plan9 is the obsolescense of the TTY.
=> https://plan9.io/
=> https://p9f.org/
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 16:46:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 3 Feb 2022 13:05:27 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 53739 <at> debbugs.gnu.org
>
> Maybe the user can have their cake and eat it. What if Emacs ignores
> the PATH element containing plan9/bin and the shell environment
> outside Emacs is allowed to prefer plan9's commands?
Emacs doesn't use PATH, it uses exec-path.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 16:48:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 3 Feb 2022 13:12:07 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 53739 <at> debbugs.gnu.org
>
> > I can't remember the specifics, but IIRC their version of ls simply
> > prints out each file in the current working directory, without any
> > option to display permission bits, size, or ownership information.
> >
>
> The manpage for plan9's ls command is attached.
This says the -l option is supported, so I'm not sure I understand
what is the cause of the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Thu, 03 Feb 2022 16:48:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 3 Feb 2022 13:20:58 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 53739 <at> debbugs.gnu.org
>
> On Thu, 3 Feb 2022, Po Lu wrote:
>
> >
> > But it's not really a special platform, just NetBSD with an IMSHO
> > misconfigured path full of utilities ported from another very niche
> > operating system that we don't yet support.
> >
>
> IIRC I saw mentioned Emacs was ported to Plan9.
So maybe you should use that port.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 01:00:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> The manpage for plan9's ls command is attached.
Please show some output from that ls command when you run it with the
"-l" option.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 04:30:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Fri, 4 Feb 2022, Po Lu wrote:
>
> Please show some output from that ls command when you run it with the
> "-l" option.
>
'''
; on NetBSD
% /usr/local/plan9/bin/ls -l
d-rwxr-xr-x M 0 van staff 0 Feb 1 02:37 Configurations
d-rwxr-xr-x M 0 van staff 0 Feb 3 21:08 Examples
d-rwxr-xr-x M 0 van staff 0 Jan 25 20:38 Projects
; on GNU/Linux
% /usr/local/plan9/bin/ls -l
d-rwxr-xr-x M 0 van dialout 0 Jan 31 16:15 .git
--rw-r--r-- M 0 van dialout 39 Jan 12 00:14 .gitignore
d-rwxr-xr-x M 0 van dialout 0 Jan 30 15:00 Articles
d-rwxr-xr-x M 0 van dialout 0 Jan 31 07:11 Books
d-rwxr-xr-x M 0 van dialout 0 Feb 2 13:19 Configurations
d-rwxr-xr-x M 0 van dialout 0 Jan 26 03:56 Examples
d-rwxr-xr-x M 0 van dialout 0 Jan 30 20:09 Letters
d-rwxr-xr-x M 0 van dialout 0 Jan 30 20:38 Notes
d-rwxr-xr-x M 0 van dialout 0 Jan 24 10:43 Projects
--rw-r--r-- M 0 van dialout 1513 Jan 31 16:15 README
--rw-r--r-- M 0 van dialout 8342 Feb 4 13:08 emacs-lisp.text
--rw-r--r-- M 0 van dialout 208 Jan 28 09:57 focs.text
--rw-r--r-- M 0 van dialout 2242 Jan 11 06:16 graphviz.text
--rw-r--r-- M 0 van dialout 140 Jan 31 08:09 ir-book.text
--rw-r--r-- M 0 van dialout 772 Jan 11 06:11 jau--zhou1--zau1.text
--rw-r--r-- M 0 van dialout 3605 Jan 28 19:55 modern-c.text
--rw-r--r-- M 0 van dialout 28133 Feb 4 09:50 scratch.text
--rw-r--r-- M 0 van dialout 1505 Jan 31 16:13 styleguide-eu-english.text
--rw-r--r-- M 0 van dialout 4096 Jan 30 19:30 typescript
'''
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 04:51:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
> % /usr/local/plan9/bin/ls -l
> d-rwxr-xr-x M 0 van staff 0 Feb 1 02:37 Configurations
> d-rwxr-xr-x M 0 van staff 0 Feb 3 21:08 Examples
> d-rwxr-xr-x M 0 van staff 0 Jan 25 20:38 Projects
That should probably work fine, so I have no idea what the problem might
be.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 07:19:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Fri, 4 Feb 2022, Po Lu wrote:
> Van Ly <van.ly <at> sdf.org> writes:
>
>> % /usr/local/plan9/bin/ls -l
>> d-rwxr-xr-x M 0 van staff 0 Feb 1 02:37 Configurations
>> d-rwxr-xr-x M 0 van staff 0 Feb 3 21:08 Examples
>> d-rwxr-xr-x M 0 van staff 0 Jan 25 20:38 Projects
>
> That should probably work fine, so I have no idea what the problem might
> be.
>
The problem is reproduced on GNU/Linux when plan9/bin is placed
second after the head on PATH.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 07:57:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Van Ly <van.ly <at> sdf.org> writes:
>> That should probably work fine, so I have no idea what the problem might
>> be.
> The problem is reproduced on GNU/Linux when plan9/bin is placed second
> after the head on PATH.
But the important question is which `ls' is run, not the order where
directories appear in PATH?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 08:07:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 53739 <at> debbugs.gnu.org
> Date: Fri, 04 Feb 2022 12:50:39 +0800
>
> Van Ly <van.ly <at> sdf.org> writes:
>
> > % /usr/local/plan9/bin/ls -l
> > d-rwxr-xr-x M 0 van staff 0 Feb 1 02:37 Configurations
> > d-rwxr-xr-x M 0 van staff 0 Feb 3 21:08 Examples
> > d-rwxr-xr-x M 0 van staff 0 Jan 25 20:38 Projects
>
> That should probably work fine, so I have no idea what the problem might
> be.
The problem, as I explained up-thread, seems to be that 'ls' returns a
non-zero exit status, which insert-directory takes as a sign that the
directory listing didn't work.
So: what does "ls -l" return as exit status when using the plan9
variant of 'ls'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 09:00:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Fri, 4 Feb 2022, Eli Zaretskii wrote:
>
> The problem, as I explained up-thread, seems to be that 'ls' returns a
> non-zero exit status, which insert-directory takes as a sign that the
> directory listing didn't work.
The "9 man intro" page has this paragraph containing the "exit" keyword.
'''
DIAGNOSTICS
In Plan 9, a program's exit status is an arbitrary text
string, while on Unix it is an integer. Section (1) of this
manual describes commands as though they exit with string
statuses. In fact, exiting with an empty status corresponds
to exiting with status 0, and exiting with any non-empty
string corresponds to exiting with status 1. See exits(3).
'''
>
> So: what does "ls -l" return as exit status when using the plan9
> variant of 'ls'?
>
Starting 'emacs -Q' at the end of this typescript reproduces the problem.
'''
; on GNU/Linux
% echo $SHELL
/usr/bin/zsh
% PATH=/usr/local/plan9/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export PATH
% echo $PATH
/usr/van/.opam/cs3110-2-21fa/bin:/usr/local/plan9/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
% which ls
/usr/local/plan9/bin/ls
% ls -l
--rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
--rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
% echo $?
0
% /usr/local/plan9/bin/ls -l
--rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
--rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
% echo $?
0
'''
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 09:27:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Fri, 4 Feb 2022, Van Ly wrote:
> On Fri, 4 Feb 2022, Eli Zaretskii wrote:
>
>>
>> So: what does "ls -l" return as exit status when using the plan9
>> variant of 'ls'?
>>
>
This also reproduces the problem.
'''
% echo $SHELL
/usr/bin/zsh
% export PATH=/usr/local/plan9/bin:/usr/X/Projects/emacs-2022-01-15/bin
% echo $PATH
/usr/local/plan9/bin:/usr/X/Projects/emacs-2022-01-15/bin
% which ls
/usr/local/plan9/bin/ls
% ls -l
--rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
--rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
% echo $?
0
% /usr/local/plan9/bin/ls -l
--rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
--rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
% echo $?
0
% emacs -Q
'''
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 11:51:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 4 Feb 2022 08:59:11 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Po Lu <luangruo <at> yahoo.com>, 53739 <at> debbugs.gnu.org
>
> On Fri, 4 Feb 2022, Eli Zaretskii wrote:
>
> >
> > The problem, as I explained up-thread, seems to be that 'ls' returns a
> > non-zero exit status, which insert-directory takes as a sign that the
> > directory listing didn't work.
>
> The "9 man intro" page has this paragraph containing the "exit" keyword.
>
> '''
> DIAGNOSTICS
> In Plan 9, a program's exit status is an arbitrary text
> string, while on Unix it is an integer. Section (1) of this
> manual describes commands as though they exit with string
> statuses. In fact, exiting with an empty status corresponds
> to exiting with status 0, and exiting with any non-empty
> string corresponds to exiting with status 1. See exits(3).
> '''
>
> >
> > So: what does "ls -l" return as exit status when using the plan9
> > variant of 'ls'?
> >
>
> Starting 'emacs -Q' at the end of this typescript reproduces the problem.
>
> '''
> ; on GNU/Linux
> % echo $SHELL
> /usr/bin/zsh
> % PATH=/usr/local/plan9/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export PATH
> % echo $PATH
> /usr/van/.opam/cs3110-2-21fa/bin:/usr/local/plan9/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> % which ls
> /usr/local/plan9/bin/ls
> % ls -l
> --rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
> --rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
> % echo $?
> 0
> % /usr/local/plan9/bin/ls -l
> --rw-r--r-- M 0 van dialout 46 Feb 4 18:22 emacs28
> --rw-r--r-- M 0 van dialout 47 Feb 4 18:14 emacs28q
> % echo $?
> 0
Thanks, but we need to know what Emacs sees as the exit status inside
insert-directory. So, as I already said, the best approach top
investigating this is to step with Edebug through the code in
insert-directory, and see what kind of exit status we receive there,
and why we decide that "directory listing failed".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Fri, 04 Feb 2022 11:54:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 4 Feb 2022 09:26:28 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Po Lu <luangruo <at> yahoo.com>, 53739 <at> debbugs.gnu.org
>
> On Fri, 4 Feb 2022, Van Ly wrote:
>
> > On Fri, 4 Feb 2022, Eli Zaretskii wrote:
> >
> >>
> >> So: what does "ls -l" return as exit status when using the plan9
> >> variant of 'ls'?
> >>
> >
>
> This also reproduces the problem.
I don't see what it reproduces, and more importantly, don't see how
this is relevant. Please step through the code of insert-directory
and describe here what you see there when it reports the error.
Everything else is just noise, as far as investigation of this problem
is concerned.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 03:08:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 53739 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, 4 Feb 2022, Eli Zaretskii wrote:
Please step through the code of insert-directory
> and describe here what you see there when it reports the error.
> Everything else is just noise, as far as investigation of this problem
> is concerned.
Using Edebug on the instrumented insert-directory function narrows in
on lisp/files.el
'''
7502 (apply 'call-process
7503 insert-directory-program nil t nil
7504 (append
7505 (if (listp switches) switches
7506 (unless (equal switches "")
7507 ;; Split the switches at any spaces so we can
7508 ;; pass separate options as separate args .
7509 (split-string-and-unquote switches)))
7510 ;; Avoid lossage if FILE starts with `-'.
7511 '("--")
7512 (list file))))))
'''
The "result" exit status is "1" on line 7512 closing parenthesises.
The call is "ls -al -- /usr/X" and the problem is Plan's ls doesn't
take the "-a" switch. For example
'''
% ls -a
usage: ls [-dlmnpqrstuFQ] [file ...]
% echo $?
1
% ls -al
usage: ls [-dlmnpqrstuFQ] [file ...]
% echo $?
1
'''
The Edebug steps continue to line 7581.
lisp/files.el:7581
"Listing directory failed but `access-file' worked"
In the case of Plan9's ls what is needed is to leave out the "-a" switch.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 07:38:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 5 Feb 2022 03:07:07 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53739 <at> debbugs.gnu.org
>
> The "result" exit status is "1" on line 7512 closing parenthesises.
>
> The call is "ls -al -- /usr/X" and the problem is Plan's ls doesn't
> take the "-a" switch. For example
>
> '''
> % ls -a
> usage: ls [-dlmnpqrstuFQ] [file ...]
> % echo $?
> 1
> % ls -al
> usage: ls [-dlmnpqrstuFQ] [file ...]
> % echo $?
> 1
> '''
Thanks, the problem is clear now.
> The Edebug steps continue to line 7581.
>
> lisp/files.el:7581
> "Listing directory failed but `access-file' worked"
>
> In the case of Plan9's ls what is needed is to leave out the "-a" switch.
Which means "C-u C-x d" should fix your use case nicely. You can also
customize dired-listing-switches in your init file, if you intend to
use this version of 'ls' routinely. It's a defcustom for this very
reason.
Bottom line: I think we can close this bug with no further action.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 09:05:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Sat, 5 Feb 2022, Eli Zaretskii wrote:
>> In the case of Plan9's ls what is needed is to leave out the "-a" switch.
>
> Which means "C-u C-x d" should fix your use case nicely. You can also
> customize dired-listing-switches in your init file, if you intend to
> use this version of 'ls' routinely. It's a defcustom for this very
> reason.
>
> Bottom line: I think we can close this bug with no further action.
>
Thanks.
Another fix is to re-order Emacs's exec-path and put plan9/bin second
last at the bottom. Emacs could DWIM to the exec-path on seeing
plan9/bin at the top.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 09:21:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 53739 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 5 Feb 2022 09:04:29 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: luangruo <at> yahoo.com, 53739 <at> debbugs.gnu.org
>
> On Sat, 5 Feb 2022, Eli Zaretskii wrote:
>
> >> In the case of Plan9's ls what is needed is to leave out the "-a" switch.
> >
> > Which means "C-u C-x d" should fix your use case nicely. You can also
> > customize dired-listing-switches in your init file, if you intend to
> > use this version of 'ls' routinely. It's a defcustom for this very
> > reason.
> >
> > Bottom line: I think we can close this bug with no further action.
> >
>
> Thanks.
>
> Another fix is to re-order Emacs's exec-path and put plan9/bin second
> last at the bottom. Emacs could DWIM to the exec-path on seeing
> plan9/bin at the top.
I see no need to change Emacs for such a corner use case that already
has an easy solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 10:58:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 53739 <at> debbugs.gnu.org (full text, mbox):
On Sat, 5 Feb 2022, Eli Zaretskii wrote:
>
> I see no need to change Emacs for such a corner use case that already
> has an easy solution.
>
Anyway. I wonder what the Lisp Machine designers would have done for
this corner case in the sense of furniture design and comfort. For
me, Emacs feels like furniture at times. Edebug was an easy to use
experience and well designed.
--
vl
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#53739; Package
emacs.
(Sat, 05 Feb 2022 21:58:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 53739 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Bottom line: I think we can close this bug with no further action.
I agree. Now done.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 05 Feb 2022 21:59:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
53739 <at> debbugs.gnu.org and Van Ly <van.ly <at> sdf.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 05 Feb 2022 21:59:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 06 Mar 2022 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 107 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.