On Wed, Apr 1, 2015 at 3:24 PM, Jon Rowe <[email protected]> wrote:
Reasonable enough.
>
> Our implementation of shell escape is supposed to work for POSIX and
> windows so perhaps a PR to correct the escaping of +?
>
> I'm sure we'd also welcome a PR escaping the file names in regular
> expressio s.
>
>
> On Thursday, 2 April 2015, Cédric Boutillier <[email protected]>
> wrote:
>
>>
>>
>> On Wednesday, April 1, 2015 at 1:28:45 AM UTC+2, Jon Rowe wrote:
>>>
>>> At the risk of sounding facetious… could you not just rename the
>>> directory?
>>>
>>>
>> Thanks for your question. Here is more context: what I am trying to do is
>> to package rspec3 for the Debian Linux distribution. For the moment, we
>> have rspec2 split into several source packages. The specs are run during
>> the build of the package, but because of the interdependency of the gems,
>> this was creating cyclic build dependencies. For rspec3, we want to have a
>> unique source package, which would combine the source of the various
>> rspec-* gems to avoid this cyclic dependency. So we need a way to reflect
>> in the version number of the package the patchlevels of the various gems.
>> In Debian, + is a standard suffix to add some info to the upstream version
>> number. This is the cause of my problem.
>> I can consider using something else for the suffix, but my guess is that
>> if another gem which will be using for some reason rspec-support and must
>> have a + in its name/version number, the same problem will occur.
>>
>> I see that some care is taken to deal with filenames with spaces. Having
>> special symbols like + is maybe more rare, but can occur.
>>
>> Cédric
>>
> To expand a bit on what Jon said…we absolutely want to ensure RSpec works
properly on projects that use spaces, + or any other funny character in
their file names.
For RSpec’s own specs, we certainly haven’t put the same level of care into
ensuring that RSpec’s spec suite passes when people clone it to a directory
containing non-standard characters. Honestly, I can’t think of a time
anyone has ever asked about this before, so we simply haven’t thought about
it or put effort into it. Given the fact that this only affects people who
run RSpec’s specs, and doesn’t affect normal RSpec usage, it’s something
that we’re unlikely to put the time and effort into fixing…but as Jon said,
we’d welcome a PR (or multiple PRs) to fix the specs that suffer from this
issue. The Regexp.escape is one solution. Another is to use a composed
matcher (like a_string_including("#{__FILE__}:#{__LINE__}")) so that we’re
not even using regexes derived from the current file name.
If we do merge some PRs addressing this, it would be cool to update our
travis builds to catch these problems. Maybe we can find to make travis run
things in a non-standard directory containing some of the problematic
characters?
Myron
--
You received this message because you are subscribed to the Google Groups
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/rspec/CADUxQmtw83HxKY%2BPLHzOnu498SBYYd7AepF-dn3Wu2yRr3P%2Bhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
