Re: [xml] Why does "-" read from stdin?

[Tim Van Holder <tim vanholder anubex com>]

Michael Day wrote:
> Hi Tim,
>
> > It's fairly typical behaviour on Unix systems (may even be POSIX, not
> > sure). And no, there isn't.
>
> It's typical behaviour for programs, not libraries; eg. fopen("-") does 
> not return stdin. The issue I'm concerned with is the way that an API 
> function taking a filename treats one value specially, requiring a check 
> and escaping by the caller, when it seems that aliasing "-" to mean 
> stdin is a decision to be made at a higher level, for example when 
> processing command line arguments.

fair point

> > Sure - but so would CON under windows, or /dev/stdin, or /dev/ttys7, ...
>
> These situations are different in that you can actually have a regular 
> file called "-", and the xmlReadFile() function won't load it. This is 
> different from calling xmlReadFile() on a filename that turns out to be 
> bound to a socket or a pipe or some other blocking input (or an NFS 
> filesystem for that matter). Blocking after trying to load "/dev/stdin" 
> is not surprising, blocking while trying to load "-" is.
>
> The header file and the doxygen comments do not even mention that "-" is 
> treated specially; xmlParseFile() takes an argument called filename and 
> xmlReadFile() takes an argument called URL, when the actual meaning of 
> the value is more subtle: URL/filename unless the value is - in which 
> case it means stdin. Again, this requires every caller to check for "-" 
> and substitute "./-".
>
> To be honest the special treatment for "-" seems more like a hack to 
> simplify xmllint than a sensible API choice for a generic XML library. I 
> understand that now is probably too late to change this kind of stuff, 
> as libxml2 was frozen in stone years ago. But perhaps it's not too late 

Well if it's not documented, it's not set in stone - but I'm inclined to
agree it's probably safest to just document it.

> to document it. How about changing:
>
> /**
>   * xmlParseFile:
>   * @filename:  the filename
>
> to this:
>
>   * @filename:  the filename, or "-" to parse from standard input
>
> similarly for xmlReadFile:
>
>   * @filename:  a file or URL, or "-" to parse from standard input
>
> That would at least place a warning sign in the documentation for 
> application developers to be aware of what the argument really means.