Hi, On 2011-04-10 13:22:57 +0200, Mònica Ramírez Arceda wrote: > Here you have the upstream's answer: > > ----------------- > It's not clear to me that entities should be parsed here. The decription of > -v is > > -v or --value-of <xpath> - print value of XPATH expression > > The argument is an XPath expression, not an XML string representing an > XPath expression. > It seems to me that the older behaviour was an accident of the > implementation rather than an official feature. A problem with the old > behaviour would be: > $ ./src/xml sel -T -t -v "'&'" > Entity: line 23: parser error : xmlParseEntityRef: no name > <xsl:value-of select="'&'"/> > > See: > http://sourceforge.net/tracker/?func=detail&aid=3240736&group_id=66612&atid=515106 > ----------------- > > But there is an open thread in devel upstream list where this issue > can be discussed.
The above point makes sense, but XMLStarlet should behave in a consistent way: if it doesn't assume XML for XPath expression arguments, then it shouldn't do XML normalization on them! > Do you have an argument that could be made in favour interpreting > entities on practical grounds? In practice, I want to be able to pass a tab character (as allowed by XPath). Passing the tab character itself doesn't work: it is replaced by a space, due to XML normalization I assume. That's why I was using a character reference. XMLStarlet should be fixed in one way or the other, so that at least one of the following works, i.e. gives a line with "a" followed by a tab character followed by "b": $ echo '<root/>' | xml sel -T -t -v "'a$(printf \\t)b'" -n $ echo '<root/>' | xml sel -T -t -v "'a	b'" -n Currently the former command gives: "a b" (with a space). > I can forward your argument/s to this list, if you want. Yes, please. -- Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
