Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Comment se débarrasser d'un dossier « WindowsPowerShell » dans mon dossier « Documents »

ayi

J’ai récemment remarqué un dossier <code>WindowsPowerShell</code> dans mon dossier Documents (dans <code>C:\Users\sylva\Documents</code>, <code>sylva</code> étant mon profil utilisateur). Je l’ai supprimé, mais il revient après chaque démarrage.
S’il vous plaît, pourriez-vous m’aider à me débarrasser de ce dossier ?
Pour contexte, je n’utilise pas / n’ai pas besoin de PowerShell, donc je ne suis pas trop sûr de pourquoi ce dossier est là.
<hr>
Source : <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Profiles" rel="noopener nofollow ugc">Super User</a>

ayi_2

Bien que le sous-dossier <code>WindowsPowerShell</code>[1] du dossier Documents bien connu :[2]
<ul>
<li></li>
</ul>
soit utilisé par Windows PowerShell (l’édition héritée, livrée avec Windows, uniquement Windows, dont la dernière et ultime version est la 5.1), à savoir pour stocker des <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Profiles">fichiers de profil</a> de niveau utilisateur optionnels et des <a href="https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_Modules">modules</a>,
<ul>
<li></li>
</ul>
son existence n’est pas nécessaire au fonctionnement de Windows PowerShell, et Windows PowerShell ne le crée pas à la demande (il n’est créé que par une action délibérée de l’utilisateur).[3]
Ce qui précède implique que dans votre cas, un processus qui s’exécute à la connexion doit recréer ledit dossier, vous devrez donc enquêter pour trouver lequel.
L’utilitaire Sysinternals <a href="https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns">Autoruns</a> peut vous aider à cet égard.
Plus précisément, étant donné que, comme vous l’indiquez dans un commentaire ultérieur, les sous-dossiers <code>Scripts\InstalledScriptInfos</code> sont créés à l’intérieur du dossier <code>WindowsPowerShell</code> indésirable, recherchez une tâche de démarrage PowerShell qui appelle <a href="https://learn.microsoft.com/en-us/powershell/module/powershellget/install-module"><code>Install-Module</code></a> et/ou <a href="https://learn.microsoft.com/en-us/powershell/module/powershellget/install-script"><code>Install-Script</code></a>.
Mise à jour :
<ul>
<li></li>
</ul>
Vous rapportez que le coupable s’est avéré être le gestionnaire de paquets méta à interface graphique <a href="https://github.com/marticliment/UniGetUI">UniGetUI</a>…
<ul>
<li></li>
</ul>
… et que la création inattendue du dossier a été signalée auparavant, dans le <a href="https://github.com/marticliment/UniGetUI/issues/2098">ticket GitHub #2098</a>, qui, cependant, a été fermé, en raison de l’idée fausse que le dossier fait partie intégrante et nécessaire de Windows PowerShell.
(En aparté : ce qui précède pourrait indiquer que ce n’était pas nécessairement un redémarrage / une reconnexion en soi qui a causé la création du dossier, mais le lancement de l’application UniGetUI – sauf si ce lancement se produit comme tâche de démarrage.)
[1] Notez que <a href="https://github.com/PowerShell/PowerShell/blob/master/README.md">PowerShell (Core) 7</a>, l’édition successeur moderne, multiplateforme, à installer à la demande, utilise le sous-dossier <code>PowerShell</code> à la place. Le reste de cette réponse s’applique de manière analogue.
[2] Son emplacement par défaut est <code>$env:USERPROFILE\Documents</code>, mais il peut être redirigé vers un emplacement différent sur une machine donnée, souvent vers OneDrive ; utilisez <code>[Environment]::GetFolderPath('MyDocuments')</code> pour déterminer l’emplacement réel.
[3] Les actions délibérées telles que la création forcée du fichier vers lequel pointe <code>$PROFILE</code> avec <code>New-Item -Force $PROFILE</code>, qui crée implicitement son dossier hébergeant, c’est-à-dire <code>WindowsPowerShell</code> sous Documents (ATTENTION : si vous exécutez ceci et qu’il y a un fichier préexistant à cet emplacement, il sera tronqué) ou telles que l’installation d’un module ou d’un script avec <code>Install-Module</code> ou <code>Install-Script</code>.
Inversement, vous pouvez vérifier que le dossier n’est pas (re)créé à la demande comme suit : si nécessaire (seulement si vous observez la création inattendue du dossier), créez un nouvel utilisateur et connectez-vous en tant que tel. Si le dossier existe sur votre système, renommez-le temporairement. Puis redémarrez votre système et lancez Windows PowerShell : il démarrera normalement, sans se plaindre, et le dossier ne sera pas (re)créé.