Questions about windows support
a at a.a
Tue Feb 21 15:49:45 PST 2012
"Bernard Helyer" <b.helyer at gmail.com> wrote in message
news:iianhomhapvkfhidezbr at forum.dlang.org...
> >Nick replied to something about globbing
> Having programs doing the globbing sounds great until you run into someone
> who doesn't play ball. *cough* every single digital mars utility *cough*.
> I think Windows and unix both get it wrong, but unix gets it less wrong
> (as it could theoretically be annoying, but in practice I just escape it
> and move on, but working around a non-globbing program is just annoying).
> Wot I think should happen: the runtime (say libc) should handle globbing
> of arguments, and it should be enabled by default. So if someone wants an
> app that handles wildcards specially, they can do that, but for most apps
> it'll just workT. I don't think this really meshes with the traditional
> main signature of just passing the strings as arguments. Perhaps just a
> non_globbed_args function or something.
> Buuuut things are pretty much set in stone at this point.
I dunno about that. The problem is that in the default "just work" case, the
app still has no idea that the shell is sending it things that are
*supposed* to be interpreted as filenames, so you still end up with that
"touch -- --ha-ha-fuck-you" fiasco.
Also, libc/whatever has no way to know when a glob does or doesn't even make
sence in the first place. What if you want to do something like:
"fooapp --special-files=blah*.baz" The app knows how to handle that right,
but if fooapp's authot forgot to disable the autoglob, the runtime will just
fuck it up and remove the arg entirely (unless some jackwagon previously did
"touch -- --special-files=blahblah.baz").
Or if the app allowed "fooapp --regex r/blah*blah/" which wasn't even
*intended* to be a glob. In that case, too, the app itself would have *make
sure* to remember to disable the default setting so it works right. It'd
just be another thing for developers to watch out for and possibly screw up.
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
$someutil *.txt foo.html
ERROR: Can't find file '*.txt'
'hello.txt' 'Modern File Name.txt' 'another.txt'
$someutil `glob *.txt` foo.html
Processing Modern File Name.txt...done
Erm...actually, that glob tool above would probably have to work more like
'hello.txt' 'Modern File Name.txt' 'another.txt'$someutil `glob *.txt`
Which brings up another little nitpick: When bash displays a prompt, it
should first check to see if the last char output was a newline. If not, it
More information about the Digitalmars-d