xspec.sh doesn't run out of the box on a Unix other than Darwin.

[GoogleCodeExporter]

Steps:
1. curl -O http://xspec.googlecode.com/files/xspec-v0.2.zip
2. unzip xspec-v0.2.zip
3. adapt CLASSPATH of xspec.sh to point to your saxon jar.
4. curl -O http://xspec.googlecode.com/svn/trunk/tutorial/escape-for-regex.xslt
5. curl -O http://xspec.googlecode.com/svn/trunk/tutorial/escape-for-regex.xspec
6. ./xspec.sh escape-for-regex.xspec

Expected effect is the test report to show up in my browser, however I get the 
error message:
"Couldn't get a file descriptor referring to the console"

This is due to the "open" command which has a different meaning under Darwin 
than other Unices. The corresponding command in other Unices is "see".

There's a patch in the attachment that lets the script run in both environments.

Apply it with:
patch xspec.sh < xspec.patch

Original issue reported on code.google.com by sbs....@gmail.com on 1 Sep 2010 at 10:06

Attachments:

• xspec.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

... here's the patch against the current svn version

Original comment by sbs....@gmail.com on 1 Sep 2010 at 10:42

Attachments:

• xspec.patch

[GoogleCodeExporter]

Fixed in revision 177.  I just reversed the test on the OS name, as Darwin is 
probably a more specific case.  By the way, I always thought that was behind 
the duty of such a script to open the result file, so personally I think we 
should simply get rid of those lines.  What do you think?

Original comment by fgeorges on 15 Sep 2010 at 1:54

• Changed state: Fixed

[GoogleCodeExporter]

Thank you, Florent!
I agree about the separation of concern, i.e. that xspec.sh should not display 
the html files but leave that to an enclosing script. Maybe a "driver.sh" 
script could be added that calls xspec.sh and displays xspec.sh's results.

(There's an appeal for newcomers to have a script, i.e. driver.sh, that runs 
out of the box and opens test results in their browser).

While we're at it: I think setting the CLASSPATH to the saxon.jar shouldn't be 
done within xspec.sh. xspec.sh should rely on saxon.jar already being on the 
CLASSPATH.
The Wiki (and possibly the error message within xspec.sh) could provide the 
command line, how to call xspec.sh (or driver.sh, respectively), e.g.:
CLASSPATH = $CLASSPATH:path_to_your_saxon.jar xspec.sh
CLASSPATH = $CLASSPATH:path_to_your_saxon.jar driver.sh

Original comment by sbs....@gmail.com on 15 Sep 2010 at 3:23

[GoogleCodeExporter]

I agree in principle about separating these concerns, and that we should 
careful to not make things too complicated for new users.  

Expanding on the driver.sh idea, should we consider distributing Saxon HE with 
xspec?  That way, we could preset the classpath in driver.sh, and have an easy, 
out-of-the-box solution for new users?  

(This discussion might be better suited for the mailing list, but I didn't know 
if Bernhard was subscribed.)

Original comment by jsulak@gmail.com on 15 Sep 2010 at 3:33

[GoogleCodeExporter]

Thanks for those comments!  A couple of comments about them:

1/ I don't think distributing Saxon is a good idea.  Usually
Saxon will be installed in an environment where XSpec is used, or
even the test suites are not supposed to be run with Saxon at
all.  In that case, shipping the 5+ M. of Saxon with XSpec is
just a nonsense.

2/ For quite a long time now, I'd like to write "test harnesses"
for different processors (like eXist and MarkLogic) which require
more than for Saxon.  For eXist for instance it will require to
compile the test suite locally, using Saxon, then evaluate it in
eXist and get the result back.  In MarkLogic, with the next
version supporting XSLT 2.0, we will be able to do everything on
the database.  XQSharp has just announced support for XSLT 2.0 as
well, in addition to XQuery.  Etc., etc.

3/ I never had to set the CLASSPATH myself, and I don't think any
usual program does expect so.  All the Java program I use just
expect a *_HOME variable to be set )or something similar), then
do what they have to with it.  For Saxon, there is no such
variable defined by Saxon itself.

My approach usually is to rely on either SAXON_HOME and SAXON_CP
(like in [1]).  SAXON_CP is a ready-to-use classpath to launch
Saxon (including maybe other JARs, that the user may know he
needs).  If SAXON_CP is not set, then SAXON_HOME must be set to
the directory Saxon is installed (then we use saxon9ee.jar, or
saxon9pe.jar, or ...)

4/ About the mailing list: yes, that's probably a good idea.
Bernhard, are you ok with switching to the list?

[1]http://code.google.com/p/expath-pkg/source/browse/trunk/saxon/pkg-saxon/src/s
hell/saxon

Original comment by fgeorges on 15 Sep 2010 at 6:20