Description of problem: Dired not working (I don't know whether this should have been filed under sumo, or under rawhide vs 11, etc. Please forgive and correct as appropriate.) Version-Release number of selected component (if applicable): xemacs-21.5.28-12.fc11.x86_64 When I try a dired I get the following backtrace: Debugger entered--Lisp error: (error "No file on this line") signal(error ("No file on this line")) cerror("No file on this line") apply(cerror "No file on this line" nil) error("No file on this line") dired-manual-move-to-end-of-filename(nil 16 71) dired-insert-set-properties(1 #<marker at 8546 in root 0x1a82c68>) dired-insert-directory("/root/" "-al" nil t) dired-readin-insert("/root/" nil) dired-readin("/root/" #<buffer "root"> nil) dired-internal-noselect("/root/" nil) dired-noselect("~/" nil) #<compiled-function (dirname &optional switches) "...(7)" [switches dirname switch-to-buffer dired-noselect] 4 ("/usr/share/xemacs/xemacs-packages/lisp/dired/dired.elc" . 34964) (dired-read-dir-and-switches "")>("~/" nil) call-interactively(dired) If I don't quit that buffer then I can do a dired, but then if I try to do another one I get the message (in minibuffer) dired-subdir-alist seems to be mangled (Evaluating that in *scratch* gives nil.) Also in that dired, trying to find a file by typing f gives me (minibuffer) No file on this line even though there IS a file on that line.
dired on xemacs is broken due to the new coreutils ls printing an additional character after the mode bits. From info coreutils 'What information is listed' Following the file mode bits is a single character that specifies whether an alternate access method such as an access control list applies to the file. When the character following the file mode bits is a space, there is no alternate access method. When it is a printing character, then there is such a method. GNU `ls' uses a `.' character to indicate a file with an SELinux security context, but no other alternate access method. A file with any other combination of alternate access methods is marked with a `+' character. and this extra character doesn't play well with dired. Temporary workaround. Add to your xemacs init: (set-q dired-ls-program "ls.pl") And create ls.pl in your path to something like: #!/usr/bin/perl open LS, join (" ", '/bin/ls', @ARGV, '|'); while (<LS>) { s/[r\n]+$//g; print substr ($_, 0, 10), substr ($_, 11), "\n"; } close LS;
(In reply to comment #1) Thank you. My quality of life has just improved significantly.
Yes, couldn't leave the house this morning before fixing this. F11 killed about 5 critical things on my home machine and without dired mode it is very hard to fix them :-) Couple of typos in my comment#1 though. Hope you caught them: It should be: (setq dired-ls "ls.pl") and s/[\r\n]+$//g; i.e. extra - on first line, missing \ on \r on second. Obviously someone needs to fix dired for xemacs. I'll peek tonight whether this has been fixed on the emacs branch and if not I'll try my lisp skills. Seems idiotic that this was added to ls without a flag to turn it off.
(In reply to comment #3) > Couple of typos in my comment#1 though. Hope you caught them: > It should be: > (setq dired-ls "ls.pl") > and > s/[\r\n]+$//g; > i.e. extra - on first line, missing \ on \r on second. I fixed the first. Dired seemed to work without fixing the second. I now see that, while dired works, s (sort by time) in dired mode still does not. It says in minibuffer "dired-subdir-alist seems to be mangled".
Just tried and dired/sort-by-time works fine on my home machine.
(In reply to comment #5) > Just tried and dired/sort-by-time works fine on my home machine. Ok, the problem was that I was using an old dired buffer that I managed to create before your fix. Now I create a new one and it works. Whew!
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
My ls.pl above doesn't work if file names have spaces. This one does (but it can probably be written a bit better,...) #!/usr/bin/perl $cmd = '/bin/ls '; while ($arg = shift @ARGV) { if ($arg =~ /^-/) { $cmd .= "$arg "; } else { $cmd .= '"'. $arg; last; } } $cmd .= join (' ', @ARGV) . '"|'; open LS, $cmd; while (<LS>) { s/[\r\n]+$//g; print substr ($_, 0, 10), substr ($_, 11), "\n"; } close LS;
I have asked the dired maintainer for advice on how to fix this in the dired code itself, so that ls.pl is not necessary. Thank you for providing that workaround in the meantime.
Created attachment 349255 [details] dired.el patch Ok, so my perl above is a bit too verbose. Even shorter version: #!/usr/bin/perl open LS, join (' ', '/bin/ls', map ({ "\"$_\""} @ARGV), '|'); map { s/[\r\n]+$//g; print substr ($_, 0, 10), substr ($_, 11), "\n" } <LS>; close LS; which I wrote on the bus in to work, and I'm pretty sure this can be made one liner. HOWEVER the dired fix is much simpler, it just took me longer to find the problem as my ELISP capabilities were never very good. It turns out that one can add a single "." in a strategic place of dired.el and fix the whole thing. Edit /usr/share/xemacs/xemacs-packages/lisp/dired/dired.el Look for the following line "[^ ][-r][-w][^ ][-r][-w][^ ][-r][-w][^ ][-+ 0-9@]" and add a "." to the last bracketed sequence, i.e. make it "[^ ][-r][-w][^ ][-r][-w][^ ][-r][-w][^ ][-+ 0-9@.]" Patch attached. Byte compile the .el (as root), unset the dired-ls-program in your init, restart xemacs (well...) and there you go. Or copy/paste the definition of dired-manual-move-to-end-of-filename to your init apply the fix and reload it after loading dired.el, maybe via after-load-alist entry. Or whatever way you like to do these things. Is there a dired bugzilla bug I can post my patch to, if needed?
M-x dired-report-bug will create a mail message with some information already filled in for you. Thanks for figuring this out. I'm working on fixing a couple of other bugs, and will then roll new packages.
xemacs-packages-base-20090217-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/xemacs-packages-base-20090217-2.fc11
xemacs-packages-base-20090217-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update xemacs-packages-base'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9006
xemacs-packages-base-20090217-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
xemacs-packages-extra-20090217-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/xemacs-packages-extra-20090217-2.fc11
*** Bug 521534 has been marked as a duplicate of this bug. ***
I believe this problem is still not fixed. My xemacs package list: xemacs-packages-extra-info-20090217-1.fc11.noarch xemacs-ebib-el-1.8.0-1.fc11.noarch xemacs-ess-el-5.3.10-2.fc11.noarch xemacs-el-21.5.29-2.fc11.i586 xemacs-anthy-el-9100h-8.fc11.i586 xemacs-info-21.5.29-2.fc11.noarch xemacs-debuginfo-21.5.28-12.fc11.i586 xemacs-common-21.5.29-2.fc11.i586 xemacs-packages-base-el-20090217-3.fc11.noarch xemacs-uim-1.5.6-1.fc11.i586 xemacs-devel-21.5.29-2.fc11.i586 xemacs-ess-5.3.10-2.fc11.noarch xemacs-aplus-fsf-4.22.4-15.fc11.noarch xemacs-anthy-9100h-8.fc11.i586 xemacs-ebib-1.8.0-1.fc11.noarch xemacs-packages-extra-el-20090217-1.fc11.noarch xemacs-muse-el-3.12-2.fc11.noarch xemacs-packages-base-20090217-3.fc11.noarch xemacs-21.5.29-2.fc11.i586 xemacs-nox-21.5.29-2.fc11.i586 xemacs-muse-3.12-2.fc11.noarch xemacs-tuareg-el-1.45.6-7.fc11.1.noarch xemacs-packages-extra-20090217-1.fc11.noarch xemacs-tuareg-1.45.6-7.fc11.1.noarch I used the yum command in comment #13 and it did not update any rpm's - so either the command is wrong or that is an RPM I already have. In either case dired still does not work.
The bug is fixed by the package in comment 15, which is still in testing. If you would like to help test it, please install it from the testing repository and submit your feedback via the karma system. Thank you.
Comment 15 points to a ...-2.fc11 packages, but there's a ...-3.fc11 package in testing, and that one includes the fix for dired
I seem to have successfully confused everyone. Sorry, folks! Let's try to straighten this out. xemacs-packages-base-20090217-2.fc11 or later plus xemacs-packages-extra-20090217-2.fc11 is needed to solve the dired bug. The former has already been pushed to stable (and I mistakenly allowed the push to close this bug). The latter is currently in testing, and is the package referred to in comment 15. Meanwhile xemacs-packages-base-20090217-3.fc11 (note that it is *base*, not *extra*) has been pushed to testing to solve a different bug. That package is not needed to fix the dired bug. I usually leave a package in testing for at least a week to give people a chance to try it out. However, I also use the karma system. Please note on https://admin.fedoraproject.org/updates/F11/FEDORA-2009-9310 whether this update solves your problem or not. Karma of 3 will immediately push the update to stable; karma of -3 will immediately unpush the update.
xemacs-packages-extra-20090217-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.