GNU bug report logs - #34915
27.0.50; Wdired regression with ls -F

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34915 in the body.
You can then email your comments to 34915 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Wdired regression with ls -F
Date: Tue, 19 Mar 2019 13:43:16 +0000

X-Debbugs-Cc: Stephen Berman <stephen.berman <at> gmx.net>

The following behaviour is present in master but not emacs-26.
I haven't bisected the issue to Stephen's changes to Wdired, but I
checked that it wasn't caused by Stefan's recent changes to Dired.

0. emacs -Q
1. (progn (setq dired-listing-switches "-Fl")
          (dired (make-temp-file "my-wdired-" t)))
   C-j
2. M-x dired-create-empty-file RET exec RET
3. M +x RET
4. M-x wdired-change-to-wdired-mode RET
5. w C-c C-c
   1 rename actions failed--type ? for details
6. ?
   Rename ‘/tmp/my-wdired-tMSVuW/exec*’ to ‘/tmp/my-wdired-tMSVuW/wexec*’ failed:
   (file-missing Renaming No such file or directory
                 /tmp/my-wdired-tMSVuW/exec*
                 /tmp/my-wdired-tMSVuW/wexec*)
7. M-x dired-create-empty-file RET plain RET
8. M-x wdired-change-to-wdired-mode RET
9. w C-c C-c

This wdired-finish-edit succeeds, but instead of only renaming 'plain'
to 'wplain', it also renames 'exec' to 'exec*'.

It seems like Wdired thinks the indicators added by ls (one of */=>@|)
are part of the file name now.

-- 
Basil

In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-03-19 built on thunk
Repository revision: c0936672876bccc15e7899e83d8ab99910f8feee
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native -pipe'
 --config-cache --prefix=/home/blc/.local --with-mailutils
 --with-x-toolkit=lucid --with-modules --with-file-notification=yes
 --with-x'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Message #8 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 12 Apr 2019 14:23:38 +0200

On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:

> X-Debbugs-Cc: Stephen Berman <stephen.berman <at> gmx.net>
>
> The following behaviour is present in master but not emacs-26.
> I haven't bisected the issue to Stephen's changes to Wdired, but I
> checked that it wasn't caused by Stefan's recent changes to Dired.
>
> 0. emacs -Q
> 1. (progn (setq dired-listing-switches "-Fl")
>           (dired (make-temp-file "my-wdired-" t)))
>    C-j
> 2. M-x dired-create-empty-file RET exec RET
> 3. M +x RET
> 4. M-x wdired-change-to-wdired-mode RET
> 5. w C-c C-c
>    1 rename actions failed--type ? for details
> 6. ?
>    Rename ‘/tmp/my-wdired-tMSVuW/exec*’ to ‘/tmp/my-wdired-tMSVuW/wexec*’ failed:
>    (file-missing Renaming No such file or directory
>                  /tmp/my-wdired-tMSVuW/exec*
>                  /tmp/my-wdired-tMSVuW/wexec*)
> 7. M-x dired-create-empty-file RET plain RET
> 8. M-x wdired-change-to-wdired-mode RET
> 9. w C-c C-c
>
> This wdired-finish-edit succeeds, but instead of only renaming 'plain'
> to 'wplain', it also renames 'exec' to 'exec*'.
>
> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
> are part of the file name now.

This is indeed due to my changes.  The patch below appears to fix the
problem, but I'm not sure how robust it is (I was also, and remain,
unsure about my handling of symlinks in the previous patch, but I
haven't found time to look at it more closely; at least I haven't seen
any bug reports about it so far).

Steve Berman

diff --git a/lisp/wdired.el b/lisp/wdired.el
index acc62e4e39..ca3e2f7845 100644
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -612,14 +612,21 @@ wdired--restore-dired-filename-prop
         (when (re-search-forward
                directory-listing-before-filename-regexp lep t)
           (setq beg (point)
-                ;; If the file is a symlink, put the dired-filename
-                ;; property only on the link name.  (Using
-                ;; (file-symlink-p (dired-get-filename)) fails in
-                ;; wdired-mode, bug#32673.)
-                end (if (and (re-search-backward
-                              dired-permission-flags-regexp nil t)
-                             (looking-at "l")
-                             (search-forward " -> " lep t))
+                end (if (or
+                         ;; If the file is a symlink, put the
+                         ;; dired-filename property only on the link
+                         ;; name.  (Using (file-symlink-p
+                         ;; (dired-get-filename)) fails in
+                         ;; wdired-mode, bug#34915.)
+                         (and (re-search-backward
+                               dired-permission-flags-regexp nil t)
+                              (looking-at "l")
+                              (search-forward " -> " lep t))
+                         ;; When using the -F switch, don't treat file
+                         ;; type indicator characters as part of the
+                         ;; file name (bug#34915).
+                         (and (string-match "F" dired-actual-switches)
+                              (re-search-forward "[*/@|=>]$" lep t)))
                         (goto-char (match-beginning 0))
                       lep))
           (put-text-property beg end 'dired-filename t))))))

Message #11 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 12 Apr 2019 13:58:25 +0100

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:
>
>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>> are part of the file name now.
>
> This is indeed due to my changes.  The patch below appears to fix the
> problem, but I'm not sure how robust it is (I was also, and remain,
> unsure about my handling of symlinks in the previous patch, but I
> haven't found time to look at it more closely; at least I haven't seen
> any bug reports about it so far).

I can confirm your patch fixes the issue, thanks!

-- 
Basil

Message #14 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 12 Apr 2019 15:06:18 +0200

On Fri, 12 Apr 2019 13:58:25 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios"
>> <contovob <at> tcd.ie> wrote:
>>
>>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>>> are part of the file name now.
>>
>> This is indeed due to my changes.  The patch below appears to fix the
>> problem, but I'm not sure how robust it is (I was also, and remain,
>> unsure about my handling of symlinks in the previous patch, but I
>> haven't found time to look at it more closely; at least I haven't seen
>> any bug reports about it so far).
>
> I can confirm your patch fixes the issue, thanks!

Thanks for testing.  If there are no objections within a few days, I'll
push it to master.

Steve Berman

Message #17 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Thu, 25 Apr 2019 19:28:26 +0200

On Fri, 12 Apr 2019 15:06:18 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Fri, 12 Apr 2019 13:58:25 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:
>
>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>
>>> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios"
>>> <contovob <at> tcd.ie> wrote:
>>>
>>>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>>>> are part of the file name now.
>>>
>>> This is indeed due to my changes.  The patch below appears to fix the
>>> problem, but I'm not sure how robust it is (I was also, and remain,
>>> unsure about my handling of symlinks in the previous patch, but I
>>> haven't found time to look at it more closely; at least I haven't seen
>>> any bug reports about it so far).
>>
>> I can confirm your patch fixes the issue, thanks!
>
> Thanks for testing.  If there are no objections within a few days, I'll
> push it to master.

I didn't expect "a few days" to become almost two weeks, but I've
finally pushed the fix to master as commit 6d8e0fc5aa.  I slightly
changed the patch to account for using either the short or long form of
the indicator switch, and I added a test.

Steve Berman

Message #20 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 26 Apr 2019 14:56:57 +0100

[Message part 1 (text/plain, inline)]

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Fri, 12 Apr 2019 15:06:18 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Fri, 12 Apr 2019 13:58:25 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios"
>>>> <contovob <at> tcd.ie> wrote:
>>>>
>>>>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>>>>> are part of the file name now.
>>>>
>>>> This is indeed due to my changes.  The patch below appears to fix the
>>>> problem, but I'm not sure how robust it is (I was also, and remain,
>>>> unsure about my handling of symlinks in the previous patch, but I
>>>> haven't found time to look at it more closely; at least I haven't seen
>>>> any bug reports about it so far).
>>>
>>> I can confirm your patch fixes the issue, thanks!
>>
>> Thanks for testing.  If there are no objections within a few days, I'll
>> push it to master.
>
> I didn't expect "a few days" to become almost two weeks, but I've
> finally pushed the fix to master as commit 6d8e0fc5aa.  I slightly
> changed the patch to account for using either the short or long form of
> the indicator switch, and I added a test.

Thanks.  I noticed an opportunity for a tiny bit of reuse:

[classify.diff (text/x-diff, inline)]

diff --git a/lisp/dired.el b/lisp/dired.el
index 63082fe392..3050a4bd2d 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -1261,6 +1261,10 @@ dired-switches-recursive-p
   "Return non-nil if the string SWITCHES contains -R or --recursive."
   (dired-check-switches switches "R" "recursive"))
 
+(defun dired-switches-classify-p (switches)
+  "Return non-nil if the string SWITCHES contains -F or --classify."
+  (dired-check-switches switches "F" "classify"))
+
 (defun dired-insert-directory (dir switches &optional file-list wildcard hdr)
   "Insert a directory listing of DIR, Dired style.
 Use SWITCHES to make the listings.
@@ -2588,7 +2592,7 @@ dired-move-to-end-of-filename
   (if (get-text-property (point) 'dired-filename)
       (goto-char (next-single-property-change (point) 'dired-filename))
     (let ((opoint (point))
-          (used-F (dired-check-switches dired-actual-switches "F" "classify"))
+          (used-F (dired-switches-classify-p dired-actual-switches))
           (eol (line-end-position))
           (hidden (dired--hidden-p))
           file-type executable symlink)
diff --git a/lisp/wdired.el b/lisp/wdired.el
index d2a298bd25..1e9c7f6c5a 100644
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -626,8 +626,7 @@ wdired--restore-dired-filename-prop
                          ;; or "classify", don't treat appended
                          ;; indicator characters as part of the file
                          ;; name (bug#34915).
-                         (and (dired-check-switches dired-actual-switches
-                                                    "F" "classify")
+                         (and (dired-switches-classify-p dired-actual-switches)
                               (re-search-forward "[*/@|=>]$" lep t)))
                         (goto-char (match-beginning 0))
                       lep))

[Message part 3 (text/plain, inline)]

Which makes me wonder: is there no Dired function that
wdired--restore-dired-filename-prop can reuse for finding the boundaries
of a file name?  Is dired-move-to-end-of-filename not suitable?  It
seems to perform similar checks for symlinks and --classify.

-- 
Basil

Message #23 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 26 Apr 2019 14:57:53 +0100

[Message part 1 (text/plain, inline)]

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Fri, 12 Apr 2019 15:06:18 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Fri, 12 Apr 2019 13:58:25 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:
>>
>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>
>>>> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios"
>>>> <contovob <at> tcd.ie> wrote:
>>>>
>>>>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>>>>> are part of the file name now.
>>>>
>>>> This is indeed due to my changes.  The patch below appears to fix the
>>>> problem, but I'm not sure how robust it is (I was also, and remain,
>>>> unsure about my handling of symlinks in the previous patch, but I
>>>> haven't found time to look at it more closely; at least I haven't seen
>>>> any bug reports about it so far).
>>>
>>> I can confirm your patch fixes the issue, thanks!
>>
>> Thanks for testing.  If there are no objections within a few days, I'll
>> push it to master.
>
> I didn't expect "a few days" to become almost two weeks, but I've
> finally pushed the fix to master as commit 6d8e0fc5aa.  I slightly
> changed the patch to account for using either the short or long form of
> the indicator switch, and I added a test.

Thanks.  I noticed an opportunity for a tiny bit of reuse:

[classify.diff (text/x-diff, inline)]

diff --git a/lisp/dired.el b/lisp/dired.el
index 63082fe392..3050a4bd2d 100644
--- a/lisp/dired.el
+++ b/lisp/dired.el
@@ -1261,6 +1261,10 @@ dired-switches-recursive-p
   "Return non-nil if the string SWITCHES contains -R or --recursive."
   (dired-check-switches switches "R" "recursive"))
 
+(defun dired-switches-classify-p (switches)
+  "Return non-nil if the string SWITCHES contains -F or --classify."
+  (dired-check-switches switches "F" "classify"))
+
 (defun dired-insert-directory (dir switches &optional file-list wildcard hdr)
   "Insert a directory listing of DIR, Dired style.
 Use SWITCHES to make the listings.
@@ -2588,7 +2592,7 @@ dired-move-to-end-of-filename
   (if (get-text-property (point) 'dired-filename)
       (goto-char (next-single-property-change (point) 'dired-filename))
     (let ((opoint (point))
-          (used-F (dired-check-switches dired-actual-switches "F" "classify"))
+          (used-F (dired-switches-classify-p dired-actual-switches))
           (eol (line-end-position))
           (hidden (dired--hidden-p))
           file-type executable symlink)
diff --git a/lisp/wdired.el b/lisp/wdired.el
index d2a298bd25..1e9c7f6c5a 100644
--- a/lisp/wdired.el
+++ b/lisp/wdired.el
@@ -626,8 +626,7 @@ wdired--restore-dired-filename-prop
                          ;; or "classify", don't treat appended
                          ;; indicator characters as part of the file
                          ;; name (bug#34915).
-                         (and (dired-check-switches dired-actual-switches
-                                                    "F" "classify")
+                         (and (dired-switches-classify-p dired-actual-switches)
                               (re-search-forward "[*/@|=>]$" lep t)))
                         (goto-char (match-beginning 0))
                       lep))

[Message part 3 (text/plain, inline)]

Which makes me wonder: is there no Dired function that
wdired--restore-dired-filename-prop can reuse for finding the boundaries
of a file name?  Is dired-move-to-end-of-filename not suitable?  It
seems to perform similar checks for symlinks and --classify.

-- 
Basil

Message #26 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 34915 <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 26 Apr 2019 18:07:04 +0200

On Fri, 26 Apr 2019 14:56:57 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Fri, 12 Apr 2019 15:06:18 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>>
>>> On Fri, 12 Apr 2019 13:58:25 +0100 "Basil L. Contovounesios"
>>> <contovob <at> tcd.ie> wrote:
>>>
>>>> Stephen Berman <stephen.berman <at> gmx.net> writes:
>>>>
>>>>> On Tue, 19 Mar 2019 13:43:16 +0000 "Basil L. Contovounesios"
>>>>> <contovob <at> tcd.ie> wrote:
>>>>>
>>>>>> It seems like Wdired thinks the indicators added by ls (one of */=>@|)
>>>>>> are part of the file name now.
>>>>>
>>>>> This is indeed due to my changes.  The patch below appears to fix the
>>>>> problem, but I'm not sure how robust it is (I was also, and remain,
>>>>> unsure about my handling of symlinks in the previous patch, but I
>>>>> haven't found time to look at it more closely; at least I haven't seen
>>>>> any bug reports about it so far).
>>>>
>>>> I can confirm your patch fixes the issue, thanks!
>>>
>>> Thanks for testing.  If there are no objections within a few days, I'll
>>> push it to master.
>>
>> I didn't expect "a few days" to become almost two weeks, but I've
>> finally pushed the fix to master as commit 6d8e0fc5aa.  I slightly
>> changed the patch to account for using either the short or long form of
>> the indicator switch, and I added a test.
>
> Thanks.  I noticed an opportunity for a tiny bit of reuse:
[...]

I'm not sure the two uses justify a new function, but I don't oppose it.

> Which makes me wonder: is there no Dired function that
> wdired--restore-dired-filename-prop can reuse for finding the boundaries
> of a file name?  Is dired-move-to-end-of-filename not suitable?  It
> seems to perform similar checks for symlinks and --classify.

dired-move-to-end-of-filename doesn't work in wdired-mode because the
dired-filename text property it uses was removed to fix bug#32173, and
wdired--restore-dired-filename-prop was added to compensate.  I couldn't
come up with a more elegant solution.

Steve Berman

Message #33 received at 34915-done <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 34915-done <at> debbugs.gnu.org
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Fri, 26 Apr 2019 17:20:30 +0100

tags 34915 fixed
close 34915
quit

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Fri, 26 Apr 2019 14:56:57 +0100 "Basil L. Contovounesios" <contovob <at> tcd.ie> wrote:
>
>> Thanks.  I noticed an opportunity for a tiny bit of reuse:
> [...]
>
> I'm not sure the two uses justify a new function, but I don't oppose
> it.

I'll leave it for now.

>> Which makes me wonder: is there no Dired function that
>> wdired--restore-dired-filename-prop can reuse for finding the boundaries
>> of a file name?  Is dired-move-to-end-of-filename not suitable?  It
>> seems to perform similar checks for symlinks and --classify.
>
> dired-move-to-end-of-filename doesn't work in wdired-mode because the
> dired-filename text property it uses was removed to fix bug#32173, and
> wdired--restore-dired-filename-prop was added to compensate.  I couldn't
> come up with a more elegant solution.

Thanks for explaining and for working on this.  Since your patch fixed
the bug, I'm closing this report.

-- 
Basil

Message #40 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: "34915 <at> debbugs.gnu.org" <34915 <at> debbugs.gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Thu, 30 May 2019 19:51:06 +0000

The fix for this bug causes wdired-tests to hang on my system (Cygwin):

$ make -C test wdired-tests
make: Entering directory '/home/kbrown/src/emacs/i686/test'
make[1]: Entering directory '/home/kbrown/src/emacs/i686/test'
   GEN      lisp/wdired-tests.log
Running 5 tests (2019-05-30 15:39:07-0400, selector `(not (tag :unstable))')
Press C-c C-c when finished or C-c ESC to abort changes
Move: 1 of 1
Move: 1 file done
    passed  1/5  wdired-test-bug32173-01 (0.189231 sec)
Press C-c C-c when finished or C-c ESC to abort changes
    passed  2/5  wdired-test-bug32173-02 (0.140659 sec)
(Shell command succeeded with no output)
Connection file "/tmp/emacs197609/server" deleted
Press C-c C-c when finished or C-c ESC to abort changes
Connection file "/tmp/emacs197609/server" deleted

[At this point I kill it with C-c.]

I don't use wdired, so I haven't made a serious effort to track down the cause. 
I thought at first that it might have something to do with the following alias 
that I use:

alias ls='ls -F --color=tty'

But the problem persisted after I moved my .bashrc out of the way.

Ken

Message #43 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: "34915-done <at> debbugs.gnu.org" <34915 <at> debbugs.gnu.org>
Cc: Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Wed, 26 Jun 2019 16:28:26 +0000

On 5/30/2019 3:51 PM, Ken Brown wrote:
> The fix for this bug causes wdired-tests to hang on my system (Cygwin):

This turns out to be purely a Cygwin issue (involving FIFOs), having nothing to 
do with wdired.  Sorry for the noise.

Ken

Message #46 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: "34915-done <at> debbugs.gnu.org" <34915 <at> debbugs.gnu.org>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Wed, 26 Jun 2019 18:57:36 +0200

On Wed, 26 Jun 2019 16:28:26 +0000 Ken Brown <kbrown <at> cornell.edu> wrote:

> On 5/30/2019 3:51 PM, Ken Brown wrote:
>> The fix for this bug causes wdired-tests to hang on my system (Cygwin):
>
> This turns out to be purely a Cygwin issue (involving FIFOs), having nothing to
> do with wdired.  Sorry for the noise.

No problem, on the contrary, I'm relieved, because I know next to
nothing about Cygwin and have no ready access to it (and I'm already in
arrears on dealing with another wdired issue).  So thanks for the good
news ;-)

Steve Berman

Message #55 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: 34915 <at> debbugs.gnu.org
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Mon, 30 Dec 2019 20:38:22 +0100

Sorry about reopening, but wdired-test-bug34915 fails on macOS (and probably BSD in general).
It appears that GNU ls formats symlinks with ls -lF as

.... LINK -> TARGET

but macOS/BSD ls uses

.... LINK@ -> TARGET

which the new code in wdired--restore-dired-filename-prop fails to account for.

This was found on macOS 10.14.

Message #58 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 34915 <at> debbugs.gnu.org,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Sun, 20 Sep 2020 20:14:55 +0200

Mattias Engdegård <mattiase <at> acm.org> writes:

> Sorry about reopening, but wdired-test-bug34915 fails on macOS (and
> probably BSD in general).
> It appears that GNU ls formats symlinks with ls -lF as
>
> .... LINK -> TARGET
>
> but macOS/BSD ls uses
>
> .... LINK@ -> TARGET
>
> which the new code in wdired--restore-dired-filename-prop fails to account for.
>
> This was found on macOS 10.14.

I tries "make wdired-tests" in Mojave, and it doesn't report any
problems.  I seem to remember working on ls -lF-related bits for Macos a
while back, so I'm guessing that fixed this problem, too, and I'm
closing this bug report again.

If the problem persists, send an email to the debbugs address and we'll
reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #63 received at 34915 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 34915 <at> debbugs.gnu.org,
 Stephen Berman <stephen.berman <at> gmx.net>
Subject: Re: bug#34915: 27.0.50; Wdired regression with ls -F
Date: Mon, 21 Sep 2020 11:42:36 +0200

20 sep. 2020 kl. 20.14 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> I tries "make wdired-tests" in Mojave, and it doesn't report any
> problems.  I seem to remember working on ls -lF-related bits for Macos a
> while back, so I'm guessing that fixed this problem, too, and I'm
> closing this bug report again.

Thank you for re-testing! It indeed seems to be fixed on master.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.