# filecontents* cannot write to file in Windows

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?

-
Could it be the @ in the batch file? I can reproduce the error with MiKTeX 2.9, TeXnicCenter, Windows. –  Kurt Jul 25 '13 at 12:37
I have no problem on my system. –  egreg Jul 25 '13 at 12:38
No problem on my Mac. –  Jubobs Jul 25 '13 at 12:49
Same problem with system file extensions like .com, .dll, etc too in Windows! –  Jagath AR Jul 25 '13 at 12:53
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

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.

-
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 AR 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
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