Question [Résolu] Problème avec les alias

jojo écrit:

[code:1]new-alias -force -name rm -value remove-item -force[/code:1]
maintenant pour chaque appel de rm les fichiers seront effacer sans confirmation \"-force\"

C'est bien ce qui me semblait, il y a une incompréhension sur la présence du paramètre -Force, ici il référence celui du cmdlet New-Alias.
Un alias pointe sur un nom de commande, de fonction ou de prog externe, mais ne pointe pas sur une suite d'instructions.

Pour réaliser ce que tu souhaites faire, tu peux utiliser une fonction :
[code:1]
function Test {Write-warning \"Appelle le scriptblock : $args\"}
Test \"une valeur\"
[/code:1]
Ici cela fonctionne pour passer une valeur sans l'associer à un nom de paramètre, essayons maintenant de l'associer :
[code:1]
function Test { invoke-expression \"Write-Host $args\" }
Test \"Appelle le scriptblock\"
Test \"Appelle le scriptblock\" -Fore Green
[/code:1]
ça marche.
En utilisant le dynamisme on pourrait retrouver le comportement souhaité, enfin pour ce cas.
jojo écrit:

Si je veux,dans un script ou directement dans le prompt, changer ce comportement pour un fichier donnée pour qu'il m'affiche la confirmation que faire alors ?

Si je comprend bien, tu veux donc paramètrer la spécialisation d'un cmdlet !
Essayons :
[code:1]
#on simplifie le code pour ne gérer que le switch
#sans avoir à redéclarer tous les paramètres de Remove-Item
Function delete {
#on force la valeur du switch
param( [switch]$whatif=$true )
#on appel le cmdlet d'origine, en propageant la valeur du switch
Remove-Item c:\temp\*.tmp -whatif:$whatif
}
#premier appel, $whatif est activé par défaut
Delete
#Second appel, la présence de -whatif ne change rien
Delete -whatif
#troisème appel, $whatif est désactivé en précisant une nouvelle valeur
Delete -whatif:$false
[/code:1]
Le pb est que la seconde instruction est contradictoire, je demande tel comportement, mais le code n'en tient pas compte.
On peut préciser les intentions en inversant la logique autour d'un nouveau paramètre :
[code:1]
Function delete {
param( [switch]$NoWhatif )
#on appel le cmdlet d'origine, en propageant la valeur inverse du switch
Remove-Item c:\temp\*.tmp -whatif:«»(!$NoWhatif)
}
#premier appel, -NoWhatif n'est pas précisé($false), Whatif est activé par défaut (not $false).
Delete
#Second appel, -NoWhatif est précisé($true), Whatif est désactivé (not $true).
Delete -NoWhatif
[/code:1]
C'est donc possible, mais cela ressemble à du code de Didier l'Embrouille
Reste que les autres paramètres du cmdlet d'origine ne sont pas gérés, à moins de le recoder dans la fonction Delete qui sert d'intermédiaire et de filtre (Proxy).

PowerShell v2 permet de créer des proxys de cmdlet, leurs usages est expliqué dans ce tutoriel .
C'est du scripting avancée mais cela répond parfaitement à ton besoin.

Je joins un proxy du cmdlet Remove-Item qui affecte $true au switch -Force si on ne le précise pas sur la ligne de commande, sinon il prend la valeur qu'on lui affecte.
Donc pour forcer la suppression :
[code:1]
$path=TODO
New-Alias rmForce \"$Path\Remove-ItemForce.ps1\"
#-Force n'est pas précisé et est à true par défaut
XrmForce C:\temp\*.tmp
#-Force est précisé, le comportement ne change pas
XrmForce C:\temp\*.tmp -Force
#-Force est précisé à false, on annule le comportement modifié.
XrmForce C:\temp\*.tmp -Force:$false
[/code:1]
On retombe dans une problèmatique de gestion d'alias, mais cette fois ci en ayant un script spécialisé modifiant le comportement du cdmlet d'origine, tout en laissant la possibilité de retrouver son comportement d'origine.
Il est préférable de distinguer l'alias du proxy, par exemple en utilisant le préfixe X suivi du nom de l'alias du cmdlet d'origine et enfin par le comportement modifié.
<br><br>Message édité par: Laurent Dardenne, à: 18/06/10 16:13