Subject: | |
From: | |
Reply To: | |
Date: | Thu, 16 Jun 2005 14:53:34 +0100 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
>It is UNIX that is the odd man out. Provide a call for wildcard expansion,
>of which every utility can take advantage, while also being able to confirm
>that the user does in fact intend to perform certain operations, or
>alternate implementations. Seems obvious enough.
Sure - I'm sure that works very well. I've just never heard of anyone
complainnig that UNIX does too much for you automatically. Usually it's
that UNIX doesn't do anything and the answer is always "do it yourself".
>It's not just del / erase / purge / rm. How about move / mv? If a user
>provides the argument to move all files from a given directory to a
>non-existent directory, and all files is a non-trivial number, perhaps
>renaming the existing dir, and cloning its attributes to a new dir would be
>somewhat more efficient than brokering a non-trivial number of moves.
Well that's up to the user. "mv directory1 directory2" works already and
would be more efficient than
mkdir directory2
mv directory1/* directory2
rmdir directory1
but then that's pretty obvious and doesn't require wildcard expansion at
all.
Wildcard expansion in the command line interpreter -
Advantages:
Gaurenteed consistent wild card expansion across utilities.
No need for developers to remember to write additional code in every utility
(even an API call requires some coding). (more code = more bugs)
Disadvantages:
Can't do a "are you sure" type prompt when all files are being removed in a
directory.
Possibly some situation where knowing you've got the whole directory could
make things quicker.
Actually - you could write a library routine to determine if all the files
you have been passed represent the entire contents of one directory. Then
you'd be calling the additional code to get additional unusual behaviour
rather than calling a routine every time to get wild card expansion.
Cheers
Peter
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|