Comment recharger le profil de l'utilisateur à partir du fichier script dans PowerShell
je veux recharger mon profil utilisateur à partir d'un fichier de script. Je pensais que le point approvisionnement à partir du fichier de script ferait l'affaire, mais il ne fonctionne pas:
# file.ps1
. $PROFILEcependant, cela fonctionne si je dote la source de L'interpréteur de PowerShell.
pourquoi je veux faire ça?
j'exécute ce script à chaque fois que je mettre à jour mon profil et que vous souhaitez tester, donc j'aimerais éviter d'avoir à redémarrer PowerShell pour actualiser l'environnement.
7 réponses
ainsi, l'approche que vous avez marquée comme réponse peut fonctionner à l'intérieur de L'invite de commande Powershell, mais elle ne fonctionne pas à L'intérieur de PowerShell ISE (qui, pour moi, fournit une session PowerShell supérieure) et ne fonctionnera probablement pas correctement dans d'autres environnements PowerShell.
voici un script que j'utilise depuis un moment, et qui a très bien fonctionné pour moi dans tous les environnements. J'ai simplement mettre cette fonction dans mon Profil.ps1 à ~\Documents\WindowsPowerShell, et chaque fois que je veux recharger mon profil, j'point-source de la fonction, c'est à dire
. Reload-Profile
Voici la fonction:
function Reload-Profile {
@(
$Profile.AllUsersAllHosts,
$Profile.AllUsersCurrentHost,
$Profile.CurrentUserAllHosts,
$Profile.CurrentUserCurrentHost
) | % {
if(Test-Path $_){
Write-Verbose "Running $_"
. $_
}
}
}
si vous voulez rafraîchir globalement votre profil à partir d'un script, vous devrez exécuter ce script "dot-sourced".
Lorsque vous exécutez votre script, le script s'exécute dans un "script" champ d'application et ne modifiera pas votre "" portée globale.
pour qu'un script modifie votre portée globale, il doit être "dot-source" ou précédé d'une période.
. ./yourrestartscript.ps1
où vous avez votre script de profil " dot-sourced "à l'intérieur de" yourrestartscript.ps1". Ce que vous en fait, ils disent à "votresartscript" de s'exécuter dans le scope courant et à l'intérieur de ce script, vous dites au script $profile de s'exécuter dans le scope du script. Puisque la portée du script est la portée globale, toute variable définie ou commande dans votre profil se produira dans la portée globale.
cela ne vous donne pas beaucoup d'avantage sur la course
. $profile
Pourquoi essayez-vous de le faire?
parce qu'il est susceptible de créer des doublons (ajoute à $env:path) et des problèmes avec le réglage constant/readonly des objets causant des erreurs.
il y a eu un thread sur ce sujet récemment sur microsoft.public.Windows.powershell.
si vous essayez de réinitialiser l'état de la session, il n'y a aucun moyen de le faire, même en utilisant une portée interne ($host.EnterNestedPrompt()) en raison de la possibilité de définir des variables/alias/... "tous les portée."
& $profile
fonctionne pour recharger le profil.
si votre profil définit des alias ou exécute des importations qui échouent, alors vous verrez des erreurs car elles étaient déjà définies lors du chargement précédent du profil.
j'ai trouvé cette solution:
#some-script.ps1
#restart profile (open new powershell session)
cmd.exe /c start powershell.exe -c { Set-Location $PWD } -NoExit
Stop-Process -Id $PIDUne version plus élaborée:
#publish.ps1
# Copy profile files to PowerShell user profile folder and restart PowerShell
# to reflect changes. Try to start from .lnk in the Start Menu or
# fallback to cmd.exe.
# We try the .lnk first because it can have environmental data attached
# to it like fonts, colors, etc.
[System.Reflection.Assembly]::LoadWithPartialName("System.Diagnostics")
$dest = Split-Path $PROFILE -Parent
Copy-Item "*.ps1" $dest -Confirm -Exclude "publish.ps1"
# 1) Get .lnk to PowerShell
# Locale's Start Menu name?...
$SM = [System.Environment+SpecialFolder]::StartMenu
$CurrentUserStartMenuPath = $([System.Environment]::GetFolderPath($SM))
$StartMenuName = Split-Path $CurrentUserStartMenuPath -Leaf
# Common Start Menu path?...
$CAD = [System.Environment+SpecialFolder]::CommonApplicationData
$allUsersPath = Split-Path $([System.Environment]::GetFolderPath($CAD)) -Parent
$AllUsersStartMenuPath = Join-Path $allUsersPath $StartMenuName
$PSLnkPath = @(Get-ChildItem $AllUsersStartMenuPath, $CurrentUserStartMenuPath `
-Recurse -Include "Windows PowerShell.lnk")
# 2) Restart...
# Is PowerShell available in PATH?
if ( Get-Command "powershell.exe" -ErrorAction SilentlyContinue ) {
if ($PSLnkPath) {
$pi = New-Object "System.Diagnostics.ProcessStartInfo"
$pi.FileName = $PSLnkPath[0]
$pi.UseShellExecute = $true
# See "powershell -help" for info on -Command
$pi.Arguments = "-NoExit -Command Set-Location $PWD"
[System.Diagnostics.Process]::Start($pi)
}
else {
# See "powershell -help" for info on -Command
cmd.exe /c start powershell.exe -Command { Set-Location $PWD } -NoExit
}
}
else {
Write-Host -ForegroundColor RED "Powershell not available in PATH."
}
# Let's clean up after ourselves...
Stop-Process -Id $PID
ce n'est qu'un raffinement du script en deux lignes dans la réponse de guillermooo ci-dessus, qui n'a pas obtenu la nouvelle fenêtre PowerShell dans le répertoire correct pour moi. Je crois que c'est parce que $PWD est évalué dans le contexte de la nouvelle fenêtre PowerShell, qui n'est pas la valeur que nous voulons que set-location traite.
function Restart-Ps {
$cline = "`"/c start powershell.exe -noexit -c `"Set-Location '{0}'" -f $PWD.path
cmd $cline
Stop-Process -Id $PID
}
par Droits, cela ne devrait pas fonctionner, car la ligne de commande qu'il crache est mal formée, mais il semble faire le travail et c'est assez bon pour moi.
depuis que je suis tombé sur ce quelques années plus tard, j'ai pensé à ajouter que vous pouvez utiliser l'opérateur d'invocation:& pour charger votre profil avec la variable par défaut de votre profil: $profile.
donc, si votre session échoue d'une façon ou d'une autre à charger votre profil (ce qui m'arrive avec cmder/conemu) tapez juste:
& $profile