! in Dired--what was the outcome?

! in Dired--what was the outcome?

[Richard Stallman]

What did we finally end up doing about the ! command in Dired
and its handling of ? and *?

! in Dired--what was the outcome?

[Jose E. Marchesi]

    What did we finally end up doing about the ! command in Dired
    and its handling of ? and *?
    

I would suggest to back to the old handling: subst all appearances of
'?'  and '*' unless escaped with a backslash character '\'.

The new handling (a space or end of line must follow both characters
in order to be handled as special) make very difficult to construct
another file name from the selected one.

Consider the following command:

     !cmd ? ?.added_extension

It is not trivial to concatenate strings with sh. It is much more
comfortable to escape the characters in the case we want to send them
literally to the shell.

Another choice would be to change the substituted characters. Both '?'
and '*' are heavily used on the shell command. But such a radical
change could confuse many users.

Just my two euro-cents.


-- 
José E. Marchesi 

<jemarch@gnu.org>         http://www.gnu.org     GNU No es Unix!
<jemarch@es.gnu.org>      http://es.gnu.org      GNU España

.---------------.
|    .-[]--.    |
|   [] `>[]-|   |  BEE GNU/Hurd            http://bee.es.gnu.org
|    `-.[]<-'   |               
._______________.    

Re: ! in Dired--what was the outcome?

[Luc Teirlinck]

   What did we finally end up doing about the ! command in Dired
   and its handling of ? and *?

If I remember well we decided to solve this as follows, proposed by
David Kastrup:

   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 *.

But then Juri pointed out that several other problems needed to be
solved before this could be implemented.  I believe you then decided
that these other problems should be solved.  I do not know whether any
of this actually ever got implemented.

There are alternative solutions that only require trivial changes to
something like two lines of code.

Sincerely,

Luc.

Re: ! in Dired--what was the outcome?

[Luc Teirlinck]

>From my previous message:

   If I remember well we decided to solve this as follows, proposed by
   David Kastrup:

      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 *.

Actually, the problem concerned mainly `?'.  So if we decide to stick
with this solution (assuming somebody would be willing to implement it
and solve all other problems that need to be solved first to make it
work), it would actually be `?' that should be bound as described
above.  `*' could either be left alone or bound similarly with a
display property of "<list of files>" or whatever.

Sincerely,

Luc.

Re: ! in Dired--what was the outcome?

[Richard Stallman]

    Actually, the problem concerned mainly `?'.  So if we decide to stick
    with this solution (assuming somebody would be willing to implement it
    and solve all other problems that need to be solved first to make it
    work), it would actually be `?' that should be bound as described
    above.  `*' could either be left alone or bound similarly with a
    display property of "<list of files>" or whatever.

Would you like to try implementing this?

    But then Juri pointed out that several other problems needed to be
    solved before this could be implemented.  I believe you then decided
    that these other problems should be solved.

Can you find what those other problems were?
Do they apply to the precise proposal which is to do this with ?,
rather than with *?

Re: ! in Dired--what was the outcome?

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     But then Juri pointed out that several other problems needed to be
>     solved before this could be implemented.  I believe you then decided
>     that these other problems should be solved.
>
> Can you find what those other problems were?
> Do they apply to the precise proposal which is to do this with ?,
> rather than with *?

The main problem I see is that special text properties may not be
visible to the user (remember the recent problem with help-argument-name
where italics is not displayed in some fonts).  It makes this feature
quite dangerous if the command doesn't do what the user sees on the
command line in the minibuffer.

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

Re: ! in Dired--what was the outcome?

[Richard Stallman]

Here is another idea.  We could use one ? with one meaning
and ?? for the other meaning.

What do people think about that?

Re: ! in Dired--what was the outcome?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Here is another idea.  We could use one ? with one meaning
> and ?? for the other meaning.
>
> What do people think about that?

?? has a valid meaning of its own in shell patterns.  ** in contrast
would be free for grabs, more or less.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ! in Dired--what was the outcome?

[Stefan Monnier]

> ?? has a valid meaning of its own in shell patterns.  ** in contrast
> would be free for grabs, more or less.

** is used in zsh (and eshell) to mean a recursive search.
But it never appears alone, it's always in the shape of **/


        Stefan

Re: ! in Dired--what was the outcome?

[Luc Teirlinck]

What is wrong with the solution I proposed earlier?

Currently ? and * expand if and only if they are surrounded on both
sides by whitespace.

There are two problems.

One might want to use an isolated * (or less likely ?) as a wildcard.
The Emacs manual recommends using *"" (or ?"") in those cases.  The *
(or ?) is no longer surrounded by whitespace, so Emacs does not
expand.  To the shell, "" does not make any difference.

Our discussion was concerned with the opposite problem.  One wants to
expand ? in cases where it is not surrounded by whitespace, to add
prefixes or extensions to a bunch of file names.  I proposed to solve
this problem in a similar way to the opposite problem.  Namely make *
and ?  expand if and only if they are surrounded on both sides by
whitespace _or_ ''.  That is, we would treat a pair of single-quotes
as equivalent to whitespace for expansion purposes.  As for "", ''
does not make any difference for the shell.

So one could do

mv ? .''?

or:

mv ? ?''.uu

to prepend . or append .uu to a bunch of marked files.

The corresponding trick for * will very seldom be useful, but it
probably is better to make it work for * too, just for consistency.

Here is the patch to dired-aux (which I proposed earlier) that
implements the above:

===File ~/dired-aux-diff====================================
*** 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: ! in Dired--what was the outcome?

[Luc Teirlinck]

Richard Stallman <rms@gnu.org> wrote:

       Actually, the problem concerned mainly `?'.  So if we decide to stick
       with this solution (assuming somebody would be willing to implement it
       and solve all other problems that need to be solved first to make it
       work), it would actually be `?' that should be bound as described
       above.  `*' could either be left alone or bound similarly with a
       display property of "<list of files>" or whatever.

   Would you like to try implementing this?
				   
I am already doing too many things at the same time.  Apart from the
problems Juri pointed out, there also is the problem that it makes
using wildcards with M-! more cumbersome.  Note that the problem we
are trying to fix with the above is not encountered very often and
there are trivial _other_ ways to fix it, with a very minor change to
a regexp.  It is not even clear that these trivial ways are really
inferior.

Note however that if somebody else is willing to implement the above
more involved solution, while taking care of Juri's objections, then I
by no means object to that.

Sincerely,

Luc.

Re: ! in Dired--what was the outcome?

[Richard Stallman]

      Note that the problem we
    are trying to fix with the above is not encountered very often and
    there are trivial _other_ ways to fix it, with a very minor change to
    a regexp.  It is not even clear that these trivial ways are really
    inferior.

They may be trivial to implement, but if you're talking about the
ones that we discussed, they get rid of a useful feature.

Re: ! in Dired--what was the outcome?

[Luc Teirlinck]

Richard Stallman wrote:

   They may be trivial to implement, but if you're talking about the
   ones that we discussed, they get rid of a useful feature.

Which feature?  After my proposed change, .?.uu and .*.uu would still
do exactly the same thing they do now.  My proposed change just
exploits the fact that .''?''.uu and .''*''.uu are currently useless
synonyms for the two simpler expressions.  After my patch you can
cause expansion by surrounding ? or * on both sides by whitespace _or_
two single-quotes.

So:

mv ? .''?''.uu

prepends . and appends .uu to the names of all marked files.

This _adds_ a feature and gets rid of none.  It does this without
making using wildcards less convenient, unlike the more difficult to
implement feature.

Sincerely,

Luc.

Re: ! in Dired--what was the outcome?

[Richard Stallman]

    So:

    mv ? .''?''.uu

    prepends . and appends .uu to the names of all marked files.

Ok, I agree this does not take away any useful feature.  It would be
an acceptable solution, but it is rather inconvenient to use.
So I would rather use a solution along the lines where ? displays
one way and C-q ? displays another way.

Re: ! in Dired--what was the outcome?

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> What did we finally end up doing about the ! command in Dired
> and its handling of ? and *?

I see no other good solution than developing a special syntax to
express different needs for marked files used in shell commands.
Such a syntax would allow to specify file names, file directories,
file extensions etc. of all files or each file, and to evaluate
arbitrary s-expressions on file names.

Here is a short example what this would look like:

      \*f - all marked file names
      \?f - each marked file name
      \*d - all marked file names with directory
      \?d - each marked file name with directory
      \*x - all marked file names without extensions
      \?x - each marked file name without extension
      \*(s-expr) - s-expression evaluated on all files
      \?(s-expr) - s-expression evaluated on each file,
                   where rules for finding the end of s-expression are
                   the same as those used for \,(...) in query-replace

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

Re: ! in Dired--what was the outcome?

[Luc Teirlinck]

Juri Linkov wrote:

   Here is a short example what this would look like:

	 \*f - all marked file names
	 \?f - each marked file name
	 \*d - all marked file names with directory
	 \?d - each marked file name with directory
	 \*x - all marked file names without extensions
	 \?x - each marked file name without extension
	 \*(s-expr) - s-expression evaluated on all files
	 \?(s-expr) - s-expression evaluated on each file,
		      where rules for finding the end of s-expression are
		      the same as those used for \,(...) in query-replace

I guess you also would need a rule that if Emacs sees \\* or \\? it
actually passes \* or \? to the shell to allow _literal_ *'s and ?'s
in file names.  Then all of that would have to be documented in the
Emacs manual.

Maybe I should mention a possible simpler solution, proposed in
private email by Johan Vromans to use {} instead of ?, in analogy with
the -exec argument of find(1).

mv {} .{}.uu

I do not know whether we then also should use () or [] or such
instead of * for consistency.  The idea is to get rid of confusion
with shell wildcards.

I guess it actually even is possible to use "" and '' instead of ? and
*.  Why do we absolutely want to use shell wildcards for this?


Sincerely,

Luc.

Re: ! in Dired--what was the outcome?

[David Kastrup]

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

> Juri Linkov wrote:
>
>    Here is a short example what this would look like:
>
> 	 \*f - all marked file names
> 	 \?f - each marked file name
> 	 \*d - all marked file names with directory
> 	 \?d - each marked file name with directory
> 	 \*x - all marked file names without extensions
> 	 \?x - each marked file name without extension
> 	 \*(s-expr) - s-expression evaluated on all files
> 	 \?(s-expr) - s-expression evaluated on each file,
> 		      where rules for finding the end of s-expression are
> 		      the same as those used for \,(...) in query-replace
>
> I guess you also would need a rule that if Emacs sees \\* or \\? it
> actually passes \* or \? to the shell to allow _literal_ *'s and ?'s
> in file names.  Then all of that would have to be documented in the
> Emacs manual.
>
> Maybe I should mention a possible simpler solution, proposed in
> private email by Johan Vromans to use {} instead of ?, in analogy with
> the -exec argument of find(1).
>
> mv {} .{}.uu

I think that is a good proposal.  The normal use does not really seem
to warrant all that complexity.  The disadvantage is that {} is not
necessarily easy to type on non-American keyboards, but I think that
people typing shell commands and using Emacs for editing (many
languages use braces, even TeX) are likely used to having to type
those characters.

> I do not know whether we then also should use () or [] or such
> instead of * for consistency.  The idea is to get rid of confusion
> with shell wildcards.

() and [] don't look so hot.  Perhaps {*} ?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ! in Dired--what was the outcome?

[Richard Stallman]

    Maybe I should mention a possible simpler solution, proposed in
    private email by Johan Vromans to use {} instead of ?, in analogy with
    the -exec argument of find(1).

    mv {} .{}.uu

That could be a good idea.  It would only cause a problem if you
are trying to run `find'.  I guess you could use "{}" to pass
that argument to `find'; by the time `find' sees it, the quotes
will have been removed.

Does anyone see a problem with this?

    I do not know whether we then also should use () or [] or such
    instead of * for consistency.

That would be rather complex, and there is no problem with *.
Using * is natural because it means "all the files".

Re: ! in Dired--what was the outcome?

[Johan Vromans]

Richard Stallman <rms@gnu.org> writes:

>     Maybe I should mention a possible simpler solution, proposed in
>     private email by Johan Vromans to use {} instead of ?, in analogy with
>     the -exec argument of find(1).
>
>     mv {} .{}.uu
>
> That could be a good idea.

Likewise, {} could be made available to 'shell-command' as well, to
make it easy to run arbitrary commands on the file associated with the
current buffer. For example C-x C-s M-! cp {} {}.save RET before
starting to make possibly hazardous changes...

-- Johan

Re: ! in Dired--what was the outcome?

[Andreas Schwab]

Johan Vromans <jvromans@squirrel.nl> writes:

> For example C-x C-s M-! cp {} {}.save RET before starting to make
> possibly hazardous changes...

M-x copy-file

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ! in Dired--what was the outcome?

[Miles Bader]

Andreas Schwab <schwab@suse.de> writes:
>> For example C-x C-s M-! cp {} {}.save RET before starting to make
>> possibly hazardous changes...
>
> M-x copy-file

I usually just use `find-alternate-file' (after saving):  C-x C-v RET

Which forces the backup system to start a new backup at that point.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: ! in Dired--what was the outcome?

[Andreas Schwab]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Andreas Schwab <schwab@suse.de> writes:
>>> For example C-x C-s M-! cp {} {}.save RET before starting to make
>>> possibly hazardous changes...
>>
>> M-x copy-file
>
> I usually just use `find-alternate-file' (after saving):  C-x C-v RET
>
> Which forces the backup system to start a new backup at that point.

And thows away undo information.  Just use C-u C-x C-s to force a backup.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ! in Dired--what was the outcome?

[Richard Stallman]

Nobody has criticized the {} solution.
Would someone like to implement it?

Re: ! in Dired--what was the outcome?

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> Nobody has criticized the {} solution.

{} might be a good replacement for ? since AFAIU its planned use
doesn't depend on surrounding whitespace, but the problem is still
unsolved for *.  Currently the marked file names are substituted for
the * only if * is surrounded by whitespace.  But what if someone
wants to use the names of all marked files with * not surrounded
by whitespace, e.g.

! some_external_program --files='*'

or something like this?  Should we add already proposed {*}
replaced with file names unconditionally, not depending
on surrounding whitespace?

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

Re: ! in Dired--what was the outcome?

[Richard Stallman]

    {} might be a good replacement for ? since AFAIU its planned use
    doesn't depend on surrounding whitespace, but the problem is still
    unsolved for *.

We don't have a problem to solve for *.  We don't need
to do anything besides switch from ? to {}.

      Currently the marked file names are substituted for
    the * only if * is surrounded by whitespace.  But what if someone
    wants to use the names of all marked files with * not surrounded
    by whitespace, e.g.

    ! some_external_program --files='*'

If you find such a situation, just put in whitespace:

    ! some_external_program --files=' * '

I don't see how there could ever be a reason you
would need to do this with no whitespace.

Re: ! in Dired--what was the outcome?

[Reinhard Kotucha]

>>>>> "Johan" == Johan Vromans <jvromans@squirrel.nl> writes:

    > Likewise, {} could be made available to 'shell-command' as well,
    > to make it easy to run arbitrary commands on the file associated
    > with the current buffer. For example C-x C-s M-! cp {} {}.save
    > RET before starting to make possibly hazardous changes...

The example is quite special.  It allows to append an extension, but
it disallows to remove one.

What I do very often in bash is

     for file in *.ps ; do
     	 convert $file ${file%%ps}pdf
     done

Maybe your syntax can be extended, for instance like this:

      convert {} {/ps$//}pdf
or 
      convert {} {/ps$/pdf/}

Using regexps is much more powerful than the substring approach in
bash anyway.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha@web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

Re: ! in Dired--what was the outcome?

[Miles Bader]

On Fri, Oct 15, 2004 at 01:30:25AM +0200, Reinhard Kotucha wrote:
> Maybe your syntax can be extended, for instance like this:
> 
>       convert {} {/ps$//}pdf
>       convert {} {/ps$/pdf/}

That's kind of dangerous because while I think "{}" is not usually used very
often in shell commands (except for find), once you start putting stuff in
between them, it's less obvious.

-Miles
-- 
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house.  And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
  [George Carlin]

Re: ! in Dired--what was the outcome?

[David Kastrup]

Reinhard Kotucha <reinhard.kotucha@web.de> writes:

>>>>>> "Johan" == Johan Vromans <jvromans@squirrel.nl> writes:
>
>     > Likewise, {} could be made available to 'shell-command' as well,
>     > to make it easy to run arbitrary commands on the file associated
>     > with the current buffer. For example C-x C-s M-! cp {} {}.save
>     > RET before starting to make possibly hazardous changes...
>
> The example is quite special.  It allows to append an extension, but
> it disallows to remove one.
>
> What I do very often in bash is
>
>      for file in *.ps ; do
>      	 convert $file ${file%%ps}pdf
>      done
>
> Maybe your syntax can be extended, for instance like this:
>
>       convert {} {/ps$//}pdf
> or 
>       convert {} {/ps$/pdf/}
>
> Using regexps is much more powerful than the substring approach in
> bash anyway.

No.  If you need a shell, use a shell.  Like

i={};convert $i ${i%%ps}pdf

There is no sense in converting Emacs into a shell in a dozen of
different ways.  If we wanted to add in-built intelligence, the way to
do that would be to use eshell for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ! in Dired--what was the outcome?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Maybe I should mention a possible simpler solution, proposed in
>     private email by Johan Vromans to use {} instead of ?, in analogy with
>     the -exec argument of find(1).
>
>     mv {} .{}.uu
>
> That could be a good idea.  It would only cause a problem if you
> are trying to run `find'.  I guess you could use "{}" to pass
> that argument to `find'; by the time `find' sees it, the quotes
> will have been removed.
>
> Does anyone see a problem with this?

I think {} should be replaced by the file name, period.  That's simple
to understand.  If you really need {}, you can quote one of the two
characters, like '{'} or {\}.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ! in Dired--what was the outcome?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     Maybe I should mention a possible simpler solution, proposed in
>>     private email by Johan Vromans to use {} instead of ?, in analogy with
>>     the -exec argument of find(1).
>>
>>     mv {} .{}.uu
>>
>> That could be a good idea.  It would only cause a problem if you
>> are trying to run `find'.  I guess you could use "{}" to pass
>> that argument to `find'; by the time `find' sees it, the quotes
>> will have been removed.
>>
>> Does anyone see a problem with this?
>
> I think {} should be replaced by the file name, period.  That's simple
> to understand.  If you really need {}, you can quote one of the two
> characters, like '{'} or {\}.
>

I agree.

However, if we really need a special syntax to insert {} literally,
we could use {{}}.

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

Re: ! in Dired--what was the outcome?

[Reinhard Kotucha]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

    > If you really need {}, you can quote one
    > of the two characters, like '{'} or {\}.

I'd prefer to force people to quote both braces, for example '{}' or
\{\}.  Otherwise syntax checkers have to know that there is something
special.  But I agree with you that braces should be quoted if
necessary. 

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-4592165
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha@web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------

Re: ! in Dired--what was the outcome?

[David Kastrup]

Reinhard Kotucha <reinhard.kotucha@web.de> writes:

>>>>>> "David" == David Kastrup <dak@gnu.org> writes:
>
>     > If you really need {}, you can quote one
>     > of the two characters, like '{'} or {\}.
>
> I'd prefer to force people to quote both braces, for example '{}' or

This form is useless, as it does not hide the {} pattern.  We don't
want the command line to start messing with quoting characters if we
can avoid it.  If you want symmetry, use {''} instead.

> \{\}.

That's ok.  But I don't see why one should _force_ anybody to use that.

> Otherwise syntax checkers have to know that there is something
> special.

Syntax checkers?  On ad-hoc entered dired command lines?  Are we
talking about the same thing still?

Ok, brace matching will complain, but that is no catastrophe.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: ! in Dired--what was the outcome?

[Richard Stallman]

    Here is a short example what this would look like:

	  \*f - all marked file names
	  \?f - each marked file name
	  \*d - all marked file names with directory
	  \?d - each marked file name with directory

That is very complex.  I am looking for something simpler.