## 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: 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