302907 - makexpi.sh fails on FreeBSD

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Marco Perez [:mpk]]

The version of sed that comes with FreeBSD (up to 6.0-Beta) doesn't seem to
support \+ as a quantifier. So the extraction of the version string fails.

In addition, applying several rather small changes to the script, it can be
made compatible with older versions of the bourne shell as well. This might be
interesting for platforms such as HP-UX, Solaris, AIX, *BSD and maybe others.

I'll attach a possible patch shortly.

Comment 1

[Marco Perez [:mpk]]

Attachment: cleanup of makexpi.sh

changes:
 - use #!/bin/sh instead of #!/bin/bash
 - use [ "$VAR" = "value" ] instead of [ "$VAR" == "value" ]
 - replace pushd/popd with generic methods
 - replace sed quantifier \+ with \{1,\}

Comment 2

[James Ross]

what the...? How on earth can it support {min,max} and NOT +?

And what's up with not having pushd/popd?

Comment 3

[Marco Perez [:mpk]]

Well, I wish I knew. It just does. I guess that {min,max} has been around for
quite some time, when some versions of sed started to support + while others
still didn't.
  echo It\'s\ \"strange\",\ isn\'t\ it? | sed "s|.*\"\([^\"]\+\)\".*|\1|"
results in:
  It's "strange", isn't it?
while
  echo It\'s\ \"strange\",\ isn\'t\ it? | sed "s|.*\"\([^\"]\{1,\}\)\".*|\1|"
results in:
  strange

As for pushd/popd, bash supports them. Unfortunately the standard shell on
FreeBSD does not. Neither does ksh, which is the standard shell on many of
the commercial unices. One might argue that simply installing bash solves the
problem. On the other hand, there are simple alternatives to pushd/popd that
work on virtually any shell.

I didn't mean to offend anyone or to criticise anyone's work. I just thought
that others might run into the same problems that I did. And since I found a
way to avoid them I wanted to share my solution. Maybe there are still better
ways. Who knows?

Comment 4

[James Ross]

I don't really like the in-elegant non-pushd/popd solution, but then I don't
like bash most of the time.

I think the + thing could be an escaping issue - can you actually confirm
completely that it is not supported? (via man page, and REALLY simple regexp)

I'm also actually curious on the == -> = change. Does that still work in bash?

Comment 5

[Marco Perez [:mpk]]

Well, I chose the aproach with $OLDPWD because most shells (at least ash, bash,
ksh93, pdksh and zsh) set OLDPWD anyway when changing the current directory.
But I have to admit that the method really is somehow in-elegant.

The problem with + seems to be that according to the manpage of sed(1)
"the regular expressions used in sed, by default, are basic regular expressions".
The manpage of re_format(7) states that "BREs differ in several respects" and
"`+' and `?' are ordinary characters, and their functionality can be expressed
using bounds (`{1,}' or `{0,1}' respectively)"

BTW, manpages for different systems are available at the following URL:
http://www.freebsd.org/cgi/man.cgi

The section about "conditional expressions" in the manpage of bash(1) contains
the following:
 string1 == string2    True if the strings are equal.
                       = may be used in place of == for strict POSIX compliance.

"string1==string2" will work on FreeBSD whereas "string1 == string2" does not.
Interestingly enough, the manpage of test(1) only mentions "string1 = string2".

Comment 6

[Robert Ginda]

Comment on attachment 191178 [details] [diff] [review]
cleanup of makexpi.sh

r=rginda

Comment 7

[James Ross]

Checked in --> FIXED.