Closed
Bug 302907
Opened 19 years ago
Closed 19 years ago
makexpi.sh fails on FreeBSD
Categories
(Other Applications :: ChatZilla, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mpk, Assigned: rginda)
Details
(Whiteboard: [cz-0.9.69])
Attachments
(1 file)
2.56 KB,
patch
|
rginda
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•19 years ago
|
||
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,\}
Attachment #191178 -
Flags: review?(rginda)
Comment 2•19 years ago
|
||
what the...? How on earth can it support {min,max} and NOT +? And what's up with not having pushd/popd?
Reporter | ||
Comment 3•19 years ago
|
||
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•19 years ago
|
||
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?
Reporter | ||
Comment 5•19 years ago
|
||
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".
Assignee | ||
Comment 6•19 years ago
|
||
Comment on attachment 191178 [details] [diff] [review] cleanup of makexpi.sh r=rginda
Attachment #191178 -
Flags: review?(rginda) → review+
Comment 7•19 years ago
|
||
Checked in --> FIXED.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Whiteboard: [cz-0.9.69]
You need to log in
before you can comment on or make changes to this bug.
Description
•