On Wed, Dec 9, 2009 at 3:40 PM, Michael Richter <[email protected]>wrote:
> 2009/12/9 Wilson, Ronald <[email protected]> > >> > 2) This is a bit wooly, but sometimes I'd like to be able to do >> > something like: >> > fossil rm <file_name>.* >> > ... *when these files don't exists on disk, because I've deleted them >> > already*. So I want some way to do a delete glob on what fossil has in >> > its repo, not what is on disk. >> > How arguments are passed to an application from the shell is an oft-misunderstood topic... The problem here is that if the files are deleted, fossil will get the following arguments from the shell: argv[0] = fossil argv[1] = rm Whether or not filename.* expands to one or more filenames, or the literal string "filename.*" is up to the shell - some shells will expand it to an empty string and some will pass it on as is (bash can be configured for either, though the option name eludes me at the moment). If we deleted filename.c but not filename.h, the wildcard would expand to filename.h, and fossil would have no idea that it should also operate on filename.c. All wildcard handling which is not in quotes will be interpreted by the shell before they are handed off by fossil. Those in quotes will have their quotes stripped and the rest passed to the application (e.g. this is how to pass arguments with spaces in them). So to get the effect you're looking for we'd have to support: fossil rm 'filename.*' Note the quotes. Then fossil would get: argv[0] = fossil argv[1] = rm argv[2] = filename.* (no quotes - the shell has stripped them. Or Unix shells do, anyway.) Now fossil has to figure out if argv[2] is indeed a wildcard or a single name. It could use sqlite3's glob function for that but there would then be differences in behaviour between: fossil rm 'filename.{c,h}' fossil rm filename.{c,h} the latter would work, the former would not (assuming the existing sqlite3 GLOB function is used). There are also other problems there regarding handling of paths within the repo, but i'll leave discovering those as an exercise ;). IMO, duplicating the shell functionality is the wrong approach, mainly because there will be behavioural differences between fossil's and the shell's globbing. i agree it would be convenient for us users, but it technically could not be guaranteed to behave the same as the user's shell, and therefore could cause confusion or even data loss (e.g. accidental removal or even purging by using an incompatible glob pattern). -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
