Your whitespaces are trimmed. This is a problem if you need the exact string e.g. for a string-compare.
The cause of this behaviour is the internal shell variable $IFS (Internal Field Separator), that defaults to whitespace, tab and newline.
Thus the variable $VAR1, when passed over to “echo”, is not seen as one single string but as a bunch of strings separated by whitespaces:

One of our departments makes extensive use of including templates in wiki-articles. They have one article with 56 KB in size that hosts some larger tables. And every row of that tables includes at least one template. There is a total of 24 different templates in use in the article.

At the top of that not flawless loading page we now see this:

"Kategorie:Seiten, in denen die maximale Größe eingebundener Vorlagen überschritten ist"
or in english: "Category:Pages where template include size is exceeded"

Examining the HTML-source of the page shows now and then this warning:

As you can see, the “post-expand include size” hit the upper limit of 2048 KB. Remember: The core-text of the article was only 56 KB in size. But as stated here, every parsing of (almost) every template adds the size of that template to the total-size of the article-page while preprocessing the page.

A proper way would be to split the article into smaller subpages and link them together in a main-page. But department was under time pressure and urged me to rise the limit.

Unfortunately I found no parameter to be set in the LocalSettings.php to increase the “post-expand include size”. But running through the MediaWiki-parameters-page and scanning every one with a “Max” in it’s name, I came across the “$wgMaxArticleSize” whose default-value coincidentally equaled the 2048 KB of the “Post-expand include size”-limit. And hence all summed up template- and article-code actually makes up the “ArticleSize”, I gave it a try and set “$wgMaxArticleSize = 4096” in the LocalSettings.

According to “Google” there really doesn’t seem to be a special-parameter for “Post-expand include size” but as my new limits now again equal the $wgMaxArticleSize, it seems as this is the way to do it. At least it works…