February 26, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.829.1329869699.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote: [...]
>> I think that globbing should be done explicity by the app, *but* for apps that don't play ball you should be able to *explicitly* do it at the command line. Example:
>>
>> $someutil *.txt foo.html
>> ERROR: Can't find file '*.txt'
>> $glob *.txt
>> 'hello.txt' 'Modern File Name.txt' 'another.txt'
>> $someutil `glob *.txt` foo.html
>> Processing hello.txt...done
>> Processing Modern File Name.txt...done
>> Processing another.txt...done
>> Processing foo.html...done
>
> Hmm. I like that idea: have the shell *not* interpolate things by default, unless you explicitly say to do so. So by default typing:
>
> rm *.txt
>
> will pass "*.txt" to rm as a single argument, whereas:
>
> # Not real syntax:
> rm `*.txt`
>
> will expand "*.txt" as a glob and pass the result to rm.
>

I've just thought of (ie, gotten bit by) another thing that would be nice about having the commands do their own globbing:

If the applications glob on their own insted of the shell, then for safety they can choose to restrict the number of file args they take to whatever makes sense for their own individual purpose.

For example, suppose you want to delete everything inside a given subdirectory (but keep the directory itself). So then you (mis)type:

$rm somedir/ * -rf

Note the subtle space before the "*". I just did that by mistake earlier today, and the damage set me back a few hours (could have been much, much worse, though). I don't think there's much, if anything, that can realistically be done to protect against that right now. At least without getting really hacky.

But, if rm was expected to do its own globbing instead of the shell doing it, then rm could say: "Ok, it only makes sense for you to give me one file/path at a time. Want more? Run me multiple times or use a glob pattern (or hell, a regex pattern, or use a special explicit 'accept multiple paths' mode, etc)." Then:

$rm somedir/ * -rf
ERROR: rm only takes one path at a time
$rm somedir/* -rf  # ok
$rm somedir/ -rf  # ok
$rm * -rf  # ok

With the shell doing the expansion, that sort of thing isn't even possible.

Works with other stuff too:

$cp a b c
ERROR: You gave me a source path and a destination path, but then you gave
me *another* path! What the hell you expect *me* to do with it?


February 27, 2012
On Sun, Feb 26, 2012 at 05:10:35PM -0500, Nick Sabalausky wrote: [...]
> I've just thought of (ie, gotten bit by) another thing that would be nice about having the commands do their own globbing:
> 
> If the applications glob on their own insted of the shell, then for safety they can choose to restrict the number of file args they take to whatever makes sense for their own individual purpose.
> 
> For example, suppose you want to delete everything inside a given
> subdirectory (but keep the directory itself). So then you (mis)type:
> 
> $rm somedir/ * -rf
> 
> Note the subtle space before the "*". I just did that by mistake earlier today, and the damage set me back a few hours (could have been much, much worse, though). I don't think there's much, if anything, that can realistically be done to protect against that right now. At least without getting really hacky.

If rm did its own globbing, it could warn the user before proceeding with a mass deletion involving *. (IIRC DOS's 'del' used to do this.) With the shell doing the expansion, there's no easy way to do this.


> But, if rm was expected to do its own globbing instead of the shell doing it, then rm could say: "Ok, it only makes sense for you to give me one file/path at a time. Want more? Run me multiple times or use a glob pattern (or hell, a regex pattern, or use a special explicit 'accept multiple paths' mode, etc)." Then:
> 
> $rm somedir/ * -rf
> ERROR: rm only takes one path at a time
> $rm somedir/* -rf  # ok
> $rm somedir/ -rf  # ok
> $rm * -rf  # ok
> 
> With the shell doing the expansion, that sort of thing isn't even possible.

I guess you could have a flag for when you explicitly want to specify multiple filenames:

	$ rm abc.d def.d
	ERROR: rm only takes one path at a time
	$ rm -m abc.d def.d	# ok
	$


> Works with other stuff too:
> 
> $cp a b c
> ERROR: You gave me a source path and a destination path, but then you
> gave me *another* path! What the hell you expect *me* to do with it?
[...]

But sometimes you want to copy multiple files to a destination dir. But I suppose you can always use a glob or specify an option to say "yes I really want to copy multiple files into a target dir".


T

-- 
It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
1 2 3 4 5 6 7 8 9 10 11
Next ›   Last »