[LINUX] Adieu l'invite de commande dans WSL, VSCode et Windows Terminal

Je suis revenu à Windows depuis macOS et j'utilisais PowerShell Core parce qu'il disait: "Invite de commandes, au moins PowerShell." En passant, je me suis souvenu qu'il y avait WSL (Windows Subsystem for Linux). J'ai décidé d'utiliser entièrement WSL pour l'environnement de développement, alors prenez note de la procédure.

L'environnement de développement ici fait référence au développement du front-end de l'application Web avec Angular et du back-end avec node.js (et puisque je ne suis pas vraiment familier avec Linux, WSL, distribution et shell Je suis convaincu que c'est confus.)

1. Introduction de WSL

• [Introduction à WSL] Partie 1 Environnement Linux standard Windows 10 Commençons WSL: IT Classroom- @ IT

Présentez WSL en vous référant à.

2. Présentation du terminal Windows

Windows Terminal est un client terminal pour Windows, et bien qu'il soit toujours dans la version Preview, je l'adore car il est facile à utiliser et hautement personnalisable.

• Get Windows Terminal (Preview) -Microsoft Store ja-JP
• Windows Terminal (aperçu) Memo-Qiita

Lorsque vous installez WSL, vous verrez également un profil supplémentaire appelé «Ubuntu» dans votre terminal Windows. Pour que le Terminal Ubuntu soit ouvert par défaut lorsque vous démarrez Windows Terminal, appuyez sur ctrl +, pour ouvrir profiles.json '' et changer defaultProfile ''.

Autre,

• Réglez `` colorScheme '' pour changer la couleur pour la rendre plus facile à voir
• Définissez le répertoire initial avec startingDirectory
• Ajoutez des raccourcis clavier '' pour pouvoir copier et coller avec ctrl + c '' et ctrl + v '' (par défaut ctrl + shift + c / v '')

Change. Windows Terminal est amusant car vous pouvez le personnaliser de différentes manières en éditant ce `` profiles.json ''. Pour référence, je publierai mes paramètres.

profiles.json

{
    "$schema": "https://aka.ms/terminal-profiles-schema",

    "defaultProfile": "{2c4de342-38b7-51cf-b940-2309a097f518}",

    "profiles":
    [
<Omis>
        {
            "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
            "hidden": false,
            "name": "Ubuntu",
            "colorScheme": "Campbell",
            "cursorShape": "emptyBox",
            "acrylicOpacity": 0.85,
            "useAcrylic": true,
            "cursorColor": "#FFFFFF",
            "fontFace": "Cascadia",
            "fontSize": 12,
            "startingDirectory": "C:\\dev",
            "source": "Windows.Terminal.Wsl"
        }
    ],
    "schemes": [
        {
            "name": "Campbell",
            "foreground": "#F2F2F2",
            "background": "#0C0C0C",
            "colors": [
                "#0C0C0C",
                "#C50F1F",
                "#13A10E",
                "#C19C00",
                "#0037DA",
                "#881798",
                "#3A96DD",
                "#CCCCCC",
                "#767676",
                "#E74856",
                "#16C60C",
                "#F9F1A5",
                "#3B78FF",
                "#B4009E",
                "#61D6D6",
                "#F2F2F2"
            ]
        }
<Omis>
    ],

    // Add any keybinding overrides to this array.
    // To unbind a default keybinding, set the command to "unbound"
    "keybindings": [
        { "command": "copy", "keys": [ "ctrl+c" ] },
        { "command": "paste", "keys": [ "ctrl+v" ] }
    ]
}

3. Terminal par défaut VScode vers WSL

Avec l'introduction de WSL, "wsl" a également augmenté dans le Terminal de Visual Studio Code, alors changez-le en "wsl" avec ctrl + shift + p → Terminal: Select default shell.

Il semble que vous puissiez changer le terminal pour chaque espace de travail en spécifiant Terminal dans .code-workspace, mais je ne le recommande pas car il y a certains environnements où wsl n'est pas inclus.

4. Exécution de la tâche VSCode dans WSL

Même si je change le terminal par défaut de VScode en WSL, les tâches de VScode semblent être exécutées du côté Windows, et je veux aussi les exécuter sur WSL. Malheureusement, pour résoudre ce problème, vous devez écrire des "tâches dépendantes de WSL".

./vscode/tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "ng-serve",
      "type": "shell",
      "isBackground": true,
      "command": "ng serve",
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
            "regexp": "^$"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": ".*Angular Live Development Server.*",
          "endsPattern": ".*Compiled successfully.*"
        }
      }
    },
    {
      "label": "ng-serve-wsl",
      "type": "shell",
      "isBackground": true,
      "command": "\"ng serve\"",
      "options": {
        "shell": {
          "executable": "C:\\Windows\\System32\\wsl.exe",
          "args": [ "bash -ic" ]
        }
      },
      "problemMatcher": {
        "owner": "custom",
        "pattern": {
            "regexp": "^$"
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": ".*Angular Live Development Server.*",
          "endsPattern": ".*Compiled successfully.*"
        }
      }
    }
  ]
}

Par exemple, l'exemple tasks.json ci-dessus définit une tâche appelée ng-serve '' pour le débogage d'Angular, mais cela fonctionne sous Windows, donc De plus, il existe une tâche appelée ng-serve-wsl '' avec des paramètres à exécuter sur WSL.

La différence entre la version WSL réside dans les informations de wsl.exe définies dans ʻoptions: {} `, qui est l'invite de commande.

wsl.exe bash -ic "ng serve"

Équivaut à exécuter. L'important est l'argument d'exécution bash -i, sinon .bashrc ne sera pas lu (= PATH n'est pas défini), donc ng entraînera une erreur de commande introuvable. Je vais finir.

5. Créer un environnement de développement côté WSL

Les outils nécessaires au développement tels que git, node, npm, angular, python, aws-cli, firebase-cli, etc. seront placés dans WSL. Pour Ubuntu, il est généralement installé avec apt-get.

Résumé et endroit un peu gênant (redondant)

Je me demandais si je pouvais attendre WSL2, mais c'était très pratique de l'utiliser également avec WSL1.

Terminal et VSCode, qui sont souvent utilisés pendant le développement, peuvent maintenant être dépensés presque sans savoir qu'il s'agit de Windows. Les scripts, etc. sont presque les mêmes que macOS, et il est plus facile de répéter CI fonctionnant sous Linux.

L'interopérabilité avec Windows est plus élevée que ce à quoi je m'attendais, et si j'ajoute .exe à la commande, je peux exécuter la commande Windows à partir de WSL, donc j'ai senti que je pouvais atteindre l'endroit qui démange (à partir de WSL). Vous devriez être en mesure de créer des applications .NET qui ne fonctionnent que sur Windows en appuyant sur `` msbuild.exe '', et bien sûr, vous pouvez vérifier le fonctionnement des programmes .NET qui s'exécutent sur plusieurs plates-formes en plaçant .NET Core du côté WSL en premier lieu. Est possible).

Comme un peu redondant,

les informations d'identification git doivent être stockées dans Win / WSL

Parfois, j'appuie sur la commande git dans bash, parfois j'utilise une application cliente Git (telle que GitKraken ou VSCode), et je sais comment rendre le magasin d'informations d'identification commun. Je ne l'ai pas, donc je le mémorise dans les deux pour le moment.

Conversion d'un chemin Windows en chemin UNIX

Pour "copier le chemin d'accès dans l'Explorateur Windows et" cd "dans bash", vous avez besoin d'une commande similaire à la suivante:

cd $(wslpath -u "C:\dev\hoge")

Vous pouvez convertir une chaîne de chemin Windows en chemin UNIX avec la fonction `` wslpath '', donc je mords ceci et déplace le répertoire.

La plupart des autres membres de l'équipe sont Windows

Par conséquent, si vous devez écrire un script en supposant qu'il fonctionnera dans leur environnement, vous devrez utiliser PowerShell ensemble pour vérifier son fonctionnement, et vous devrez éventuellement installer le nœud du côté Windows également. Eh bien, c'est une situation d'équipe. Néanmoins, Windows Terminal est facile à utiliser car vous pouvez gérer à la fois WSL et PowerShell dans des onglets.

Une autre solution ou un favori

En supposant que VSCode, en utilisant Remote - Extension WSL, tout le développement de projet peut être effectué sur WSL. Vous pourrez le faire. Le terminal décrit ci-dessus et l'exécution de la tâche sont tous.

• Get Started with C++ and Windows Subsystem for Linux in Visual Studio Code
• Developing in the Windows Subsystem for Linux with Visual Studio Code

Actuellement, il s'agit toujours d'une version Preivew, donc la stabilité est incertaine, WSL semble lent (subjectif) car il s'agit d'un site distant, l'extension VS Code doit être installée davantage pour la télécommande en fonction de la chose, etc. J'ai essayé un peu et je l'ai mis en attente car il y a certains points qui m'intéressent.