4

I want define a command "\foo" which outputs the result of a shell command, such as:

\newcommand{\foo}[1]{\input{|"#1"}}

This works, except if I'm trying to use this command in the context of \includegraphics:

\includegraphics{\foo{command attr1 attr2}}

where command is a shell command which outputs a filename. For example, with command: "echo im" and im.png an image on the same directory, I get this error:

! Undefined control sequence.
\filename@simple ...#2\\}\fi \edef \filename@base 
                                                  {#1}
l.14 \includegraphics{\foo{echo im}}
5

It works if you make it a bit easier for the filename parser (I wasn't planning on making this work back then:-) by moving the shell command before the graphics inclusion:

\documentclass{article}

\usepackage{graphicx}

\makeatletter
\long\def\eatspace#1 {#1}
\def\foo#1{\edef\result{\expandafter\eatspace\@@input|"#1;echo \string\\noexpand"}}
\makeatletter

\begin{document}



\foo{echo ug}
\includegraphics{\result}

\end{document}

Then

pdflatex --shell-escape gr44

reports:

...
 <ug.png, id=1, 264.23718pt x 288.3272pt> <use ug.png> [1{/usr/local/texlive/20
13/texmf-var/fonts/map/pdftex/updmap/pdftex.map} <./ug.png>] (./gr44.aux) )</us
r/local/texlive/2013/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb>
Output written on gr44.pdf (1 page, 9920 bytes).
Transcript written on gr44.log.

showing the image was included

  • Thanks ;) I created a custom \includegraphicsShell command which works like \includegraphicsShell{echo up}, so this is acceptable. Only one limitation for now, I have issues with escaping my shell command (For example, if I need to do \foo{python -c "code with 'strings'"}, it interact with the \input command. – Guillaum Dec 18 '13 at 17:23
  • @Guillaum really I wouldn't do this, I'd just run the python first and let it do whatever and write xxx.tex that has one line\includegraphics{....} then you just need \input{xxx} in the tex file and don't need --shell-escape – David Carlisle Dec 18 '13 at 17:31
  • except from the potential security issue introduced by -shell-escape, do you see any other reason to avoid this approach ? Dependencies buildings are driven by the document, they are always in sync (so no need for multiples passes to generated dependencie list and pass them to a makefile) and I don't have to worry about file naming (currently, my scripts generate unique names based on the parameters used). – Guillaum Dec 18 '13 at 20:42
  • @Guillaum not really any reasons you don't know:-) you know your situation better, I just thought I'd float the idea. It can simplify quoting and if you ever need to make the files portable without the scripting you have the generated files, but these may not be considerations in your case. – David Carlisle Dec 18 '13 at 20:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.