Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 66.249.82.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=RvljF42TU0R+jl0HEPhbWq9cF7blwF/bUNIG2cs2VJ7TGUECjHIlLCtcxDb+ggd0h9s9FXP+nJ6mgxxQLfOIXJkGO4wB9hI9OhSUfS8Ox2RxhPKqseqLotpZPEPrEOXOLtc+ngzV4ajEWKNwgF1gr3ystohMnuI9glj2CNR2z5c=
Message-ID: <47BBC9C5.7020801@roguewave.com>
Date: Tue, 19 Feb 2008 23:33:41 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r628839 - /stdcxx/trunk/tests/self/0.braceexp.cpp
References: <47BB356D.3040708@roguewave.com> <15580502.post@talk.nabble.com>
In-Reply-To: <15580502.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
> 
[...]
> The function rw_brace_expand() does brace expansion on whatever string you
> pass. There is no special treatment for whitespace [as required by the Bash
> Reference Manual]. That is a feature of the shell. The difference is very
> significant...

Okay, that was an important point I missed. The question then is:
which is more useful? Or, if we think both are, we might want to
consider implementing both.

> 
> If you pass the string "first {1,2} last" to the shell for expansion, you
> will get "first 1 2 last" as output. The shell is brace expanding each of
> the three tokens seperately. If you brace expand this as one string, which
> you can do by escaping the spaces, you get a different result. You should
> get "first 1 last first 2 last".
> 
> I think much of the confusion we are having is because we are testing our
> rw_brace_expand() function with the bash test suite. Our function only
> implements one of the many features of bash, but the test suite verifies
> several of the bash features are working together correctly.

You're probably right. My confusion, if you want to call it that,
probably does stem from my expectation to use the function the
same way I use the shell. In my view, the whole "raison d'etre"
for the function is that we don't have a UNIX shell on Windows.
If we did, some of the features in the driver, including the
locale query, and most of those in the harness (the exec utility)
would probably be relegated to it and we wouldn't need to
(re)implement it ourselves.

I wonder if it would help us move forward to outline the major
use cases for the function. Here are the ones at the top of my
list:

  *  to help with locale matching in the locale query string, i.e.,
     as part of the mechanism behind the rw_locale_query() function

  *  to help with the matching of platforms in the expected failures
     project, i.e., again, as one of the essential pieces, along with
     rw_fnmatch(), behind an rw_match_platform() or some such function
     to match the platform string from xfail.txt
     against the actual platform

  *  to help generate input strings for some of our tests (I don't
     have a clear picture of how to use it here)

Are there any others?

In the first two cases, I envision using the function pretty much
exactly how I would use the shell + grep (e.g., to process the
xfail.txt file). In the last case, I can imagine using it a little
or maybe even a lot differently, i.e., with various extensions or
differences from how the shell behaves.

How do you expect to use it?

In all cases, I think we will get the biggest bang for our buck if
we design and implement rw_brace_expand() in a way that will make
coding the bigger features as easy as possible by handling as much
of the shared use cases in it instead of duplicating the same thing
at the outer layers. Does this make sense?

> 
> 
[...]
> I wish I could get inside the heads of the guys writing this stuff. By
> introducing such a change, they are potentially breaking existing user code,
> and there appears to be no net benefit for making such a change. As we've
> already established, it is quite easy to stick an additional set of braces
> in there.

I can't help you there, but you can get some insight by reading the
archives of the bug-bash list or ask your questions on it:
   http://lists.gnu.org/archive/html/bug-bash/
But I don't think the corner cases are terribly important to get
exactly the same as in Bash or even implemented at all, just as
long as we have a solid implementation of the common ones.

> 
[...]
> I could, but I think it would be better to implement something on top of
> rw_brace_expand() that expands each of the whitespace seperated tokens
> seperately, just like bash does. If rw_brace_expand() becomes a private
> implementation function, then so be it.

Whatever works. It all depends on how we end up using it. We haven't
spent much time talking about the top level interface yet. Maybe it
would help if we did? What do you expect the rw_locale_query()
interface will look like? And how do you envision it to be implemented
in terms of rw_brace_expand() and rw_fnmatch()? (I should probably do
the same exercise for rw_match_platform().)

> 
[...]
> Unfortunately the bash testcases rely heavily on additional behavior
> implemented in bash [environment variable expansion, whitespace collapse,
> and more. I understand the motivation, I just want to make sure we all
> understand that some of the cases don't work because we're not implementing
> bash. We're implementing a single feature of bash.

Yes, but the only way to use that feature is in conjunction with at
least some of the others, such as collapsing whitespace. I do agree
that the environment variable expansion can be done separately. I'm
not 100% convinced that it necessarily has to be, but I'm not at all
opposed to it, certainly not if it makes the implementation cleaner
and easier to maintain and enhance.

Martin