GNU bug report logs -
#30285
dired-do-chmod vs. top line of dired
Previous Next
Full log
Message #23 received at 30285 <at> debbugs.gnu.org (full text, mbox):
> >> > (Why doesn't it just complain "can't operate on" like it does for
> the
> >> > third line, ".".)
> >> Following patch just do nothing in these cases. That's OK for me.
> >> Do you prefer to inform the user in this case that there is no file
> >> to change the mode?
> >
> > Yes, I think we should produce some message in these cases.
> OK. Then, we must adjust other siblings commands (dired-do-chgrp,
> dired-do-chown); otherwise they might become jealous.
> I propose to add a new predicate
> `dired-marked-files-or-file-at-point-p', and used it in all those
> commands.
Please don't do any such thing.
Yes, it makes sense for such commands to do nothing or to show an
error message when on the "top line of dired", as described in the
bug report.
No, we don't need a function `dired-marked-files-or-file-at-point-p',
for that or anything else. The `dired-do-*' commands already DTRT
wrt the marked-files-or-file-at-point.
And no, it doesn't make sense to act that way on `.' - it's OK to
change the properties of the current directory (provided you have
the necessary permissions). And that's not even part of this bug
report, is it?
The question of `..' is arguable, but I'd say the same thing for
it as for `.': It's OK to change its properties, provided you have
permission to do so. After all, `..' is just a (unique) directory.
How did this bug report move from being about behavior on the top
line (and the second, "total" etc. line) to being also about the
lines for `.' and `..'?
This bug report was last modified 7 years and 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.