From: Jean Louis <bugs@gnu.support>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 47432@debbugs.gnu.org, Lars Ingebrigtsen <larsi@gnus.org>,
arthur.miller@live.com
Subject: bug#47432: 28.0.50; Dired using ! or & on file should fail without command supplied
Date: Mon, 29 Mar 2021 21:51:41 +0300 [thread overview]
Message-ID: <YGIhvT5rtj+iBFZz@protected.localdomain> (raw)
In-Reply-To: <83czvjofw1.fsf@gnu.org>
* Eli Zaretskii <eliz@gnu.org> [2021-03-28 11:13]:
> > Date: Sun, 28 Mar 2021 10:50:37 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 47432@debbugs.gnu.org
> >
> > * Arthur Miller <arthur.miller@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
next prev parent reply other threads:[~2021-03-29 18:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-27 7:09 bug#47432: 28.0.50; Dired using ! or & on file should fail without command supplied Jean Louis
2021-03-27 7:51 ` Arthur Miller
2021-03-27 8:42 ` Jean Louis
2021-03-27 13:59 ` Arthur Miller
2021-03-27 18:54 ` Jean Louis
2021-03-27 20:28 ` Arthur Miller
2021-03-28 7:50 ` Jean Louis
2021-03-28 8:13 ` Eli Zaretskii
2021-03-29 18:51 ` Jean Louis [this message]
2021-03-29 19:23 ` Eli Zaretskii
2021-03-28 14:03 ` Lars Ingebrigtsen
2021-03-28 15:00 ` Andreas Schwab
2021-03-28 15:06 ` Lars Ingebrigtsen
2021-03-29 18:55 ` Jean Louis
2021-03-29 18:34 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YGIhvT5rtj+iBFZz@protected.localdomain \
--to=bugs@gnu.support \
--cc=47432@debbugs.gnu.org \
--cc=arthur.miller@live.com \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).