Unable to edit .bash_profile or .bashrc with text editor

[Gingernaut]

When I try to edit my .bash_profile or .bashrc file in Sublime (or any other text editor), it fails to reload the file when I open up bash and won't show up in an 'ls -la'. Currently I can only edit them in nano or vim, and as reported elsewhere I'm having issues with nano or vim scrolling though a file, where the window will re-size and I cannot view the full file, it will cut off my ability to go below a certain point in the file.

[Gingernaut]

Scrolling issue is only in nano not vim. Original problem still applies.

[abyx01]

As a general rule you shouldn't edit Linux Subsystem files with a Windows native text editors. If you do, remember to set newline mode to LF, not CRLF.

[filipeaguiar]

If you can't use windows tools to modify files inside the WSL that makes the whole thing kind of useless.

As a developer I want to use an native editor, like Atom, to edit my files and run the code using the linux tools. I don't want to use a VM for this and I certainly don't want to use vim.

[roboticlemon]

@filipeaguiar You can definitely use windows tools to modify the files, as abyx noted though just make sure your newlines etc are right 💯

[filipeaguiar]

I used Atom with the correct kind ending and the file was inaccessible too.

[KayLeung]

I found the same problem. all files inside Local\lxss\root will be not accessible anymore if you edit with Windows tools (eg. VSCode)

[russalex]

Things here can get awkward quickly. Hopefully I can clear up a little bit here. Unfortunately the story won't be terribly pretty, but it should hopefully make things more deterministic.

Before going more, let's get a term down. For this I will reference files in VolFs. VolFs is our filesystem that covers everything not under /mnt/. Our dev lead Deepu has a great blog here which dives a bit more into it. We'll give more details in future blog posts.

VolFs is what knows about Linux filesystem support including attributes. The issue comes in when a user edits / modifies a file in Windows that is normally controlled by VolFs. The confusion is further compounded if there is a Bash session up and running and what app you use to edit the file.

Long story short:

• If Bash is not running: editing a file in most editors will cause the file to disappear from Bash. This is due to some extended data being stripped off by the application on file save (or so I believe right now). I hate to say this, but the only editor I have been able to use reliably is notepad.
• If Bash is running: editing the file will show the changes to the file in your current session. This is due to caching on VolFs's side. When you exit Bash and come back in the file will be missing.
• Creating or deleting directories on VolFs have the same issues. You can get yourself into odd states this way.

We are aware that this is an issue. While editing files on DrvFs (everything under /mnt/) works well it does not help for things that naturally appear in your home directory. I am now in the habit of moving items from VolFs to DrvFs to edit and back, but that does lose the file attributes. A chmod is in order after.

While this is something we know about, it never hurts to vote on things on our User Voice page. It's a great place to show us that many people are having similar issues.

[hparadiz]

After reading up on this I understand why this a problem. I will specifically quote the post written up by Deepu.

VolFs
VolFs is a file system that provides full support for Linux file system features, including:

Linux permissions that can be modified through operations such as chmod and chroot
Symbolic links to other files
File names with characters that are not normally legal in Windows file names
Case sensitivity
Directories containing the Linux system, application files (/etc, /bin, /usr, etc.), and users Linux home folder, all use VolFs.

Interoperability between Windows applications and files in VolFs is not supported.

I have to say that this goes against the spirit of Bash for Windows in my opinion.

The files exist in the folder as NTFS legal files. How the devs get away with Windows file names that are not legal and case sensitivity while saving them to NTFS is beyond me but I believe that if a file shows up in the lxss directory VolFs should take it (and fix the linux attributes or give defaults if none exist).

If the directory isn't meant to be edited from Windows you may as well drop the pretense and make a virtual hard disk for the root path instead of needlessly putting so much work into VoIFs.

[olinbg]

Figuring out how to prevent this might be a start. I agree with others though - this capability is one of the reasons I'm drawn to Bash for Windows.

For now, I'll look to store most things on C.

[pvginkel]

At least doing something with /home/user would make sense. Would it be an option to symlink that to %USERPROFILE%?

[benhillis]

Closing this out as a duplicate of #45. The recommendation is to work out of /mnt/* directories if you'll be modifying files from Windows and WSL.

[Elijen]

@benhillis This unfortunately is not a great solution either because of problems with file permissions.

[LarryMarzanJr]

question:
can i still include external sources from .bashrc ?
In this case I have my own custom aliases to include, like:
. /path/to/my/custom/aliases/file

[aseering]

Yes, that is supported. The syntax and semantics are the same as with regular Ubuntu Linux (or most other Linux distributions).

[aderusha]

This behavior renders a lot of the subsystem pointless, and (as mentioned earlier) it'd make more sense to create a VHDX or similar and just use that. Exposing the filesystem to the user, knowing full well that if any windows tool actually touches those files that they'll be deleted from the environment is the closest thing you can get to data-destructive behavior you could get short of just deleting the file outright.

[fragtion]

Probably worth noting that this issue is closely related to issue #449 as both pertain to the sensitiveness of this underlying lxss filesystem from outside of the linux environment