Re: Using full paths in Calabash p:store

Ah, for some reason the breakthroughs this week are coming just *after*
sending a message for help to the list.

The problem here ('index 12' should have clued me in) is the space in the
URI.  If I use a directory without spaces in the name, things work as
expected.

Is this an issue in how Calabash treats windows URIs, or is there a way I
should be escaping URIs with spaces in them?

-Tom (a reluctant windows user at work)

On 22 April 2010 12:26, HILLMAN, Tomos <tomos.hillman@oup.com> wrote:

> Hi List,
>
> I'm having issues with Calabash when using p:store in situations like this:
>
>                <p:store name="saveFiles">
>                    <p:input port="source">
>                        <p:pipe port="result" step="XSLtransform"></p:pipe>
>                    </p:input>
>                    <p:with-option name="href" select="concat($output, '/',
> $fileName)"/>
>                </p:store>
>
> where $fileName is an xml file name as generated by p:directory-list
> and $output is a URI for a directory, e.g:
> 'file:/U:/xml examples/CMS_Data_Output'
>
> This fails with the message:
> Engine name: Calabash XProc
> Severity: error
> Description:  Illegal character in path at index 12: file:/U:/xml
> examples/CMS_Data_Output/IC-BT010(1998).xml
>
> This directory format is the same used to supply the argument for the
> p:directory list, which works fine; however calabash seems to be
> interpreting the href value as an invalid file name rather than an absolute
> path - if I replace the @select statement with just $fileName, the results
> save just fine in the xproc script directory.
>
> Can anyone shed any light on this?
>
> Thanks,
> Tom
> Oxford University Press (UK) Disclaimer
>
> This message is confidential. You should not copy it or disclose its
> contents to anyone. You may use and apply the information for the intended
> purpose only. OUP does not accept legal responsibility for the contents of
> this message. Any views or opinions presented are those of the author only
> and not of OUP. If this email has come to you in error, please delete it,
> along with any attachments. Please note that OUP may intercept incoming and
> outgoing email communications.
>
>

Received on Thursday, 22 April 2010 16:54:05 UTC