Apply files.eol setting when saving untitled with a specific mode that has this setting configured

[gojimmypi]

This is a feature request to save Linux files with linefeed only and not carriage return.

Visual Studio Code on Windows 10
Version 1.12.1
Commit f6868fc
Date 2017-05-04T21:26:50.689Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

Steps to Reproduce:

1. Map a windows drive to a Linux machine (e.g. one sharing drives via samba)
2. Open VSCode on Windows
3. Create a shell script like this:

#!/bin/bash
echo "Hello World!"

4. save the file to the Linux machine: myhello.sh
5. login to Linux machine, chmod +x the file, and try to run it.
6. observe error:

-bash: ./myhello.sh: /bin/bash^M: bad interpreter: No such file or directory

the problem could be resolved as described here:

https://askubuntu.com/questions/304999/not-able-to-execute-a-sh-file-bin-bashm-bad-interpreter

however VSCode is aware that it is a bash shell script, yet even this setting does not resolve the problem:

"[shellscript]": {
    "files.eol": "\n",
}

It would be great to have VSCode be able to save Linux files with the appropriate linefeed (only), as desired.

edit: spelling

[Tyriar]

@alexandrudima @bpasero any idea why saving using "files.eol": "\n" on Windows then trying to run it on Linux via a mapped drive would complain about line endings?

[gojimmypi]

It appears the "files.eol" may not be implemented for this file type. This first screen snip shows VSCode recognizing that it is a "Shell Script (Bash)" file (lower right):

Clicking on "Shell Script (Bash)" then select "Configure 'Shell Script (Bash)' language based settings..." to view JSON config (including the line I added, the default is "files.eol": "\r\n", ) :

{
    "[cpp]": {
        "editor.quickSuggestions": false
    },
    "[c]": {
        "editor.quickSuggestions": false
    },
    "[shellscript]": {
         "files.eol": "\n"
    }
}

But when attempting to add the "files.eol" the hover text for the error is "Unknown Identifier. Use Language Identifiers". So I suspect the setting is simply quietly ignored and files are saved with CF and LF as is normal in Windows. Perhaps I am not using it correctly?

(btw - the two outstanding updating that are pending are unrelated: for Arduino and Python):

[Tyriar]

@gojimmypi maybe there's an issue with using that setting on the language settings? What if you manually hit the CRLF button and set it to LF in the status bar?

[gojimmypi]

@Tyriar clicking on the "Shell Script (bash)" on the bottom bar, and then selecting "Configure 'Shell Script (bash)' language based settings.." seems to create a second settings.json file, inserting a comma after the last setting, but not much different. (I would have expected it to open / change focus to the existing settings.json). There does seem to be an issue with the "files.eol": "\n" setting.

Indeed manually setting the CRLF to LF in the status bar does work; the script runs in linux with no complaint about the extra CR. Perhaps an acceptable temporary workaround; but it would be great if that setting was always honored in .sh files when configured in the settings.json file.

It is cool that toggling the LF/CRLF converts all existing chars, not just the newly entered ones. :)

[alexdima]

@Tyriar

It depends on the user steps taken:

• if a new untitled file is opened => it has no language associated to it => it uses files.eol which in this case most likely defaults to \r\n unless there is a specific workspace/user setting.

• if this untitled file is edited to insert a new line, the inserted new line will be \r\n

• if this untitled file is saved as run.sh, the file is saved with \r\n line endings (i.e. as presented in the bottom right status bar)

• if the file is later opened, and it contains \r\n line endings, it will be opened with \r\n line endings.

• the setting files.eol is respected when the file being opened is ambiguous i.e. has equal number of \r\n line endings and \n line endings or when it has no line endings.

[gojimmypi]

@Tyriar @alexandrudima

For bulleted item 1 above: I do not believe the files.eol setting is respected for new files for me with my settings.json file. AD domain account user, saved in:

C:\Users\[user].[domain]\AppData\Roaming\Code\User

Here's my existing settings.json

{
    "[cpp]": {
        "editor.quickSuggestions": false
    },
    "[c]": {
        "editor.quickSuggestions": false
    },
    "[shellscript]": {
         "files.eol": "\n"
    }
}

At launch time, VSCode starts with UTF-8, CRLF. If I "Save As" and select "Shell Script"... then type in a name... the CRLF setting remains.

Indeed if I open a file saved where the setting was LF, VSCode properly opens the file in LF mode, and not CRLF.

[alexdima]

Today, the setting files.eol is read only on buffer creation. When creating a new file, it does not have a language associated with it, therefore the indication for shellscript to use \n is not respected. IMHO this is ok, as the file is untitled and unknown.

In this case, the buffer gets created with the "global" eol, i.e. the one which is not language specific, which on Windows out of the box is \r\n.

When the untitled file gets saved with a file ending that indicates shellscript, we no longer look at the files.eol language specific setting to convert the buffer from \r\n to \n.

This is opposed to a new file being created in the explorer, e.g. newfile.sh, when it is opened it will immediately be known to be shellscript and the eol will be picked up as \n.

It would be nice for the first case (untitled file being saved) to do something about the setting, perhaps prompt and explain the discrepancy or offer to convert the eol, etc.

Adding @bpasero

[bpasero]

This should actually work because when saving the untitled file we create a new model with the proper resource of the target. However #39051 is the actual problem, you cannot set files.eol as a language specific setting. Closing as duplicate.

[bpasero]

I was wrong, there would still be some conversion needed to apply the EOL when saving.

[bpasero]

@aeschli my understanding is that you are working on this too

[aeschli]

Fixed by #82101.
To verify:

• Set preferred eol to \r\n
• create untitled file
• save as foo.sh
• observe in status bar that eol is now \n

Note: We only change the EOL if the file has no newlines yet