From: Greg W. <gw...@py...> - 2002-04-11 17:56:27
|
On 11 April 2002, Scott Alexander Kirkwood said: > I did a similar class in C++ back in the early 90's. It also printed out the > help and could even create the man file for you. I also (optionally) > supported having color coding for the options. Aiee! Sounds neat, but the term "creeping featurism" comes to mind. > Anyway, one feature which I added to my class which seems to be missing from > yours is globbing on Windows. The idea is to tell Optik that this parameter > is a file or file(s). On Unix style systems there's nothing for Optik to do > extra. On Windows, Optik will receive '*.py" and will have to expand (glob) > the files. The beauty is that both Windows and Unix developers won't have to > worry about which platform they're on, it'll both appear to be Unix style. I can think of so many reasons why that won't work. I think it boils down to a basic difference in conventional syntax for Unix vs. MS-DOS programs: if Unix programs take multiple filenames, they take them as positional arguments, ie. what's left over after all the options have been parsed. It's done this way because Unix shells expand wildcards for you. Under MS-DOS, a wildcard is just a single argument that the program has to expand, so making a wildcard an option value is not a problem. IOW, it would be most unusual to write a Unix program that works like this: $ foo -f *.py (implying that the argument(s) to the "-f" option is a list of filenames). Anyways, is it really so hard to call glob() on a string to expand it? Greg -- Greg Ward - just another /P(erl|ython)/ hacker gw...@py... http://starship.python.net/~gward/ Health is merely the slowest possible rate at which one can die. |