Editing files in a Windows Subsystem for Linux development environment












16















Windows Subsystem for Linux (WSL) works pretty well for making most commandline Linux tools available and working on Windows without modification. However, it gets a little tricky for development, when one wants to




  • Build a project using a Linux toolchain that doesn't have a well-supported Windows equivalent (Ruby, Node, etc)

  • Edit files using a Windows-based GUI editor such as Visual Studio code.


The problem is that Windows apps cannot modify files inside the virtual lxss filesystem. Directly modifying these files is known to cause all sorts of issues.



Therefore, there seem to be only two suboptimal choices when it comes to using WSL for development:




  1. Store the project under lxss (/home/foo). The normal toolchain works properly. However, editing is limited to either terminal-based Vim/Emacs or whatever can be run under a janky X server, which is less smooth than native editors running on Windows.


  2. Store the project under the Windows filesystem (/mnt/c/Users/foo). Now any Windows-based editor can be used for development. However, the Linux-based toolchain is fragile as it's not designed to be used on a "network drive", and can cause problems with file watching or databases.



Is there any way to get the best of both worlds here - that is, to be able to edit using a native Windows application, but still have the Linux toolchain work as it normally would on a local drive?










share|improve this question



























    16















    Windows Subsystem for Linux (WSL) works pretty well for making most commandline Linux tools available and working on Windows without modification. However, it gets a little tricky for development, when one wants to




    • Build a project using a Linux toolchain that doesn't have a well-supported Windows equivalent (Ruby, Node, etc)

    • Edit files using a Windows-based GUI editor such as Visual Studio code.


    The problem is that Windows apps cannot modify files inside the virtual lxss filesystem. Directly modifying these files is known to cause all sorts of issues.



    Therefore, there seem to be only two suboptimal choices when it comes to using WSL for development:




    1. Store the project under lxss (/home/foo). The normal toolchain works properly. However, editing is limited to either terminal-based Vim/Emacs or whatever can be run under a janky X server, which is less smooth than native editors running on Windows.


    2. Store the project under the Windows filesystem (/mnt/c/Users/foo). Now any Windows-based editor can be used for development. However, the Linux-based toolchain is fragile as it's not designed to be used on a "network drive", and can cause problems with file watching or databases.



    Is there any way to get the best of both worlds here - that is, to be able to edit using a native Windows application, but still have the Linux toolchain work as it normally would on a local drive?










    share|improve this question

























      16












      16








      16


      7






      Windows Subsystem for Linux (WSL) works pretty well for making most commandline Linux tools available and working on Windows without modification. However, it gets a little tricky for development, when one wants to




      • Build a project using a Linux toolchain that doesn't have a well-supported Windows equivalent (Ruby, Node, etc)

      • Edit files using a Windows-based GUI editor such as Visual Studio code.


      The problem is that Windows apps cannot modify files inside the virtual lxss filesystem. Directly modifying these files is known to cause all sorts of issues.



      Therefore, there seem to be only two suboptimal choices when it comes to using WSL for development:




      1. Store the project under lxss (/home/foo). The normal toolchain works properly. However, editing is limited to either terminal-based Vim/Emacs or whatever can be run under a janky X server, which is less smooth than native editors running on Windows.


      2. Store the project under the Windows filesystem (/mnt/c/Users/foo). Now any Windows-based editor can be used for development. However, the Linux-based toolchain is fragile as it's not designed to be used on a "network drive", and can cause problems with file watching or databases.



      Is there any way to get the best of both worlds here - that is, to be able to edit using a native Windows application, but still have the Linux toolchain work as it normally would on a local drive?










      share|improve this question














      Windows Subsystem for Linux (WSL) works pretty well for making most commandline Linux tools available and working on Windows without modification. However, it gets a little tricky for development, when one wants to




      • Build a project using a Linux toolchain that doesn't have a well-supported Windows equivalent (Ruby, Node, etc)

      • Edit files using a Windows-based GUI editor such as Visual Studio code.


      The problem is that Windows apps cannot modify files inside the virtual lxss filesystem. Directly modifying these files is known to cause all sorts of issues.



      Therefore, there seem to be only two suboptimal choices when it comes to using WSL for development:




      1. Store the project under lxss (/home/foo). The normal toolchain works properly. However, editing is limited to either terminal-based Vim/Emacs or whatever can be run under a janky X server, which is less smooth than native editors running on Windows.


      2. Store the project under the Windows filesystem (/mnt/c/Users/foo). Now any Windows-based editor can be used for development. However, the Linux-based toolchain is fragile as it's not designed to be used on a "network drive", and can cause problems with file watching or databases.



      Is there any way to get the best of both worlds here - that is, to be able to edit using a native Windows application, but still have the Linux toolchain work as it normally would on a local drive?







      linux windows ubuntu windows-10 windows-subsystem-for-linux






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Sep 21 '17 at 9:28









      Andrew MaoAndrew Mao

      5412933




      5412933






















          3 Answers
          3






          active

          oldest

          votes


















          2














          You can open Windows programs from within WSL, but you need to convert file paths if you want to open Windows files with Windows programs from inside WSL. wsltools will do this for you.



          If you open vscode from WSL then it will wait for it to close, so you'll know when it's done with whatever files it was editing. The database problems you mentioned mostly stem from things like inotify not responding to events that would trigger it in Linux. Unfortunately, this isn't implemented in WSL yet so there's no good way for a Linux application to know when some other Windows process closes a file.






          share|improve this answer

































            0














            I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is better way to get the best of both worlds, other than the ones you have mentioned (That I know of).



            I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make more smooth, but it's not there yet.






            share|improve this answer































              0














              In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:




              • In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.

              • Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.


              Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.






              share|improve this answer
























              • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                – Dan M.
                Sep 27 '18 at 11:45











              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "3"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1252400%2fediting-files-in-a-windows-subsystem-for-linux-development-environment%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              3 Answers
              3






              active

              oldest

              votes








              3 Answers
              3






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              2














              You can open Windows programs from within WSL, but you need to convert file paths if you want to open Windows files with Windows programs from inside WSL. wsltools will do this for you.



              If you open vscode from WSL then it will wait for it to close, so you'll know when it's done with whatever files it was editing. The database problems you mentioned mostly stem from things like inotify not responding to events that would trigger it in Linux. Unfortunately, this isn't implemented in WSL yet so there's no good way for a Linux application to know when some other Windows process closes a file.






              share|improve this answer






























                2














                You can open Windows programs from within WSL, but you need to convert file paths if you want to open Windows files with Windows programs from inside WSL. wsltools will do this for you.



                If you open vscode from WSL then it will wait for it to close, so you'll know when it's done with whatever files it was editing. The database problems you mentioned mostly stem from things like inotify not responding to events that would trigger it in Linux. Unfortunately, this isn't implemented in WSL yet so there's no good way for a Linux application to know when some other Windows process closes a file.






                share|improve this answer




























                  2












                  2








                  2







                  You can open Windows programs from within WSL, but you need to convert file paths if you want to open Windows files with Windows programs from inside WSL. wsltools will do this for you.



                  If you open vscode from WSL then it will wait for it to close, so you'll know when it's done with whatever files it was editing. The database problems you mentioned mostly stem from things like inotify not responding to events that would trigger it in Linux. Unfortunately, this isn't implemented in WSL yet so there's no good way for a Linux application to know when some other Windows process closes a file.






                  share|improve this answer















                  You can open Windows programs from within WSL, but you need to convert file paths if you want to open Windows files with Windows programs from inside WSL. wsltools will do this for you.



                  If you open vscode from WSL then it will wait for it to close, so you'll know when it's done with whatever files it was editing. The database problems you mentioned mostly stem from things like inotify not responding to events that would trigger it in Linux. Unfortunately, this isn't implemented in WSL yet so there's no good way for a Linux application to know when some other Windows process closes a file.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 15 at 23:10

























                  answered Apr 6 '18 at 13:21









                  Shane LawrenceShane Lawrence

                  235




                  235

























                      0














                      I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is better way to get the best of both worlds, other than the ones you have mentioned (That I know of).



                      I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make more smooth, but it's not there yet.






                      share|improve this answer




























                        0














                        I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is better way to get the best of both worlds, other than the ones you have mentioned (That I know of).



                        I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make more smooth, but it's not there yet.






                        share|improve this answer


























                          0












                          0








                          0







                          I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is better way to get the best of both worlds, other than the ones you have mentioned (That I know of).



                          I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make more smooth, but it's not there yet.






                          share|improve this answer













                          I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is better way to get the best of both worlds, other than the ones you have mentioned (That I know of).



                          I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make more smooth, but it's not there yet.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Feb 16 '18 at 2:40









                          trueCamelTypetrueCamelType

                          3591517




                          3591517























                              0














                              In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:




                              • In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.

                              • Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.


                              Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.






                              share|improve this answer
























                              • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                                – Dan M.
                                Sep 27 '18 at 11:45
















                              0














                              In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:




                              • In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.

                              • Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.


                              Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.






                              share|improve this answer
























                              • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                                – Dan M.
                                Sep 27 '18 at 11:45














                              0












                              0








                              0







                              In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:




                              • In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.

                              • Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.


                              Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.






                              share|improve this answer













                              In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:




                              • In Insider Build 17063 and later, filesystem improvements allow Linux utilities to see more of what they expect on DrvFs files.

                              • Since late 2017, Visual Studio Code is able to run the WSL version of Node directly.


                              Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Aug 3 '18 at 20:01









                              Andrew MaoAndrew Mao

                              5412933




                              5412933













                              • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                                – Dan M.
                                Sep 27 '18 at 11:45



















                              • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                                – Dan M.
                                Sep 27 '18 at 11:45

















                              Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                              – Dan M.
                              Sep 27 '18 at 11:45





                              Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.

                              – Dan M.
                              Sep 27 '18 at 11:45


















                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Super User!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1252400%2fediting-files-in-a-windows-subsystem-for-linux-development-environment%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Plaza Victoria

                              Puebla de Zaragoza

                              Musa