User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (: nag.co.uk does not designate permitted sender hosts)
Message-ID:  <537FCA13.3000700@nag.co.uk>
Date:         Fri, 23 May 2014 23:22:11 +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: David Carlisle <davidc@NAG.CO.UK>
Subject: Re: Reading from the system (pipe input)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <537E60D1.7010708@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

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