[ On Wednesday, August 15, 2001 at 18:53:03 (+0200), Lucio De Re wrote: ]
> Subject: Re: upgrade to mv
>
> I was just pointing out a particular feature I would like to
> see.  Just mentioning MS-DOS in this forum should date me as
> someone who knows the difference between Unix and DOS
> wildcards.
> 
> And, quite frankly, I would be perfectly happy fooling the
> shell with, say
> 
> 	REN {}.cob {}.dis
> 
> if REN needed it and knew how to deal with it.

Like I've been saying, this concept of handing wild-card pathname
specifications directly to the utility is older than the hills --
Multics did it long before Unix came along and decade(s) before M$-DOg
(I'm not sure if CP/M did it or not, and if so when).

The problem is, as has already been discussed, but apparently not yet
clearly enough, Unix does not do any wildcard processing in the
individual utilities -- it does it once, before the command is invoked,
in the shell.

While a '-d DESTINATION' option to cp/mv/ln would be nifty, putting any
kind of wild-card handling into them (or any other similar file handling
utility) would be a very wrong thing to do (from the perspective of
building clean and elegant software tools, at least).

> Just odd ideas that just are outlandish enough in the Unix
> paradigm to need some lateral thinking.  Adding options to
> existing commands is seldom the way to go.

Yes indeed!  :-)

MMV is/was simply a hard-coding into C of what is otherwise a very
simple shell/perl/python/ruby/WHATEVER script.  Unfortunately MMV isn't
even unix-like enough for most folks -- it breaks the RE paradigms used
by sed, expr, et al.  At least in Multics the syntax made sense (though
it wasn't as powerful as generalised REs).  (For those of you who have
used Multics, I am of course referring to "equal names" and the use of
'%'.)

The part that makes it complicted is the attempt at generalization.
When that happens you know something might be wrong with the very idea.

I've written that script hundreds, if not thousands, of times, almost
always as a one-line shell command that I type, hit <CR>, and "forget".

I.e. I don't try to build a general solution to this problem -- it's far
easier to always solve it directly with a custom solution, even if you
have to do it thousands of times over a lifetime.  The effort of being
explicit is not wasted -- it's good practice at managing and using
software tools (especially if you really think about the problem each
time and try to invent a more specifict technique for each situation you
encounter as that way you'll learn many different tricks of the trade).

After all, you won't really know how to generalise the solution until
you've encountered it enough times to know all its nooks and crannies!  :-)


That said, it could be possible to add Multics-like "equal names"
support to 'mv', 'cp', 'ln', et al, without putting any wildcard
handling right in the commands, but doing so would perhaps lend too much
credence to "." as a component separator (not to mention adding another
special character to the list of special characters one has to have
quoting support for, which implies needing yet another type of quoting
for the target parameter of these commands too), and wouldn't really
solve the more general problem that can better be solved with 'expr' or
'sed' using full general REs and a wee bit of shell-level control logic.

Shell programs really are far more powerful in general than any specific
features that would have to be added to many individual commands.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>