info inconsistency about "Shell Commands in Dired"

info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

Hi,

In the section "Shell Commands in Dired" of Emacs Info, 
I found following lines:

   * If the command string contains `?' surrounded by whitespace, the
     current file name is substituted for `?'.  You can use `?' this
     way more than once in the command, and each occurrence is
     replaced.  For instance, here is how to uuencode each file, making
     the output file name by appending `.uu' to the input file name:

          uuencode ? ? > ?.uu

?.uu is surrounded by whitespace. So above command line generated an
unexpected file.

Masatake YAMATO

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Masatake YAMATO wrote:

   In the section "Shell Commands in Dired" of Emacs Info, 
   I found following lines:

      * If the command string contains `?' surrounded by whitespace, the
	current file name is substituted for `?'.  You can use `?' this
	way more than once in the command, and each occurrence is
	replaced.  For instance, here is how to uuencode each file, making
	the output file name by appending `.uu' to the input file name:

	     uuencode ? ? > ?.uu

   ?.uu is surrounded by whitespace. So above command line generated an
   unexpected file.

You mean that the third ? is _not_ surrounded by whitespace?  I indeed
believe that the example is wrong.  The third ? is not substituted
and the output goes to a file named ?.uu.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

> Masatake YAMATO wrote:
> 
>    In the section "Shell Commands in Dired" of Emacs Info, 
>    I found following lines:
> 
>       * If the command string contains `?' surrounded by whitespace, the
> 	current file name is substituted for `?'.  You can use `?' this
> 	way more than once in the command, and each occurrence is
> 	replaced.  For instance, here is how to uuencode each file, making
> 	the output file name by appending `.uu' to the input file name:
> 
> 	     uuencode ? ? > ?.uu
> 
>    ?.uu is surrounded by whitespace. So above command line generated an
>    unexpected file.
> 
> You mean that the third ? is _not_ surrounded by whitespace?  I indeed
> believe that the example is wrong.  The third ? is not substituted
> and the output goes to a file named ?.uu.

What you believe is what I meant. The example is wrong. One of the
solution is to remove the example from the texi. However, dired users
may be happy if the users can do:
> 	     uuencode ? ? > ?.uu
Yesterday I tried "tar cvf ?.tar ?"; and I got ?.tar file.

How do you think accepting `-' and `.' in addition to the whitespace?
I have considered more generic extension, however I have got no idea.

Masatake YAMATO

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Masatake YAMATO wrote:

   How do you think accepting `-' and `.' in addition to the whitespace?
   I have considered more generic extension, however I have got no idea.

That would be pretty easy.  See the patch below.  That patch actually
allows `.', `-' _and_ `_".  If all we are worried about are extensions,
then that should be sufficient.  Is `-' even needed?  Is there an
operating system that uses this for extensions?  Are there any
operating systems that would suggest allowing other characters for
extensions?

A more generic solution would require more changes to the code, and
one has to be careful with them.

===File ~/dired-aux-diff====================================
*** dired-aux.el	19 Jul 2004 11:13:15 -0500	1.126
--- dired-aux.el	21 Aug 2004 14:20:47 -0500	
***************
*** 43,50 ****
  ;;;###begin dired-cmd.el
  ;; Diffing and compressing
  
! (defconst dired-star-subst-regexp "\\(^\\|[ \t]\\)\\*\\([ \t]\\|$\\)")
! (defconst dired-quark-subst-regexp "\\(^\\|[ \t]\\)\\?\\([ \t]\\|$\\)")
  
  ;;;###autoload
  (defun dired-diff (file &optional switches)
--- 43,50 ----
  ;;;###begin dired-cmd.el
  ;; Diffing and compressing
  
! (defconst dired-star-subst-regexp "\\(^\\|[ \t]\\)\\*\\([ \t._-]\\|$\\)")
! (defconst dired-quark-subst-regexp "\\(^\\|[ \t]\\)\\?\\([ \t._-]\\|$\\)")
  
  ;;;###autoload
  (defun dired-diff (file &optional switches)
***************
*** 540,546 ****
  	     (lambda (x)
  	       (let ((retval command))
  		 (while (string-match
! 			 "\\(^\\|[ \t]\\)\\([*?]\\)\\([ \t]\\|$\\)" retval)
  		   (setq retval (replace-match x t t retval 2)))
  		 retval))
  	   (lambda (x) (concat command dired-mark-separator x)))))
--- 540,546 ----
  	     (lambda (x)
  	       (let ((retval command))
  		 (while (string-match
! 			 "\\(^\\|[ \t]\\)\\([*?]\\)\\([ \t._-]\\|$\\)" retval)
  		   (setq retval (replace-match x t t retval 2)))
  		 retval))
  	   (lambda (x) (concat command dired-mark-separator x)))))
============================================================

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

       How do you think accepting `-' and `.' in addition to the whitespace?

Please don't do this.  It solves one problem by creating another.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

I believe I misunderstood some remarks in `(elisp)Standard File Names'.

I thought I understood from it that MS-DOS uses `_' for extensions, but
after careful reading, it appears to use `_' for "invisible" files.

So maybe we should allow [ \t._] before the [?*] (to allow making
files invisible) and [ \t.] after the file.  Unless we want to go for
a more general solution.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Eli Zaretskii]

> Date: Sat, 21 Aug 2004 15:35:45 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> Cc: emacs-devel@gnu.org
> 
> I believe I misunderstood some remarks in `(elisp)Standard File Names'.
> 
> I thought I understood from it that MS-DOS uses `_' for extensions, but
> after careful reading, it appears to use `_' for "invisible" files.

There are no invisible files on MS-DOS.  It's just that the DOS
filesystem disallows leading dots in file names, so Emacs converts
that to an underscore.  That doesn't make the file invisible.

And the character before the extension is still a dot on DOS.

I admit that I don't see how is this relevant to the issue of ?.uu,
though.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Eli Zaretskii wrote:

   I admit that I don't see how is this relevant to the issue of ?.uu,
   though.

Not if we go for the generic solution I eventually wound up proposing.
But earlier I was thinking of allowing specific characters to act
analogously to space.  Those would be the characters used to make
files invisible and characters used as extensions.  I now believe a
generic solution is better.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

On second thought, I believe we should allow [ \t._] both before and
after the [?*].  If nothing else, that is easier to explain.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

On second thought, I believe that it is better to go for a generic
solution.  i will send a patch doing so.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Eli Zaretskii]

> Date: Fri, 20 Aug 2004 19:40:12 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
>       * If the command string contains `?' surrounded by whitespace, the
> 	current file name is substituted for `?'.  You can use `?' this
> 	way more than once in the command, and each occurrence is
> 	replaced.  For instance, here is how to uuencode each file, making
> 	the output file name by appending `.uu' to the input file name:
> 
> 	     uuencode ? ? > ?.uu
> 
>    ?.uu is surrounded by whitespace. So above command line generated an
>    unexpected file.
> 
> You mean that the third ? is _not_ surrounded by whitespace?  I indeed
> believe that the example is wrong.  The third ? is not substituted
> and the output goes to a file named ?.uu.

I think we had better fix the code instead of removing the example.
It seems a pity that the example doesn't work.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    ?.uu is surrounded by whitespace. So above command line generated an
    unexpected file.

The change that makes ? operate this way only when followed by whitespace
made the example incorrect.  As far as I can see, there is no simple way
to make this example work again:

          uuencode ? ? > ?.uu

Does anyone see a way that I don't see?
If not, I will just delete the example.

It is sort of unfortunate if there's no way now to
substitute the file name and add an extension to it.

Re: info inconsistency about "Shell Commands in Dired"

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     ?.uu is surrounded by whitespace. So above command line generated an
>     unexpected file.
> 
> The change that makes ? operate this way only when followed by whitespace
> made the example incorrect.  As far as I can see, there is no simple way
> to make this example work again:
> 
>           uuencode ? ? > ?.uu
> 
> Does anyone see a way that I don't see?

uuencode ? ? > `echo ? `.uu

If everybody is finished laughing...  Maybe one should allow it
surrounded by quotes, something like

  '?'.uu

> If not, I will just delete the example.
> 
> It is sort of unfortunate if there's no way now to
> substitute the file name and add an extension to it.

Yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

David Kastrup wrote:

   If everybody is finished laughing...  Maybe one should allow it
   surrounded by quotes, something like

     '?'.uu

Using '?' for this purpose is counterintuitive.  '?' has a well
established meaning of "literal ?".

Why not handle this problem in complete symmetry with the opposite problem?

>From `(emacs)Shell Commands in Dired':

     If you want to use `*' as a shell wildcard with whitespace around
     it, write `*""'.  In the shell, this is equivalent to `*'; but
     since the `*' is not surrounded by whitespace, Dired does not
     treat it specially.

This does not take care of the case where the `*' or `?'  occurs
within single quotes, in which case it is probably meant to be taken
literally.  (_Neither_ to be expanded by Emacs _nor_ treated as a
shell wildcard.)  It actually _does_ take care of the similar double
quote situation.

In these cases, one probably has to do:  "... *"" ..."
or: '... *'' ...' to prevent expansion by Emacs.

Maybe that should be pointed out in `(emacs)Shell Commands in Dired'.

My proposed generic solution handles the opposite problem (which we
are now considering) analogously: Emacs allows '' as a substitute for
whitespace in deciding whether to replace the ? or * with the file name.

Unless the * or ? occurs within double quotes, the '' does not matter
to the shell.  If one wants to use a literal <SPC>?'' or such, the above
happens to do the right thing anyway for single quotes, as it does for
the opposite problem with double quotes.  If one is using double
quotes, one has to do: "... ?""''...".

The manual example would become:

          uuencode ? ? > ?''.uu

Complete symmetry between both sides of the problem.

Here is the patch, in case the above would be OK:

===File /home/teirllm/dired-aux-diff-b======================
*** dired-aux.el	19 Jul 2004 11:13:15 -0500	1.126
--- dired-aux.el	21 Aug 2004 16:28:30 -0500	
***************
*** 43,50 ****
  ;;;###begin dired-cmd.el
  ;; Diffing and compressing
  
! (defconst dired-star-subst-regexp "\\(^\\|[ \t]\\)\\*\\([ \t]\\|$\\)")
! (defconst dired-quark-subst-regexp "\\(^\\|[ \t]\\)\\?\\([ \t]\\|$\\)")
  
  ;;;###autoload
  (defun dired-diff (file &optional switches)
--- 43,52 ----
  ;;;###begin dired-cmd.el
  ;; Diffing and compressing
  
! (defconst dired-star-subst-regexp
!   "\\(^\\|[ \t]\\|''\\)\\*\\([ \t]\\|''\\|$\\)")
! (defconst dired-quark-subst-regexp
!   "\\(^\\|[ \t]\\|''\\)\\?\\([ \t]\\|''\\|$\\)")
  
  ;;;###autoload
  (defun dired-diff (file &optional switches)
***************
*** 540,546 ****
  	     (lambda (x)
  	       (let ((retval command))
  		 (while (string-match
! 			 "\\(^\\|[ \t]\\)\\([*?]\\)\\([ \t]\\|$\\)" retval)
  		   (setq retval (replace-match x t t retval 2)))
  		 retval))
  	   (lambda (x) (concat command dired-mark-separator x)))))
--- 542,549 ----
  	     (lambda (x)
  	       (let ((retval command))
  		 (while (string-match
! 			 "\\(^\\|[ \t]\\|''\\)\\([*?]\\)\\([ \t]\\|''\\|$\\)"
! 			 retval)
  		   (setq retval (replace-match x t t retval 2)))
  		 retval))
  	   (lambda (x) (concat command dired-mark-separator x)))))
============================================================

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

>From my previous message:

   or: '... *'' ...' to prevent expansion by Emacs.

I forgot to notice that _after my patch_, one has to do:

'... '\*' ..." to prevent expansion and insert a _literal_ <SPC>*<SPC>.
Anyway, this is not _that_ much more difficult and the situation
occurs extremely rarely.

   If one wants to use a literal <SPC>?'' or such, the above
   happens to do the right thing anyway for single quotes, as it does for
   the opposite problem with double quotes.

Not quite.  One can not use ' to quote ' anyway.  One _has_ to use "".
Thus the problem with ' is non-existent.

Sorry for these mess-ups.  But they do not affect the patch, nor the
proposed solution.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

>From my previous message:

   I forgot to notice that _after my patch_, one has to do:

   '... '\*' ..." to prevent expansion and insert a _literal_ <SPC>*<SPC>.

That was a typo.  I meant:

'... '\*' ...'

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

How do you think using `format' function directly instead of `?' ?

e.g.

	uuencode %s %s > %s.uu

Advantage:
- If the user want to `%' itself in the command line, format function
  can handle it:

      echo %%s

- Implementation is not so difficult(for us).

- Substitution rule is not so difficult(for users).

Disadvantage
- We have to throw away everything about `?', the manual description, 
  code, and the users' experience.

Masatake

Re: info inconsistency about "Shell Commands in Dired"

[David Kastrup]

Masatake YAMATO <jet@gyve.org> writes:

> How do you think using `format' function directly instead of `?' ?
> 
> e.g.
> 
> 	uuencode %s %s > %s.uu
> 
> Advantage:
> - If the user want to `%' itself in the command line, format function
>   can handle it:
> 
>       echo %%s
> 
> - Implementation is not so difficult(for us).

Not?  How do you call the format function?  Depends on the number of
%s...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

> > How do you think using `format' function directly instead of `?' ?
> > 
> > e.g.
> > 
> > 	uuencode %s %s > %s.uu
> > 
> > Advantage:
> > - If the user want to `%' itself in the command line, format function
> >   can handle it:
> > 
> >       echo %%s
> > 
> > - Implementation is not so difficult(for us).
> 
> Not?  How do you call the format function?  Depends on the number of
> %s...

Good point.
I found next code works.

    (apply 'format "echo %s" '("a" "a" "a"))
    => "echo a"

So we can pass arguments as much as possible:-P.

Re: info inconsistency about "Shell Commands in Dired"

[David Kastrup]

Masatake YAMATO <jet@gyve.org> writes:

> > > How do you think using `format' function directly instead of `?' ?
> > > 
> > > e.g.
> > > 
> > > 	uuencode %s %s > %s.uu
> > > 
> > > Advantage:
> > > - If the user want to `%' itself in the command line, format function
> > >   can handle it:
> > > 
> > >       echo %%s
> > > 
> > > - Implementation is not so difficult(for us).
> > 
> > Not?  How do you call the format function?  Depends on the number of
> > %s...
> 
> Good point.
> I found next code works.
> 
>     (apply 'format "echo %s" '("a" "a" "a"))
>     => "echo a"
> 
> So we can pass arguments as much as possible:-P.

As much as possible?
(apply 'format "echo %s %s %s %s" '#1=("a" . #1#))

Just turns out that apply is not too happy about passing infinitely
long argument lists on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

> > > > How do you think using `format' function directly instead of `?' ?
> > > > 
> > > > e.g.
> > > > 
> > > > 	uuencode %s %s > %s.uu
> > > > 
> > > > Advantage:
> > > > - If the user want to `%' itself in the command line, format function
> > > >   can handle it:
> > > > 
> > > >       echo %%s
> > > > 
> > > > - Implementation is not so difficult(for us).
> > > 
> > > Not?  How do you call the format function?  Depends on the number of
> > > %s...
> > 
> > Good point.
> > I found next code works.
> > 
> >     (apply 'format "echo %s" '("a" "a" "a"))
> >     => "echo a"
> > 
> > So we can pass arguments as much as possible:-P.
> 
> As much as possible?
> (apply 'format "echo %s %s %s %s" '#1=("a" . #1#))
> 
> Just turns out that apply is not too happy about passing infinitely
> long argument lists on.

Sorry. "as much as possible" is wrong expression.

What I'd like to say is:

(defun count-%s (string)
  (let ((count 0)
	(pos 0))
    (while (string-match "%s" string pos)
      (setq pos (match-end 0))
      (setq count (1+ count)))
    count))

(let ((cmdline "echo %s %s %s %s")
      (filenanme "a"))
   (apply 'format cmdline (make-list (count-%s cmdline) filenanme)))
=> "echo a a a a"

However, we don't have to take care about "%%s".
Even if %%s is appeared on the `cmdline', we can count it as one.
Giving the `filename' as arguments for `format' more than necessary is
ok.

(let ((cmdline "echo %%s %%s %%s %s")
      (filenanme "a"))
   (apply 'format cmdline (make-list (count-%s cmdline) filenanme)))
=> "echo %s %s %s a"

Anyway, I think using an environment varaible method I wrote in 
another mail is better than this method.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

How about passing file names via environment variables?
So the user can specify the environment variables to use the file names.

We use ${dired} for the replacement of `?'; and ${DIRED} for the
replacement of `*'. Prepend "export dired=...; export DIRED=...;" 
to the command line given from the user.

So the user can use following command line to invoke uuencode:

   uuencode ${dired} ${dired} > ${dired}.uu

Of couser the variable name should be customizable.
We don't have to remove `*' and `?' replacement; the old method
and new method can live together.

Masatake

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Masatake YAMATO wrote:
   
   How about passing file names via environment variables?
   So the user can specify the environment variables to use the file names.

   We use ${dired} for the replacement of `?'; and ${DIRED} for the
   replacement of `*'. Prepend "export dired=...; export DIRED=...;" 
   to the command line given from the user.

${dired} is as long to type as `echo ? `.  I am not even sure that
`echo ? ` is really a joke as David suggested.  Having to use
something that is somewhat funny looking is not too bad if you only
have to do it very infrequently.  So, if we actually consider having
to type eight characters acceptable, then no code change would be
necessary.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

Before continuing discussion, I'd like to add explanation which
I forget writing in the last mail.

I wrote:
> How about passing file names via environment variables?
> So the user can specify the environment variables to use the file names.
> 
> We use ${dired} for the replacement of `?'; and ${DIRED} for the
> replacement of `*'. Prepend "export dired=...; export DIRED=...;" 
> to the command line given from the user.

"export dired=...; export DIRED=...;" is perpend to the command line by
dired automatically. I misused an imperative form, "Prepend". 
I should use "Dired prepends".

Go back to the discussion.

Luc Teirlinck worte:
>    How about passing file names via environment variables?
>    So the user can specify the environment variables to use the file names.
> 
>    We use ${dired} for the replacement of `?'; and ${DIRED} for the
>    replacement of `*'. Prepend "export dired=...; export DIRED=...;" 
>    to the command line given from the user.
> 
> ${dired} is as long to type as `echo ? `.  I am not even sure that
> `echo ? ` is really a joke as David suggested.  Having to use
> something that is somewhat funny looking is not too bad if you only
> have to do it very infrequently.  

Normally, the user should use ? and *. The user can ignore the environment
variables. If you tihnk ${dired} is too long, we can introduce shorter 
variable name. In some case we don't have to use `{' and `}', as you know.

The biggest advantage of this method is that it is not tricky. If one 
knows the shell script syntax, s/he can use this method.

In other hand, about `?' and `*', I have to read *Help* buffer for `
dired-do-shell-command' and the info document when "uuencode ? ? >
?.uu" generates a file, ?.uu.

About `echo ? `, I don't want to explain this technique for my wife:-P

Masatake YAMATO

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Your environment variable suggestion is not as easy as it appears.

First of all, we can not leave things up to the shell.  We have to
scan for ${DIRED} or $DIRED ourselves first, because we need to know
whether it occurs to see whether we have to run the shell command
just once or once for each file.

Now trouble starts.

Emacs will expand the * in:

'  *  '

Does the $DIRED in the following count or not? That is, does it get
expanded and does it cause the command to run just once?

'${DIRED}'

Since it is a substitute for * it should "count", but since it is a
quoted environment variable it should not count.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

> Your environment variable suggestion is not as easy as it appears.
I read all of your message; and agree with you.
I understand the implementation is not so simple.

> First of all, we can not leave things up to the shell.  
As you wrote, what I wanted is we leave things up to the shell.

I think using shell syntax directory is better than adding extra
syntax in dired even if the amount of typing by an user increases.
In some case, avoding mistaking is more impotent than quick operation.

The next example is not so realistic but worth to consider:

    login: root
    Password: *****
    # emacs
    M-x dired 
    Dired (directory): /
    m on some files 
    !
       rm -rf *

If syntax added in dired for * becomes more complex(e.g. putting ''
around *), I'm afraid to use ! in this case.

       rm -rf ${DIRED}

The uesr will feel easier. Especially the uesr ues both the latest emacs
in the CVS repository and older emacs.

Anyway, dired needs new command line parser.  Many objections will be
but I propose remove * and ? from dired and introduce ${dired} and
${DIRED}.

Masatake YAMATO

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Masatake YAMATO wrote:

    How do you think using `format' function directly instead of `?' ?

    e.g.

	    uuencode %s %s > %s.uu

How do you handle both ? and * this way?  Does %s stand for `*' or `?'?

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Masatake YAMATO]

> Masatake YAMATO wrote:
> 
>     How do you think using `format' function directly instead of `?' ?
> 
>     e.g.
> 
> 	    uuencode %s %s > %s.uu
> 
> How do you handle both ? and * this way?  Does %s stand for `*' or `?'?

%s just stands for `?'.
A problem occurs if a file name which replceas `%s' contains `*'.
We have to take into the order or replacement.
So not I think this method is not good.

Masatake

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    Why not handle this problem in complete symmetry with the opposite problem?

    >From `(emacs)Shell Commands in Dired':

	 If you want to use `*' as a shell wildcard with whitespace around
	 it, write `*""'.  In the shell, this is equivalent to `*'; but
	 since the `*' is not surrounded by whitespace, Dired does not
	 treat it specially.

I expect that this rule does in fact apply to ? just as to *, but
people have less occasion to write ?"" than they have to write *"".

    My proposed generic solution handles the opposite problem (which we
    are now considering) analogously: Emacs allows '' as a substitute for
    whitespace in deciding whether to replace the ? or * with the file name.

It is worth thinking about.
I saw people discussing other methods, %s and envvars.
The envvar method is too inconvenient.  %s might be acceptable;
people mainly discussed how to implement it.

Let's compare these two methods in terms of desirability as
features.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Richard Stallman wrote:

	    If you want to use `*' as a shell wildcard with whitespace around
	    it, write `*""'.  In the shell, this is equivalent to `*'; but
	    since the `*' is not surrounded by whitespace, Dired does not
	    treat it specially.

   I expect that this rule does in fact apply to ? just as to *,

Yes.

   It is worth thinking about.
   I saw people discussing other methods, %s and envvars.
   The envvar method is too inconvenient.  %s might be acceptable;
   people mainly discussed how to implement it.

   Let's compare these two methods in terms of desirability as
   features.

I believe that the method I proposed offers the least deviation from
the current syntax.  

Of course, while ?'' will be useful in several situations, *'' will
very seldom (if ever) be, unless only one file is marked.  I
nevertheless would make the syntax work for * too, for consistency.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

       I saw people discussing other methods, %s and envvars.
       The envvar method is too inconvenient.  %s might be acceptable;
       people mainly discussed how to implement it.

       Let's compare these two methods in terms of desirability as
       features.

    I believe that the method I proposed offers the least deviation from
    the current syntax.  

What method is that?  Is it one of the two I described above,
or something else?

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Richard Stallman wrote:

   What method is that?  Is it one of the two I described above,
   or something else?

The method I proposed was to expand if the ? (or *) was followed on
both sides by either whitespace _or_ ''.  So one could do:

mv ? .''?

or:

mv ? ?''.uu

to prepend . or append .uu

In the Emacs manual it is recommended to use the similar trick *"" to
include an isolated * _as a wildcard_.  The "" prevents expansion by
Emacs, because the * is not surrounded by whitespace.

My '' suggestion wanted to implement a similar trick for the opposite
problem, where one wants ? to be expanded without having to surround
it by whitespace.

But I am not so sure about my suggestion any more.  Some users might
currently be using ?'' or *'' instead of the suggested ?"" or *"" to
prevent expansion by Emacs and insert an isolated ? or * as a
wildcard.  That would no longer work after the patch I sent, and might
confuse users who do not carefully read the NEWS.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    My '' suggestion wanted to implement a similar trick for the opposite
    problem, where one wants ? to be expanded without having to surround
    it by whitespace.

I see.

    But I am not so sure about my suggestion any more.  Some users might
    currently be using ?'' or *'' instead of the suggested ?"" or *"" to
    prevent expansion by Emacs and insert an isolated ? or * as a
    wildcard.

We need not hesitate to make incompatible changes in little
interactive commands like this.  The question is what interface is
best to use.

Re: info inconsistency about "Shell Commands in Dired"

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     My '' suggestion wanted to implement a similar trick for the opposite
>     problem, where one wants ? to be expanded without having to surround
>     it by whitespace.
> 
> I see.
> 
>     But I am not so sure about my suggestion any more.  Some users might
>     currently be using ?'' or *'' instead of the suggested ?"" or *"" to
>     prevent expansion by Emacs and insert an isolated ? or * as a
>     wildcard.
> 
> We need not hesitate to make incompatible changes in little
> interactive commands like this.  The question is what interface is
> best to use.

Bind * to insert a text-propertied (and thus recognizable and
copy&pastable) x character with the display property of "<filename>".
If people really need * itself, they can insert it using C-q *.

Other keybindings might be imaginable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

David Kastrup wrote:

   Bind * to insert a text-propertied (and thus recognizable and
   copy&pastable) x character with the display property of "<filename>".
   If people really need * itself, they can insert it using C-q *.

That would make inserting wildcards, a very common operation, too cumbersome.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    Bind * to insert a text-propertied (and thus recognizable and
    copy&pastable) x character with the display property of "<filename>".
    If people really need * itself, they can insert it using C-q *.

That is an interesting idea--simple to remember.  Would someone like
to implement it so people can try it out?

    That would make inserting wildcards, a very common operation, too cumbersome.

This particular command is not a very common operation.  And most uses
of the command don't involve wildcards.  So use of wildcards in this
command is quite infrequent as a part of Emacs use.

(I go for months without doing it.)

Re: info inconsistency about "Shell Commands in Dired"

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     Bind * to insert a text-propertied (and thus recognizable and
>     copy&pastable) x character with the display property of "<filename>".
>     If people really need * itself, they can insert it using C-q *.
>
> That is an interesting idea--simple to remember.  Would someone like
> to implement it so people can try it out?

When Miles suggested to use text properties for the separator between
from-string and to-string for query-replace, I tried to implement it,
and discovered some problems with using text properties in the minibuffer:

1. Text properties are discarded from the minibuffer history items.
   The variable `minibuffer-allow-text-properties' could be used to
   prevent their discarding, but it affects only `read-string',
   but not `read-minibuffer'.

2. Text properties in history variables are not saved in the
   .emacs.desktop file.

3. When text is copied from some external source to the minibuffer,
   often it has no suitable text properties.

All this means that the user has to take care about checking if * is
properly fontified (which means it corresponds to the user's intentions)
and to remember to retype * when the user notices that * is not fontified.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    1. Text properties are discarded from the minibuffer history items.
       The variable `minibuffer-allow-text-properties' could be used to
       prevent their discarding, but it affects only `read-string',
       but not `read-minibuffer'.

    2. Text properties in history variables are not saved in the
       .emacs.desktop file.

I guess we would need to fix these two.  Do you want to look at how
hard that would be?

    3. When text is copied from some external source to the minibuffer,
       often it has no suitable text properties.

That is not a bug, just "the way things are."  If you copy an * from
elsewhere, it's an ordinary *.

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

   It is worth thinking about.
   I saw people discussing other methods, %s and envvars.
   The envvar method is too inconvenient.  %s might be acceptable;
   people mainly discussed how to implement it.

Actually, I now see one problem with the change I proposed.

Somebody might have gotten the habit of using *'' or ?'' instead of the
recommended *"" to _prevent_ expansion.  That will no longer work and
this might confuse people, unless they read the NEWS carefully.

If we go for a radically different syntax, then we could just take the
example out of the manual for the time being and implement the new
syntax for 21.5. 

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

>    It is worth thinking about.
>    I saw people discussing other methods, %s and envvars.
>    The envvar method is too inconvenient.  %s might be acceptable;
>    people mainly discussed how to implement it.
> 
> Actually, I now see one problem with the change I proposed.
> 
> Somebody might have gotten the habit of using *'' or ?'' instead of the
> recommended *"" to _prevent_ expansion.  That will no longer work and
> this might confuse people, unless they read the NEWS carefully.
> 
> If we go for a radically different syntax, then we could just take the
> example out of the manual for the time being and implement the new
> syntax for 21.5. 
> 


IMHO, we should remove the feature all-together -- or just keep it
as is and give a better example in the manual, e.g

        mv ? newname.c

as well as warnings for things that does not work, e.g.

        mv ? ?-old


Instead, we should have a command that inserts the current buffer's
file name at point (e.g. in the minibuffer).

Suppose we bind it to M-? -- then you could write

        m v SPC M-? SPC M-? - o l d RET

and even be given a chance to edit the current buffer file name.

Here's an sample implementation.  It obviously need to be enhanced to
know when it is called in a dired originated command, but I'll leave
that to the dired experts...

(defun insert-buffer-file-name (&optional arg)
  "Insert current buffer's file name.
With \\[universal-argument], insert absolute file name."
  (interactive "P")
  (let ((fn (or (buffer-file-name
                   (window-buffer
                     (or (minibuffer-selected-window)
                         (selected-window))))
                "")))
   (unless arg
     (setq fn (file-name-nondirectory fn)))
   (insert fn)))

(global-set-key [?\M-?] 'insert-buffer-file-name)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: info inconsistency about "Shell Commands in Dired"

[Luc Teirlinck]

Kin Storm wrote:

   IMHO, we should remove the feature all-together -- or just keep it
   as is and give a better example in the manual, e.g

	   mv ? newname.c

   as well as warnings for things that does not work, e.g.

	   mv ? ?-old


   Instead, we should have a command that inserts the current buffer's
   file name at point (e.g. in the minibuffer).

That has little to do with `?'.  `?' substitutes each marked file (in
a Dired buffer) in turn.

Sincerely,

Luc.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    IMHO, we should remove the feature all-together -- or just keep it
    as is and give a better example in the manual, e.g

	    mv ? newname.c

    as well as warnings for things that does not work, e.g.

	    mv ? ?-old

Sorry, I do not understand this text.  Precisely what is the feature
you propose to remove?  How would ? behave in dired-do-shell-command
after your proposed change?

Re: info inconsistency about "Shell Commands in Dired"

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     IMHO, we should remove the feature all-together -- or just keep it
>     as is and give a better example in the manual, e.g
> 
> 	    mv ? newname.c
> 
>     as well as warnings for things that does not work, e.g.
> 
> 	    mv ? ?-old
> 
> Sorry, I do not understand this text.  Precisely what is the feature
> you propose to remove?  How would ? behave in dired-do-shell-command
> after your proposed change?

Sorry!  My proposal (as presented) didn't make sense in the
dired-do-shell-command context.

Here is a revised proposal:


I propose that to insert the current buffer or file name (see later)
in a prompt, you must enter M-?.

For a normal minibuffer prompt, e.g. M-x shell, this simply inserts
the buffer file name as proposed in my last fix.

For a command to be used with dired-do-shell-command, M-? inserts
a special marker -- e.g. a `?' character with a dedicated text
property, e.g. '(expand t).  Then dired-do-shell-command shall look
for characters with that property and do the replacement on those.

We should probably keep the meaning of ? surrounded by spaces for
backwards compatibility (and ease of use).  And then fix the
documentation to say what works and what doesn't work.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    For a command to be used with dired-do-shell-command, M-? inserts
    a special marker -- e.g. a `?' character with a dedicated text
    property, e.g. '(expand t).  Then dired-do-shell-command shall look
    for characters with that property and do the replacement on those.

This would be ok as long as we don't assign any other meaning to M-?
that is useful inside all minibuffers.

Re: info inconsistency about "Shell Commands in Dired"

[Richard Stallman]

    If everybody is finished laughing...  Maybe one should allow it
    surrounded by quotes, something like

      '?'.uu

That seems like a good idea, if it can be implemented in
a way that really works reliably.  It might require parsing
shell syntax to an extent that is not worth the trouble
it takes.  Or perhaps some of the existing code for parsing
shell arguments could do the job.