User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0)
            Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
References: <537E212E.2030607@morningstar2.co.uk> <537E5311.3020302@nag.co.uk> 
            <537E60D1.7010708@morningstar2.co.uk> <537FCA13.3000700@nag.co.uk>
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: 7bit
Message-ID:  <53831153.50107@morningstar2.co.uk>
Date:         Mon, 26 May 2014 11:02:59 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: Reading from the system (pipe input)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <537FCA13.3000700@nag.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 23/05/2014 23:22, David Carlisle wrote:
> On 22/05/2014 21:40, Joseph Wright wrote:
>> On 22/05/2014 20:42, David Carlisle wrote:
>>> On 22/05/2014 17:09, Joseph Wright wrote:
>>>> Hello all,
>>>>
>>>> Currently, we have \ior_open:Nn for reading from a file, but no defined
>>>> interface for using the 'pipe' shell escape provided by pdfTeX. As we
>>>> forbid spaces in file names,
>>> why do we do that? Spaces in filenames always seem like an abomination
>>> to me.
>>> But that seems to be a relic on the 1970s I've noticed that people who
>>> started using
>>> computers this century don't seem to think anything of using a
>>> descriptive phrase
>>> as a filename...
>> The logic here was that, at least as I understand it, there are some
>> places where you can't just 'wrap up spaces' and have them work. In
>> particular, there are some comments about dvips and included graphics
>> which suggest that space behaviour is hard-coded in that case and can't
>> be changed. (MiKTeX also does some 'interesting' things with BibTeX
>> input names containing spaces.) I may have this wrong: can other more
>> knowledgeable people comment?
>>
>> This can of course be changes if required.
> 
> issues with existing implementations aside....
>>> Shouldn't we just allow spaces (and leading | or any other system
>>> dependent special
>>> syntax) just surrounding any user supplied name by " " to keep it
>>> together?
>> Space behaviour notwithstanding, I think the point here is that the pipe
>> input approach is sufficiently different from a 'real' file to deserve a
>> separate interface.
> 
> My instinct here is still that the pipe interface being exposed as a
> file is a feature that should be
> preserved rather than hidden.
> 
> At the bottom programming layer it probably seems natural to have
> separate functions for accessing files
> or for invoking commands, but if you separate them you need to duplicate
> the entire stack all the way
> up to the document level, all  file reading commands would need to be
> duplicated or have some
> way of accessing the pipe functionality.
> 
> In 2e you can  do
> 
> \documentclass{article}
> 
> \begin{document}
> 
> \input{"|zcat foo.tex.gz"}
> 
> \end{document}
> 
> to input a compressed file (and zcat could be replaced by a database
> query or wget to do web request or whatever.
> You can do same with \include  and \InputIfFileExists and...
> 
> The easiest way to ensure that all top level file reading can access
> pipes (if enabled) as well as files is to not distinguish
> them and just treat them as files. The syntax for a filename is
> explicitly system dependent in anycase and this is not really
> so different (which is how come it came to be hooked into the \input 
> syntax in the first place).
> 
> David

OK, this seems like a reasonable argument. I'll update the behaviour
w.r.t. spaces.
-- 
Joseph Wright