8

With the following MWE:

\documentclass{article}
\usepackage{filecontents,hyperref,listings}

\begin{filecontents*}{script.bat}
@echo off
echo "Hello, World!"
pause
\end{filecontents*}

\begin{document}
\lstinputlisting[language=csh,float,caption={A Windows batch file}]{script.bat}

Click \href{run:script.bat}{here} to run the script.
\end{document}

I always receive the error

ERROR: I can't write on file `script.bat'.

--- TeX said ---
<to be read again> 
                   \relax 
l.4 \begin{filecontents*}{script.bat}

In interactive mode (pdflatex test), this error continues until a filename is given which does not have that 'bat' extension. What's going on here?

Sean Allred
  • 27,421
  • 1
    I have no problem on my system. – egreg Jul 25 '13 at 12:38
  • no problem here on a linux system. – barbara beeton Jul 25 '13 at 12:38
  • 1
    No problem on my Mac. – jub0bs Jul 25 '13 at 12:49
  • 2
    Same problem with system file extensions like .com, .dll, etc too in Windows! – Jagath Jul 25 '13 at 12:53
  • 2
    This is because windows (at least the latest versions) block running .bat and certain other files due to the security risks. You will see it works fine if you change .bat to .txt. I'm not sure you can make this possible without severely compromising the security of your windows machine. – Mythio Jul 25 '13 at 13:05
  • Yes, we can do one thing just as a workaround. If you have CygWin installed, give \begin{filecontents*}{script.txt} and after \end{filecontents*}, in next line give \immediate\write18{mv script.txt script.bat}. This will work. Of course, you need to enable --shell-escape. I tested and this works. – Jagath Jul 25 '13 at 13:10
  • Working on a latex "virus"? I know you loose a little bit and it won't fix your problem, but why not just simply have a static batch file, where is the advantage in generating it from tex? – ted Jul 25 '13 at 13:25
  • @ted It is common practice here on TeX.SX to include auxiliary files within a single source, so that the solution is as portable as possible. When answering a question, I ran into this problem the second time I ran it. (The first time it worked wonderfully.) Writing a TeX virus would be far more... sneaky ;) – Sean Allred Jul 25 '13 at 14:59
  • @barbarabeeton,Jubobs as Mythio has pointed out, it does appear to be Windows-specific. I've also never had a problem on my *nix installations. – Sean Allred Jul 25 '13 at 15:02
  • @JagathAR Dirty trick, and not in the spirit of the motive for filecontents ;-) (I also don't think Cygwin is a requirement; the appropriate DOS command is REN or RENAME.) – Sean Allred Jul 25 '13 at 15:04
  • @SeanAllred: I Know that! – Jagath Jul 25 '13 at 15:08

1 Answers1

4

In Windows, you will generally encounter this error due to security reason. To get rid of such error you need to do follow this:

Set the value openout_any = r in texmf.cnf. Three options are available here, any (a), restricted (r) and paranoid (p).

% Allow TeX \openin, \openout, or \input on filenames starting with `.'
% (e.g., .rhosts) or outside the current tree (e.g., /etc/passwd)?
% a (any)        : any file can be opened.
% r (restricted) : disallow opening "dotfiles".
% p (paranoid)   : as `r' and disallow going to parent directories, and
%                  restrict absolute paths to be under $TEXMFOUTPUT.
openout_any = p
openin_any = a

Note: As per the suggestion from @egreg, I changed the option from openout_any = a to openout_any = r, which also works successfully in Windows.

Jagath
  • 4,287
  • 3
    I don't think this is good advice; allowing openout_any=a opens big security problems. And it probably wouldn't solve the problem, because it's the OS that prohibits writing files with .bat extension, it seems. – egreg Jul 25 '13 at 13:32
  • I know @egreg. But it is one of the solution to the question. I tried this in Windows machine and it worked! – Jagath Jul 25 '13 at 13:34
  • @egreg: It's not the os, it has to be the latex implementation. After all you can create and edit bat files with other editors. But I agree removing the restictions is bad advice. I think the rename approach sounds rather good (can one test from inside tex if it is running on windows), since running a tex file with shell escapes makes it obvious that one runs into a security risk. However I don't know which security risk is higher letting latex execute shell commands, or generating a bat that first has to be launched by the user (possibly from the pdf as in the example). – ted Jul 25 '13 at 20:23
  • @ted It might be MiKTeX's implementation, but I didn't find any mention. – egreg Jul 25 '13 at 20:33
  • 3
    What is odd here is that doesn't seem to be documented, but certainly does seem to be deliberate! – Joseph Wright Aug 24 '13 at 17:54