## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Proportional Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

 Subject: Re: Reading from the system (pipe input) From: Joseph Wright <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Mon, 26 May 2014 11:02:59 +0100 Content-Type: text/plain Parts/Attachments: text/plain (75 lines)
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