On 10/05/12 06:22, Eli Zaretskii wrote:
>> Date: Wed, 09 May 2012 22:37:37 +0100
>> From: Keith Marshall
>> I've posted a new mingwrt snapshot at http://tinyurl.com/cgkckca
> Thank you!
>> The new glob(3) function is mostly POSIX compliant, (but currently
>> doesn't implement any use of the (*errfn)() argument). It *does* add
>> globbing of character groups, such as [abc] and [!xyz], which may not be
>> familiar to Windows users; we may want to consider making this a
>> non-default optional feature
> Yes, it should probably be optional.
Easily accommodated, (for the command line parse only; the glob(3)
function itself will continue to support it unconditionally). Add 0x20
to _CRT_glob, (as boolean addition; it needs ((_CRT_glob & 2) == 2) to
select the new glob(3) algorithm, and other options are then bit
mapped), to enable it for the command line.
New snapshot, posted at same URL, implements this, together with
tentative handling for the (*errfn)() hook.
>> One additional feature, which I have made a non-default option; with the
>> new globbing algorithm, adding 0x10 to _CRT_glob, as in:--
>> int _CRT_glob = 0x12;
>> and you'll get POSIX-like handling of *both* apostrophes *and* double
>> quotes, as argument quoting characters. However, \ remains as a
>> directory name separator, so isn't available as an escape; we may need
>> to choose a new alternative character for use as an escape, as a later
>> addition. Thoughts? Suggestions?
> Treat \ as an escape character only if it precedes a ' or " character.
Sorry. I didn't express this clearly. You've answered the question I
posed, but (unsurprisingly) not the one I intended.
> That's what DJGPP does, and it works very well in practice.
Yeah. That's also what Microsoft stipulates, (at least in the case of
the double quote; see http://tinyurl.com/6vgvax8). Extending that to
handle escaped apostrophes similarly, (when the `apostrophes as quotes'
option is enabled), is a no-brainer; if I've got it right, (as I think I
have), my implementation should already work this way.
The issue I intended to raise was not the escaping of quotes, but of
globbing tokens. In any POSIX conforming glob(3) implementation, if
GLOB_NOESCAPE is not set in the flags argument, any \ in the pattern
will be parsed as an escape, so *, ?, and [, in \*, \?, and \[, lose
their significance as globbing tokens. In a Windows implementation that
becomes problematic, because \ is normally read as a directory name
separator, which would make
$ glob c:\foo\bar\*.*
ambiguous, and I don't think we can realistically expect users to adapt
to consistently using
$ glob c:\foo\bar\\*.*
as an unambiguous alternative. So, if we want GLOB_NOESCAPE to have any
significance at all, (and I think it should), then we need to choose an
alternative escape character, for use within the glob(3) implementation
on which this improved command line globbing method depends. What
character should we choose? ^ perhaps? Or should we expect cmd.exe to
swallow that? Some other choice? I'm open to suggestions.
>> I'd like to tidy up some loose ends, before this is released, but please
>> feel free to play with the snapshot, and report any issues.
> Will do, definitely.
> Thanks again for doing this.