issue with specs when directory name contains +

[Cédric Boutillier]

Hi,

I am trying to run the specs for the various rspec* gems. The files are in a directory with full path contains a '+' character. I run into several failures, because of this symbol.

Most of them are due to the fact that in the specs, messages are matched against regexps constructed from __FILE__, like /#{__FILE__}:#{__LINE__}/, but to take care of the special + symbol, __FILE__ would need to be replaced by Regexp.escape(__FILE__).

However, one is more subtle and is caused by the method run_ruby_with_current_load_path from rspec-support/lib/rspec/support/spec/shell_out.rb. It currently calls :shellescape on all directory names in the $LOAD_PATH, to call the Ruby interpreter with these escaped directory as an argument for the -I option. However, when doing that, names in the $LOAD_PATH containing a + are not found by the interpreter once escaped (causing failures because ruby cannot find some libs, like rspec/core in tests using run_ruby_with_current_load_path), but if I remove simply the shellescape call, then for some reasons, the specs are exploring all my disks, because certainly something went wrong with the -I parameters without the shellescape...

Do you have an idea how one could fix the last step?

Thank you in advance for your advice.

Cheers,

Cédric

[Jon Rowe]

At the risk of sounding facetious… could you not just rename the directory?

Jon Rowe

---------------------------

ma...@jonrowe.co.uk

jonrowe.co.uk

--
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 rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/2e612d13-abf4-426c-be67-59df3b56d3c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cédric Boutillier]

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

[Jon Rowe]

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.

--

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 rspec+un...@googlegroups.com.
To post to this group, send email to rs...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rspec/ddead03c-caba-4c97-95a4-6556e2307f01%40googlegroups.com.

[Myron Marston]

On Wed, Apr 1, 2015 at 3:24 PM, Jon Rowe <ma...@jonrowe.co.uk> 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 <cedric.b...@gmail.com> 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

​

[Cédric Boutillier]

Thanks for your answers. I'll polish the patch I already have and submit a PR about the escaping in regexp, and I'll do some more research about the specific problem I mention in my first message.

Cheers,

Cédric