LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Mon, 26 May 2014 11:02:59 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=Big5
From: Joseph Wright <[log in to unmask]>
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

ATOM RSS1 RSS2