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

 Options: Use Classic View Use Monospaced Font Show Text Part by Default Condense Mail Headers Topic: [<< First] [< Prev] [Next >] [Last >>]

 Sender: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Fri, 23 May 2014 23:22:11 +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="ISO-8859-1"; format=flowed From: David Carlisle <[log in to unmask]> Parts/Attachments: text/plain (68 lines) 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