MySQL Bugs: #70147: SQL Editor in Workbench saves files without EOL character on final line

Bug #70147	SQL Editor in Workbench saves files without EOL character on final line
Submitted:	26 Aug 2013 10:25	Modified:	11 Oct 2013 8:59
Reporter:	Paul Keenan	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Workbench	Severity:	S3 (Non-critical)
Version:	6.0.6	OS:	Windows (Windows 7 Professional)
Assigned to:		CPU Architecture:	Any

Description:
When saving a SQL file from the SQL Editor inside MySQL Workbench, it properly adds an EOL (end-of-line) character to all of the lines except the final one.

This can be a pain when using certain unix tools, since an EOL character is generally expected after the end of every line.

How to repeat:
Open Workbench & connect
Click the new SQL file icon
Type in a few lines of text
Save the file
View in file editor

e.g. in Vim, a warning is displayed that the final line is missing the EOL character.

Suggested fix:
Add the EOL character to the final line when saving a SQL file.

Thank you for the bug report. What does show VIM for a file *.sql created by a native Windows application like Notepad for me the same as WorkBench. I think there is no bug here but if you want to convert to Feature Request to add an option to save the file in Unix way? . Thanks.

Thanks for the prompt reply.

MySQL Workbench already saves file with unix-style line terminators. :)

If I put the following into a new SQL file in Workbench and save it

1
2
3

then the resulting file when opened with a hex editor (I used HxD) shows the contents as :

31 0A 32 0A 33

The "1" and "2" are followed by the unix-style terminator 0A, but the "3" is not.

I was expecting

31 0A 32 0A 33 0A

So I believe the bug is correct as described.

If you were to change the behaviour so that the Windows-style CRLF (0D 0A) terminators are used, then this would also cause me problems.  In that case, I would definitely appreciate an option in the preferences to change this behaviour to use the unix style terminators.  I develop under Windows but our production server is unix.  If you leave the terminators as unix-style, I'm already happy. :)

FYI, Windows Notepad creates the file as

31 0D 0A 32 0D 0A 33

Thank you for the feedback Please read the article below which its 2nd paragraph says:

"On unix, every line in a file has an End-Of-Line (EOL) character and the EOF character is after the last line. On windows, each line has an EOL characters except the last line......"

http://courses.washington.edu/css342/zander/Notes/eof.html

Thanks.

I read the article and agree with everything it says. :)

MySQL Workbench produces files which conform to neither guideline.  It uses the unix convention for the EOL (i.e. 0A as a terminator) but the Windows convention for the end-of-file (i.e. no EOL on the last line).

I believe it should either use Windows convention for both, or unix convention for both, and so the bug is valid.

If you were to fix it so that it uses Windows convention for both, I can raise a separate feature request to make the choice of unix or Windows style user-configurable.

Thank you for the feedback. Verified as feature request to have an option in Preferences to save file in Unix format. Thanks.

If you want a EOL at the last line, you need to press Return after the last line.

Thanks for the workaround Alfredo.

Posted by developer:
 
There's no such thing like a guideline for trailing line breaks in a text file on either platform. A file contains what you type and it would be a nightmare if editors would start to add content automatically (unless you explicitly tell it to do so). As already said: if you want a trailing line break add one.

Hi Mike,

I'd be grateful if you could do a bit more research.

Every unix text editor and every unix utility since the very first days creates text files where every line, including the last one, ends in a newline character 0A. This is because the output from one command, or file, or socket, or ... is frequently piped into another command, and the next chain in the pipeline needs to know when the end of a line has been reached.

If you need reassurance that this is the case, and the expected behaviour for any unix tool including text editors, then you can try either of the following on a unix machine. Doesn't matter which flavour.

(1) Create a text file using the standard text editor vi (or any other one) containing 1 2 3 on separate lines. Save it and look at the resulting file in a hex editor. You will see 31 0A 32 0A 33 0A.

(2) Create a directory containing the files 1, 2, and 3. Use the command "ls >file-listing.txt". Have a look at the file-listing.txt file in a hex editor. You'll see the same result as above.

This bug report is now a feature request, which is debatable but I don't care about that too much. It asks you for an option to produce output in MS-DOS style files, which Workbench is supposed to do currently gets wrong because it uses the wrong line terminator, and unix-style files, which it accidently gets right because of the previous error but only when you use the workaround of adding an extra line which shouldn't need to be there.

I'm hoping you can quickly change this back from "Won't fix" to something more appropriate. Please advise.

Regards,
Paul