[Journal de tir de sachets de thé]Utilisation de WSL pour exécuter le fil d'exécution Github Copliot CLI-Dark

Après Open AI Codex CLI et Colude Code, Github n'a pas montré de faiblesse et a également lancé sa propre version CLI du client de développement de programmes auxiliaires AI – Github Copilot CLI. VSCode et Visual Studio ont déjà le mode Copilot Agent, pourquoi devons-nous créer une version CLI ? Si vous écrivez trop de programmes, vous préférerez souvent le clavier à la souris. Vive la CLI… (Tous ceux qui comprennent comprennent)

Découpe Laser Bois Banner | R3V Laser

Copilot CLI prend en charge Linux, macOS, WSL et prend également en charge Windows PowerShell, mais il est encore expérimental. La CLI doit souvent appeler des commandes pour faire fonctionner les fichiers et accéder aux ressources. Les commandes sont différentes selon les environnements Shell. Indépendamment de ChatGPT, Claude ou Gemini, vous serez toujours plus familier avec Linux bash que PowerShell. Par conséquent, bien que Copilot CLI prenne également en charge PowerShell, ceux qui sont au courant savent que choisir WSL est le seul moyen d'obtenir une expérience de classe affaires. (La partie inférieure de l'écran d'ouverture est également désinfectée, indiquant que la version PowerShell est de nature expérimentale. Si les choses ne se passent toujours pas bien, vous pouvez envisager d'utiliser WSL à la place.)

Coplit CLI utilise le modèle Claude Sonnet par défaut (peut être modifié en GPT-5), et la méthode de facturation consiste à envoyer une invite et à déduire un point (lecture complémentaire : Comment choisir le modèle pour utiliser Github Copilot ? Méthodes de facturation et scénarios adaptés (version 202508)). Il me reste beaucoup de crédit en septembre, je vais donc l'utiliser pour jouer à Copilot CLI avant la réinitialisation en octobre.

Mon expérience avec WSL est limitée. C'était la première fois que je l'utilisais de manière intensive et j'ai rencontré des problèmes. Commençons par la conclusion : la version Linux est très importante !

À partir du moment où j'ai commencé à l'utiliser, j'ai passé des heures à surmonter toutes les difficultés et j'étais tellement en colère que j'avais envie de maudire.

Le premier est le problème de la sauvegarde de l’identité de connexion :

utiliser /login Après m'être connecté à mon compte Github, Copilot CLI m'a demandé si j'acceptais de stocker le jeton en code brut car il n'y avait pas de sécurité pour les données confidentielles. Je sais que beaucoup de gens accepteront instantanément cette situation, et cela n'affectera pas du tout l'utilisation…

Cependant, je suis un homme sexy qui peut vérifier les adresses MAC et IP des téléphones portables et des tablettes à la maison. Stocker le jeton en texte brut est comme un mur invisible atteignant le plafond. Je n'arrive pas à passer…

Après recherches, il a été constaté que Copilot CLI suit la pratique de Github CLI. Si des mécanismes de sécurité tels que Keyring ne sont pas utilisés, oauth_token existera en code brut. /.config/gh/hosts.yml. S'il est correctement configuré, vous pouvez utiliser un service tel que gnome-keyring pour stocker les données d'authentification. Mais le problème est que gnome-keyring est un logiciel de bureau. Il doit être ajusté pour pouvoir être utilisé en WSL. Quoi qu'il en soit, j'ai échoué et j'ai abandonné. Prenez une autre voie et utilisez d'abord la version Windows de Github CLI gh auth login Une fois la connexion terminée, il peut être utilisé du côté WLS. export GITHUB_TOKEN=$("/mnt/c/Program Files/GitHub CLI/gh.exe" auth token) Enregistrez-le en tant que variable d'environnement et respectez oauth_token.
Après avoir défini la variable d'environnement GITHUB_TOKEN, Copilot CLI se connectera directement en utilisant cette identité :

Mais ensuite, j'ai rencontré des erreurs étranges les unes après les autres lorsque Copilot CLI exécutait des commandes bash telles que ls et sed. Plus j’y pensais, plus c’était faux. Je ne devrais pas être le seul à rencontrer ces problèmes, n'est-ce pas ? Si Copilot CLI avait eu autant de problèmes, il aurait été critiqué depuis longtemps, non ?

Je me suis souvenu que lorsque je vérifiais gnome-keyring, quelqu'un avait mentionné qu'il était normal de passer à Ubuntu 22.04. Je suis retourné vérifier ma version WSL et j'ai découvert que le système d'exploitation que j'avais choisi lors de l'installation il y a quelques années était en fait Ubuntu 20.04. Condamner!

Après avoir réinstallé de manière décisive Ubuntu 22.04, tout s'est bien passé. /login affiche automatiquement l'interface de gestion du trousseau de clés GNOME. C'est la merveilleuse expérience opérationnelle que WSL devrait avoir~~

Leçons apprises, lors de l'utilisation de WSL, pensez à choisir la version grand public mais pas trop nouvelle (j'ai vu certaines personnes signaler avoir rencontré des problèmes le 24.04), pour ne pas vous blottir dans un coin et chanter les louanges de l'or.

[Projection supplémentaire sur la même scène]

Une autre astuce que j'ai apprise au cours du processus de vérification des problèmes consiste à partager git-credential-manager.exe dans WSL.

Oui, vous avez bien lu, vous pouvez également exécuter des fichiers exécutables Windows dans WSL, tout comme le bureau Windows peut exécuter le gestionnaire de fichiers de Linux. Il s'agit de ce que l'on appelle WSL Interop (mécanisme d'interaction Windows/Linux). WSL enregistre la règle binfmt_misc côté Linux pour les fichiers exécutables Windows (MZ/PE). Lorsque .exe est détecté, la demande d'exécution est déléguée à CreateProcess de Windows et à d'autres mécanismes via le programme de pont init/interop de WSL. Le programme Windows démarré est exécuté en tant qu'utilisateur Windows actuel et communique avec WSL. Les processus partagent le pipeline d'entrée et de sortie standard, de sorte que les pipelines, les redirections et l'exécution en arrière-plan peuvent être effectués dans WSL, et le comportement est similaire aux instructions Linux natives. se référer à
Le document officiel contient des instructions de configuration d'administrateur certifié Git. git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe" C'est ça. Plus tard, lorsque git clone/pull/push la bibliothèque privée, vous pourrez partager les paramètres d'authentification Git de l'environnement Windows.

Source link

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Panier
Retour en haut
découpe laser pub