I’d like to use heredocs to populate config files: e.g. something like:
cat > file << EOF
foo
bar
EOF
However something in travis adds two space in front of commands, that’s visible from a simple script I made, sed replaces the first character on each line:
- |
sed 's/./x/' << EOF
first line
second line
EOF
However the first character is somewhere else:
This is very annoying bug, which prevents me from using multiline literals
As curious as it sounds, I confirmed this to be the case. We are adding indentations (with white spaces) in certain parts of the build script we compile, and commands sensitive to such modifications are affected.
For complex use cases such as this (and when you have many commands in a build phase), I encourage you to write a script to handle them instead.
Is this extra indentation necessary? I guess it’s handy for eye-checking the generated script, but bash doesn’t care, right?
This is really surprising behaviour. I’ve hit this yesterday. At first I suspected my (lack of) understanding of YAML block literals, then Travis’ YAML parser, but it was always two spaces regardless of the indent in YAML, so it couldn’t be the parser guessing the indent incorrectly.
I think this could be fixed, if the extra indent is to be retained, by indenting the command-line as it comes from to_bash as a whole; instead of splitting it on newlines, indenting each one and joining them back together.