[Info-vax] Long uptime cut short by Hurricane Sandy

[Johnny Billquist]

On 2013-02-01 01:17, Simon Clubley wrote:
> On 2013-01-31, Johnny Billquist <bqt at softjar.se> wrote:
>> On 2013-01-31 19:05, Simon Clubley wrote:
>>
>> While I agree with many things you write here, one is very different in
>> my mind.
>> Renames...
>>
>>> rename is far more powerful; you can specify a part of a filename to be
>>> replaced with another string and apply this to a set of files.
>>
>> Really? How? mv in unix has more than its fair share of brain damage. It
>> can essentially work in two modes:
>> 1 - Given two arguments and the second not being a directory, it renames
>> the first argument to the second, unless the second already exists. It
>> does not do any kind of pattern matching, replacing, or anything at all.
>> 2 - Given atleast two arguments, where the last argument is a directory,
>> it will move all the n-1 arguments into the last argument, being a
>> directory. No renaming of the files as such at all happens.
>>
>> One very obvious thing it cannot do, which is not unheard of in DCL is
>> just simply renaming a bunch of files, such as (in DCL):
>>
>> RENAME *.FOO *.BAR
>>
>> mv just cannot do this. And shell globbing will not help you either.
>> You'll have to write a loop with a rather elaborate scheme to implement
>> this rather simple thing.
>>
>> So, what are you thinking about in your comment? What have I totally missed?
>>
>
> The fact I am not talking about mv at all but the rename command. :-)
>
> Read the man page for rename and then think about what you can do with it
> that you could not possibly do on VMS.

Gotcha. Hadn't seen the rename command in some Linux (or other) systems. 
But it's definitely not something that exists everywhere in Unix. And I 
had to read the thing three times before I understood what it actually does.

>> (And by the way, wildcard handling in Unix has its ups and downs. I'm
>> not overly impressed by it, but it's a workaround that sometimes is
>> useful, except of course every program have to implement this itself if
>> it wants to be able to deal with wildcards. No common library for that
>> stuff.)
>>
>
> In many cases, letting the shell do the expansion instead of the program
> achieves the same thing and stops you from having to add wildcard
> expansion code into every program.

Yes. Which is the rationale given in Unix. So you have plenty of 
programs in Unix which all individually have to add wildcard expansion.

How about if that had been a standard function in the system instead, 
and all programs used that? No individual implementations, and having 
such functionality work everywhere?

But yes, the Unix way allows lots of programs to be rather small, at the 
expense of having to allow very long command lines.

> You can always escape the wildcard if you want the program to handle the
> expansion itself.

Yes. And for programs who actually are interactive and read input from 
the users, and programs who might not want some patterns to actually be 
globbed at all... (Think find, for example...)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol