GNU bug report logs -
#47432
28.0.50; Dired using ! or & on file should fail without command supplied
Previous Next
Reported by: Jean Louis <bugs <at> gnu.support>
Date: Sat, 27 Mar 2021 07:14:01 UTC
Severity: wishlist
Tags: fixed
Found in version 28.0.50
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
* Eli Zaretskii <eliz <at> gnu.org> [2021-03-28 11:13]:
> > Date: Sun, 28 Mar 2021 10:50:37 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 47432 <at> debbugs.gnu.org
> >
> > * Arthur Miller <arthur.miller <at> live.com> [2021-03-27 23:29]:
> > > Emacs is not executing them, Emacs is passing them to the shell. Same
> > > happends as if you tried to execute that file from the command
> > > prompt.
> >
> > Maybe in your opinion, not that I have same opinion, look:
> >
> > In Emacs, I press ! because I wish to write a command to be executed
> > on the file, not to execute empty command which I did not write. When
> > I press RET without entering command, I expect nothing to happen.
>
> Is this expectation consistent with the documentation of '!'?
> Specifically, how are you sure that an empty COMMAND does nothing in
> the shell?
In some cases it does call the marked file, but those other cases
should be excluded -- or documentation improved to tell users why is
it so.
Since Larse explained about the concatenation of COMMAND and
FILE-LIST, I understand technically why is that happening, but I do
not understand logic behind it.
When there are let us say 50 images that I wish to convert, and if I
forget to give a command like
! * [on 50 files]: mogrify -format jpg
and instead I give ""
then all those pictures will be "executed", attempted to be
executed. That makes no sense to me
> > - description of function does not say that empty RET should be
> > considered "COMMAND", there is no mentioning (I could miss it maybe)
> > that file itself will be executed;
> >
> > - info manual does not reflect that what you are speaking. It says:
> > "The Dired command ‘!’ (‘dired-do-shell-command’) reads a shell
> > command string in the minibuffer, and runs that shell command on one
> > or more files."
>
> None of the above says anything about the effect of an empty string as
> COMMAND.
That is basically what I am pointing out, thank you, but seem that we
have disagreement.
In my opinion:
- it should be clear WHY is it useful to allow empty string to be
accepted as COMMAND as the logical function should execute COMMAND
as non-empty string;
- document that so that it becomes clear; I am myself still trying to
understand as the prompt says to execute ON files, not to execute
files.
- documentation of the function and info manual should be aligned with
that functionality;
- and still I think that images and various files, directories, should
not be executed. Only if the file has executable bit it should be
executed -- this is current behavior on executable files.
Let me give you more from researching how it works:
- if there is script.pl or script.sh, then ! or & will verify for
executable bit, and execute it only if set; BUT it is not executing
THE FILE which is marked!
Replicate it by putting one non-executable script.sh in your PATH
and going to directory that is not in your path that has executable
script.sh in that path, do ! or & on that command.
script.sh:
#!/bin/bash
echo Hello, it worked
----
put same script in your PATH, like maybe ~/bin/script.sh and make it
non-executable.
put same file, but executable in other directory ~/tmp/script.sh
go with Dired to ~/tmp/script.sh as it is executable, so do ! or &
and it will try to execute which file?
Definitely not ~/tmp/script.sh but it will try to execute
"script.sh" in PATH.
So think about that, there is no logic that FILE-LIST is appended to
empty COMMAND like "" as that FILE-LIST is not getting executed
really, so it is misleading the user.
Jean Louis
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
This bug report was last modified 4 years and 53 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.