I have read the question in TeX.SE, but I don't want user to add ^^J manually. That is, I want writer to output content originally.

To be or not to be,
that is % the question

It should output

To be or not to be,
that is % the question

Here's my source code, at the beginning, I use Python to extract the content from the .tex file, then I'm refactoring it in an easier way, use LaTeX to output the code originally, that's the reason why I meet this question.

Sorry about my poor expression :P Thanks a lot!

  • 1
    Why don't you use the filecontents environment? Nov 20, 2018 at 10:15
  • Well, I don't know this environment, I will try after dinner. Thanks a lot :)
    – Iydon
    Nov 20, 2018 at 10:18
  • You seem to wish to have linebreaks at the beginning and at the end of the argument removed instead of having them written to file. What behavior do you wish in case the argument of the \write-command is empty or does contain only a single line-break, i.e., \immediate\write\file{} or \immediate\write\file{<line-break>} ? Nov 21, 2018 at 22:08

2 Answers 2


The LaTeX kernel provides the filecontents environment to write to external files without having to worry about catcodes and such. In older LaTeX releases (prior to 2019-10-01; see here) the filecontents package did minimal changes to this environment allowing it to be used anywhere in the document (LaTeX's version could only be used in the preamble and didn't allow overwriting). In newer releases, this functionality is also included in the LaTeX kernel.

To produce

To be or not to be,
that is % the question

you use:

% \usepackage{filecontents} For older LaTeX releases
To be or not to be,
that is % the question

The starred version (filecontents*) omits the heading that is printed in the standard version of the environment:

%% LaTeX2e file `tmp.txt'
%% generated by the `filecontents' environment
%% from source `test' on 2020/01/12.
To be or not to be,
that is % the question

An addendum on my (admittedly lazy) answer:

Should you want to persist on reinventing the wheel (which is much more fun, I must admit), then you can create a command to take care of the \catcodeing for you. Here I provide an implementation of a \verbwrite command which does the job for you.

The command syntax is somewhat like LaTeX's \verb: you can use either as \verbwrite\file{<stuff>} or \verbwrite\file|<stuff>|. For the latter syntax, any character other than { can be used to delimit the contents. This character, obviously, can't appear in <stuff>. The advantage of the second syntax is that you don't have any restriction in balancing { and } inside the contents of the command.


{\catcode`\ =12
{\global\let\other@sptoken= }%
\gdef\@xifnch@other {\futurelet\@let@token\@ifnch@other}}%
    \let\do\@makeother \dospecials
      {\catcode`\}= 2\relax\verbwrite@brace#1}%

\verbwrite\file {1-To be or not to be,
that is % the question}
\verbwrite*\file {2-To be or not to be,
that is % the question}
\verbwrite\file|3-To be or not to be,
that is } the {question|
\verbwrite\file$4-Être ou ne pas être,
вот в чем вопрос$
\verbwrite\file}5-Être ou ne pas être,
вот в чем вопрос}

Please beware that I took 68 minutes to write this command, so it is certainly not what you can call robust. Proceed with care :)

Fix 1: Prevent expansion of the text using ε-TeX's \unexpanded (thanks to jfbu :)

Fix 2: Prevent premature tokenization of the delimiter (thanks again to jfbu :)

Feature 1: Added a starred version that ignores spaces before the delimiter of the verbatim content.

Fix 3: Actually allow } as a "other" delimiter (\verbwrite\file}stuff}) (thanks to Ulrich Diez :)

Fix 4: Fix misfeature from Feature 1. The effect of the * argument would remain for further calls to \verbwrite once used.

  • Try this with être ou ne pas être. You will need to add \usepackage[T1](fontenc} (assuming pdflatex here). And this will only fix those benign letters, add then a Unicode letter for Cyrillic for example. On the other hand the filecontents* environment does not have that problem...even for быть или не быть
    – user4686
    Nov 20, 2018 at 14:15
  • @jfbu It was creating content! The code has developed consciousness! Thanks for the warning, I hadn't realised that :-) Nov 20, 2018 at 14:28
  • Keep in mind, it could be worse if @egreg was around, and allow me anothe remark: try it with & or $ as delimiters...
    – user4686
    Nov 20, 2018 at 15:45
  • @jfbu Oops, that one was bad. Hopefully fixed now. Thanks :) And yes, egreg would most certainly spot a missing % ;) Nov 20, 2018 at 17:11
  • attention if user leaves a space \verbwrite{\file} & or \verbwrite\file & both fail... (I have been paid to a be a nuisance :))
    – user4686
    Nov 20, 2018 at 17:18

With my explanations below I write (La)TeX in places where I wish to indicate that what is written is valid for "pure" TeX and thus is valid for LaTeX also. I do so for people who are not aware that LaTeX basically is TeX plus a collection of macros that forms the LaTeX-format and that gets loaded automatically when executing latex.exe/the latex-binary.

I suggest using the filecontents*-environment.

Be aware that there is also a LaTeX 2ε-package filecontents which does remove some of the limitations that come along with the filecontents*-environment from the LaTeX 2ε-kernel.

If you are in the mood for reinventing the wheel, you can write a macro which does

  • switch to verbatim-catcode-régime,
  • switch the catcode of the endlinechar (usually ^^M/ASCII-Return) to 12 so that ASCII-return is treated like digits and punctuation-marks,
  • read and tokenize under that catcode-régime the argument containing the text that is to be written to file
  • trim leading and trailing endline-chars from that text
  • write the text to file while having \endlinechar also as \newlinechar.

In (La)TeX there are several stages of processing input.

(La)TeX does read TeX-input, e.g., a .tex-input-file, line by line.

In the pre-processing-stage, the single characters that form the line will be converted to (La)TeX's internal character encoding. (With old-school (La)TeX engines, the internal character-encoding is ASCII. With engines based on XeTeX or LuaTeX, the internal character-encoding is utf-8 whereof ASCII is a subset.) Then all space-characters (code-point-number 32 both in ASCII and in utf-8, i.e., in all encodings that come into question as internal-character encoding of a (La)TeX engine) that occur at the right end of the line will be removed. Then a character will be inserted at the right end of the line whose code-point-number in (La)TeX' internal character-encoding (i.e. ASCII or utf-8) corresponds to the number of the integer-parameter \endlinechar. Usually the value of the integer-parameter \endlinechar is 13 while code-point-number 13 both in ASCII and in utf-8, i.e., in all encodings that come into question as internal-character encoding of a (La)TeX engine, denotes the ⟨RETURN⟩-character. This means: Usually a ⟨RETURN⟩-character gets inserted at the right end of the line.

When this is done, the tokenizing-stage begins: In this stage (La)TeX takes the characters that form the line for instructions for placing tokens into the token-stream. This is the stage when things start to be about so-called tokens, e.g., control-sequence-tokens (which come in two flavors: control-word-tokens and control-symbol-tokens) and character-tokens. Character-tokens consist of character-codes denoting the code-point-number in the (La)TeX' internal character-encoding and category-codes. Category-codes make it possible for characters to have special meanings for the (La)TeX-engine. E.g., the category-code of the backslash-character usually is 0(escape). A character whose category-code is 0 at tokenizing-time causes (La)TeX to gather the name of a control-sequence-token and afterwards place that control-sequence-token into the token-stream. E.g., the category-code of the opening curly brace usually is 1(begin grouping) and the category-code of the closing curly brace usually is 2(end grouping) while character-tokens of category-code 1(begin grouping) are to be used for introducing groups (i.e., macro arguments consisting of several tokens or local-scopes for assignments like macro-definitions or the ⟨balanced text⟩ with things like \scantokens) and character-tokens of category-code 2(end grouping) are to be used for denoting what does not belong to the group in question any more. More information about category-codes can be found at https://en.wikibooks.org/wiki/TeX/catcode.

After tokenizing, there is a "stream of tokens". Processing the stream of tokens includes things like expansion of expandable tokens (e.g., macro-tokens, e.g., expandable primitives like \string or \csname...\endcsname) and (later) carrying out assignments, creating boxes etc.

When reading and tokenizing a .tex-input-file, (La)TeX will— during the pre-processing-stage— remove spaces at every line-ending and insert an endline-character at every line-ending.

Therefore the input-sequence

To be or not to be,
that is % the question

will by (La)TeX at tokenizing-time, i.e., after pre-processing, be treated as

\immediate\write\file{⟨character due to endline-char-insertion⟩
To be or not to be,⟨character due to endline-char-insertion⟩
that is % the question⟨character due to endline-char-insertion⟩
}⟨character due to endline-char-insertion⟩

Usually the endline-character is ^^M, i.e., ⟨RETURN⟩.

Thus the above input-sequence usually will by (La)TeX at tokenizing-time be treated as

To be or not to be,⟨^^M/RETURN-character⟩
that is % the question⟨^^M/RETURN-character⟩

(The answer to the question which tokens (La)TeX will insert into the token-stream when encountering a ⟨^^M/RETURN-character⟩ depends on the category-code which at the time of tokenizing is assigned to the ⟨^^M/RETURN-character⟩.

Usually the category-code of the ⟨^^M/RETURN-character⟩ is 5 (end of line) which means that depending on the state of (La)TeX' reading apparatus either (in state S=skipping blanks) no token at all or (in state M=in the middle of a line) a space-token(=a character-token of category-code 10(space) and character-code 32 (32 is the number of the space-character in (La)TeX' internal character-encoding) or (in state N=about to begin new line) a \par-token will be inserted.

In case category code 12(other) is assigned to the ⟨^^M/RETURN-character⟩, (La)TeX will insert a character-token of category-code 12(other) and character-code 13 (13 is the number of the ⟨RETURN-character⟩, in (La)TeX' internal character-encoding) into the token-stream. Such a token can be processed as any other character token.)

Besides this, (La)TeX will—at writing-time—in any case attach at the end of the argument of a \write-command that sequence of characters/bytes that on the platform in use serves for ending lines within plain text files.

Thus—assuming that we managed to have LaTeX accept the percent-char as an ordinary character—the \write-command will get something like:

⟨token due to ^^M/RETURN-character⟩To be or not to be,⟨token due to ^^M/RETURN-character⟩that is % the question⟨token due to ^^M/RETURN-character⟩

Att writing-time, a

⟨platform-dependent sequence for ending the line⟩
will be attached.

If the category code of the endline-character/of the ⟨^^M/RETURN-character⟩ was 5(end of line) at the time of tokenizing the input, the sequence

⟨space⟩To be or not to be,⟨space⟩that is % the question⟨space⟩⟨platform-dependent sequence for ending the line⟩
will be written to the external file.

If the category code of the endline-character/of the ⟨^^M/RETURN-character⟩ was 12(return) at the time of tokenizing the input, the sequence

^^MTo be or not to be,^^Mthat is % the question^^M⟨platform-dependent sequence for ending the line⟩
will be written to the external file.

You can ensure that at writing-time a ⟨^^M/RETURN-character⟩ also yields the ⟨platform-dependent sequence for ending the line⟩ by assigning the integer-parameter \newlinechar the value of the integer-parameter \endlinechar.

If you do this also, the sequence

⟨platform-dependent sequence for ending the line⟩To be or not to be,⟨platform-dependent sequence for ending the line⟩that is % the question⟨platform-dependent sequence for ending the line⟩⟨platform-dependent sequence for ending the line⟩

will be written to the external file.

But this way you might get undesired empty lines.

Therefore you may wish to apply a routine for removing leading and trailing ⟨characters due to endline-char-insertion⟩ from the entire argument before letting \write do the writing-job.

A coding-example could look like this:



  \newcommand*\gobbleendl{}\def\gobbleendl ^^M{}%

  \catcode`\ =10 %We don't want to allow space as verb-arg-delimiter.
                 %Thus let's remove spaces when grabbing undelimited arguments.
  %\catcode`\endlinechar=5 %
\catcode`\(=1 %
\catcode`\{=12 %
    \catcode`\ =12\relax
    \catcode\endlinechar=12 %
      \catcode`\{=1 %
      \catcode`\}=2 %



être ou ne pas être.
That is % the question.
D\immediateverbatimwrite{\file}  |
}être ou ne pas être.
That is % the question.



With this example you get

  • a pdf-file with the sequence ABCDEF. (This shows that no spurious spaces/whatsoever characters get introduced/inserted.)
  • a text-file whose name is tmp.txt and whose content is:
    être ou ne pas être.⟨linebreak⟩
    That is % the question.⟨linebreak⟩
    }être ou ne pas être.⟨linebreak⟩
    That is % the question.⟨linebreak⟩
    Due to the linebreaks, editors which also show line-numbers might display that file as
    1 être ou ne pas être.
    2 That is % the question.
    3 }être ou ne pas être.
    4 That is % the question.

By the way: With (La)TeX it is not possible to keep spaces at the ends of lines.

The reason is that (La)TeX does read and tokenize input line by line and one of the first things it does (in the pre-processing-stage) to every line of input (even before adding the endline-character and starting tokenizing the line) is removing all spaces that occur at the ends of lines.

Thus (La)TeX input like

more code⟨space⟩⟨space⟩⟨space⟩⟨space⟩⟨space⟩
even more code⟨space⟩⟨space⟩

will in any case be pre-processed to

code⟨character due to endline-char-insertion⟩more code⟨character due to endline-char-insertion⟩even more code⟨character due to endline-char-insertion⟩

before any further processing/tokenization etc takes place.

  • The line breaks in the written file disappear when I put \immediateverbatimwrite into another macro. Is there a possibility to fix this? Jan 12, 2020 at 17:24
  • @user125730 I suppose the linebreaks do not come into being at all because the second arg of \immediateverbatimwrite is passed to \immediateverbatimwrite by that other macro. The problem with this is: \immediateverbatimwrite needs to have LaTeX read and tokenize its second arg from the TeX-input-file rather than having it passed from another macro. Reason: Changes to the catcode-régime done temporarily by \immediateverbatimwrite affect how that second arg will be read and tokenized. But these changes do not apply when the arg is not read and tokenized but passed by another macro. Jan 14, 2020 at 23:02
  • I don't understand why do you writing (La)TeX when you are describing pure TeX features. This is confusing for many people.
    – wipet
    May 6, 2020 at 17:13
  • @wipet I do so in order to make clear for readers who program in LaTeX that these features apply both to pure TeX and to LaTeX. This way they know that what is written applies to LaTeX/what they use, too. EOD. May 6, 2020 at 17:24
  • First: TeX experts like you are using ambiguous (La)TeX phrase and second: documents about TeX like this: tex.stackexchange.com/questions/110133 are created. Note: pdfLaTeX version 3.1415926 :)
    – wipet
    May 7, 2020 at 5:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .