Fix Background Jobs in *nix and Windows - #1972

Is there a policy about missing EOL at EOF?

Personally, as someone who uses hg and git (and Linux), missing EOL markers at EOF result in lots of pain which I'd rather avoid.

I haven't seen a strong argument for requiring EOL at EOF, and it comes up often enough to be somewhat annoying and distracting.

If it's truly a problem for some tools, I think we should just run a tool over our source from time to time and fix it instead of asking each contributor every time we see it.

I'm not sure where to start.

The length of a file "" and the length of a file "\n" aren't the same.
Version control systems at some point rely on hashing content and ensuring that they're reproducible.

diff and patch work on lines (things that end in "\n"). A patch generated for a properly ended line doesn't apply well to an improperly ended line and vice versa. This makes it hard to graft and merge changes.

Other things like wc (word count tool which also does line count) can be implemented by counting \ns, a file "hello\n" can be defined to have 1 line because it has 1 \n.

Many text editors as a courtesy to other tools (like diff and vcs and ...) will automatically insert the EOL at EOF.

There's a general goal in VCS for commits to have descriptions that describe the entirety of their changes, and for blame to be assignable based on the last user to change a given line.

These factors result in a file like:
"hello.....\n......\nworld" which was created by one person but, where I change "hello" to "Hello" with a message of "capitalizing Hello" also resulting in my commit often changing the file to:
"Hello.....\n......\nworld\n"

And when someone uses a tool to quickly view the blame for lines of the file, they'll think that I was responsible for "world\n".

If you've ever had problems trying to apply changes where a patch was \r\n and a file was \n, or where a file had mixed line endings, the missing EOL at EOF triggers roughly similar failures.

Trying to apply a change that's missing a line ending to a line that has a line ending:

$ cat c; d -c 4; d -c 4|patch c
Hello
world
a
diff --git a/c b/c
--- a/c
+++ b/c
@@ -1,3 +1,3 @@
 Hello
 world
-a
\ No newline at end of file
+b
\ No newline at end of file
patching file c
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file c.rej

Trying to apply a change with a line ending to a line that is missing a line ending:

 (cat c; echo XXX); d -r 1 -r 2; d -r 1 -r 2|patch c
Hello
world
aXXX
diff --git a/c b/c
--- a/c
+++ b/c
@@ -1,3 +1,3 @@
 Hello
 world
-a
+b
patching file c
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file c.rej

Converting the repository to not be missing line endings would be appreciated.
But I would still encourage you to also discourage people from adding files that are missing EOL at EOF because unless your script automatically commits the line changes as the user who added the line, you'll be distorting authorship for those lines.

should it be else?

This line should be in a BeforeAll block.

Also, I think the job should be removed in a AfterAll block.

5 seconds might not be enough time to wait on a heavily loaded system, especially with debug binaries that aren't pre-jit compiled.

What is a good timeout that you suggest?

I haven't seen a strong argument for requiring EOL at EOF, and it comes up often enough to be somewhat annoying and distracting.

If it's truly a problem for some tools, I think we should just run a tool over our source from time to time and fix it instead of asking each contributor every time we see it.