Powershell: Appel de l'opérateur (&) avec évacuation param (--%) ne fonctionne pas avec les non-statique args

Mon script Powershell doit invoquer un fichier EXE avec un très compliqué d'arguments. Je suis à l'aide de Powershell 3.0, et doit s'en tenir à cette version. Hélas, même la "magie" s'échappant de l'opérateur (--%) n'est pas de m'aider. Par exemple, à l'aide de l'opérateur d'Appel, pensez à ceci:

& other.exe --% action /mode fast /path:"location with spaces" /fancyparam { /dothis /dothat:"arg with spaces" } /verbose

Maintenant, si c'était si simple, mon script peut facilement fonctionner correctement. Mais il n'est pas simple. Les arguments pour "other.exe" peut être différent, selon les sélections de l'utilisateur au début de mon script. Donc, au lieu de cela, j'ai besoin de construire ces paramètres à l'avance, peut-être comme ceci:

$commandArgs = 'action /mode ' + $userMode + ' /path:"location with spaces" /fancyparam { /dothis /dothat:"' + $userArgs + " } /verbose'

Donc je voudrais appeler de cette façon:

& other.exe --% $commandArgs

...eh bien, s'attendre à ce que --% signifie qu'il transmet simplement une chaîne brute de $commandArgs à la place. Mais sans le --%, powershell auto-cite le contenu de $commandArgs, qui bousille l'intérieur des guillemets (pour ne pas mentionner la rupture de "l'action" argument à l'avant qui other.exe les besoins de première). En d'autres termes, j'ai déjà essayé l'intégration de la --% à l'intérieur de mon $commandArgs la chaîne, mais le mal est déjà fait par le temps, il serait analysée (et je ne pense pas que cela fonctionne de cette façon).

NOTEZ que cet exemple n'est que d'environ 1/4 de ma commande j'ai besoin d'exécuter -- qui comprend beaucoup plus de l'utilisateur args, des citations et autres drôles de personnages que me conduire à s'échapper-l'enfer dans un dépêchez-vous! J'ai également déjà été à l'aide de la echoargs.exe l'outil, qui est la façon dont je vois les problèmes que je vais avoir. Oh, et j'ai besoin de tous les espaces dans mon exemple, trop (c'est à dire le besoin d'espaces autour de l'attache de caractères).

Donc, après beaucoup de recherches pour la réponse, je me tourne vers vous pour de l'aide. Merci à l'avance.

InformationsquelleAutor SteveDJ | 2014-01-27
  1. 8

    Ok, probablement bizarre de répondre à ma propre question, mais après avoir passé l'autre jour sur ce problème hier, j'ai réalisé que la réponse moi-même. Au moins, c'est ce que j'ai trouvé qui fonctionne. Mais je poste ici pour obtenir de plus amples commentaires, dans le cas où je suis vraiment en train de faire quelque chose qui n'est pas recommandé ...l'aide d'Invoquer l'Expression 🙂

    J'avais sorta réalisé très tôt, et certains d'entre vous l'a confirmé ce, dans vos réponses, que le --% empêche tous les autres expansions (y compris mon $variables). Et mon problème est que je suis encore besoin de développer beaucoup de choses lorsque vous essayez d'utiliser l'opérateur d'Appel (&). Mon problème serait résolu si ma ligne de commande est tout prêt à aller de l'avant à l'aide de --%, de sorte que ce que j'ai fait.

    J'ai créé une nouvelle chaîne, composée de:

    $fullCommand = '& "other.exe" --% ' + $commandArgs

    (Le chemin d'accès EXE en fait des espaces, d'où les guillemets.) Puis, avec elle, tous construits (y compris les --% là où il faut), je invoquer celle-ci comme un nouveau morceau de script:

    Invoke-Expression $fullCommand

    Jusqu'à présent, je vais avoir de très bons résultats. Mais je sais que dans ma recherche jusqu'à ce point que Invoke-Expression sonnait comme cette mauvaise chose, les gens ne devraient pas l'utiliser. Pensées, tout le monde?

    InformationsquelleAutor SteveDJ
  2. 3

    Le but de --% est de supprimer l'argument de traitement, donc il n'y a pas d'expansion de variables après que paramètre au nom de PowerShell. Vous pouvez contourner ce problème en utilisant des variables d'environnement, si:

    $env:UserMode = 'foo'
$env:UserArgs = 'bar baz'

& other.exe --% action /mode %UserMode% /path:"location with spaces" /fancyparam { /dothis /dothat:"%userArgs%" } /verbose
    • C'est certainement une solution viable, même si elle nécessite un grand nombre de variables 'copie' (en env vars) qui pourrait obtenir un peu difficile, comme ma ligne de commande grandit...? Je suis en ajoutant un +1 vote pour cette pour le moment... 🙂 (ou, je vote, mais je n'ai pas assez de réputation encore, oh bien)
    InformationsquelleAutor Ansgar Wiechers
  3. 2

    Je recommande toujours que les gens construisent leurs arguments de ligne de commande dans une variable, puis passer cette variable en la -ArgumentList paramètre de la Start-Process applet de commande.

    $Program = '{0}\other.exe' -f $PSScriptRoot;
$UserMode = 'fast';
$Path = 'c:\location with\spaces';
$ArgWithSpaces = 'arg with spaces';
$ArgumentList = 'action /mode {0} /path:"{1}" /fancyparam { /dothis /dothat:"{2}" } /verbose' -f $UserMode, $Path, $ArgWithSpaces;

$Output = '{0}\{1}.log' -f $env:Temp, [System.Guid]::NewGuid().ToString();
Start-Process -Wait -FilePath $Program -ArgumentList $ArgumentList -RedirectStandardOutput $Output;
    • Hmmm, c'est un peu plus compliqué que je le voudrais. 🙂
    • Il est effectivement plus facile, une fois que vous avez réellement la comprendre et de s'habituer à elle. J'ai également intégré le concept de .NET mise en forme de chaîne, ce qui n'est pas une exigence, mais rend la compilation des paramètres un peu plus modulaire.
    • Cela fonctionne comme prévu? Le paramètre-ArgumentList est censé être un tableau de chaînes, mais vous juste donné une chaîne unique, de sorte que l'ensemble de la chaîne de $ArgumentList doit être passé comme premier argument.
    • Oui, il fonctionne parfaitement bien. Essayez-le vous-même.
    InformationsquelleAutor Trevor Sullivan