Subject: bug#47432: 28.0.50; Dired using ! or & on file should fail without command supplied

From: Jean Louis <[email-masked]>
Date: Mon, 29 Mar 2021 21:51:41 +0300

* Eli Zaretskii <[email-masked]> [2021-03-28 11:13]:
> > Date: Sun, 28 Mar 2021 10:50:37 +0300
> > From: Jean Louis <[email-masked]>
> > Cc: [email-masked]
> > 
> > * Arthur Miller <[email-masked]> [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