Fix Pandoc version check in configure by iKevinY · Pull Request #22474 · rust-lang/rust

iKevinY · 2015-02-18T02:50:51Z

Executing configure seems to create the following error due to how the script parses Pandoc's version:

./configure: line 705: [: pandoc: integer expression expected
./configure: line 705: [: 1.12.4.2: integer expression expected

This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.

rust-highfive · 2015-02-18T02:51:05Z

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

iKevinY · 2015-02-18T09:04:22Z

After trying a few things, I decided upon this solution, which uses grep to isolate the MAJOR.MINOR component of the version number, and changed the shell globs to use . as the delimiting character.

alexcrichton · 2015-02-24T01:02:10Z

@bors: r+ b720412a673e2d2afdd574841475d32f157fb593

iKevinY · 2015-02-24T01:17:10Z

@alexcrichton Do you think that using grep -Eo and head is portable enough to work on all systems? I don't have too much experience with anything outside of OS X, and I don't want this patch to fix behaviour on OS X just to have it break on other systems.

alexcrichton · 2015-02-24T01:19:49Z

Hm, I'm not quite sure. I know that @brson has been doing a bunch of shell scripting recently though and may know better than I.

r? @brson

alexcrichton · 2015-02-24T01:19:52Z

@bors: r-

brson · 2015-02-24T01:36:42Z

I think it's ok. -E is common. -o I'm not sure of (doesn't work on Solaris).

Better than the existing breakage anyway.

iKevinY · 2015-02-24T02:56:28Z

Hmm, is it safe to use \d or should I just leave it as [0-9]? I did some really basic testing on an Ubuntu VPS and grep -E doesn't seem to like \d.

Edit: I've changed \d to [0-9] since it seems as though the \d character class isn't recognized by all versions of grep. This still leaves the issue of grep -o, though.

iKevinY · 2015-02-24T18:21:00Z

@brson I was thinking about -E, and realized the best fix would probably be to just change the existing sed command to use an extended regex (sed -E 's/pandoc(.exe)? ([0-9]+)\.([0-9]+).*/\2 \3/'); this works on both OS X and Ubuntu for me. How does this patch sound?

Using an extended regex fixes pattern matching on BSD sed.

brson · 2015-03-05T23:47:12Z

@bors: r+ 4349

Executing `configure` seems to create the following error due to how the script [parses Pandoc's version](https://github.com/rust-lang/rust/blob/master/configure#L705): ```text ./configure: line 705: [: pandoc: integer expression expected ./configure: line 705: [: 1.12.4.2: integer expression expected ``` This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.

bors · 2015-03-06T00:27:56Z

⌛ Testing commit 4349fa4 with merge cd05a57...

bors · 2015-03-06T03:02:15Z

💔 Test failed - auto-linux-32-opt

alexcrichton · 2015-03-06T06:14:08Z

@bors: retry

bors · 2015-03-06T09:26:36Z

⌛ Testing commit 4349fa4 with merge aba1498...

Executing `configure` seems to create the following error due to how the script [parses Pandoc's version](https://github.com/rust-lang/rust/blob/master/configure#L705): ```text ./configure: line 705: [: pandoc: integer expression expected ./configure: line 705: [: 1.12.4.2: integer expression expected ``` This issue seems to stem from a discrepancy between BSD and GNU versions of sed. This patch changes the sed command to use an extended regex, which works with both flavours of sed.

bors · 2015-03-06T10:55:22Z