Question Get-content fichier distant

6ratgus écrit:

tout est dis dans ces deux Write-host

Presque


Raijin écrit:

$folderPath recupère le chemin d'accès.

Ok
Raijin écrit:

$folderContain récupère les noms de fichiers qui se trouvent dans le dossier temp et les met dans un tableau.

Get-ChildItem récupère des objets de type fichiers et pas des noms de fichiers, ce n'est pas la même chose, et c'est ce qui pose pb ici :
[code:1]
$folderContain[0].Gettype().FullName
#System.IO.FileInfo
$folderContain[0].Fullname.Gettype().FullName
#System.String
[/code:1]
Raijin écrit:

Ensuite le foreach parcours ce tableau,

Ok
Raijin écrit:

mais ne garde pas en mémoire le chemin d'accès de chaque fichier,

Si l'objet existe, l'information existe aussi.
Raijin écrit:

du coup a chaque Get-content (vu qu'il ne connait pas le chemin d'accès au fichier) il ne trouve pas ce fichier.

C'est effectivement ce qui se passe, mais on ne sait tjr pas pourquoi, à partir d'un objet fichier, le cmdlet Get-Content ne 'connait' le chemin d'accès au fichier.
Ici il faut lire la documentation et comprendre le mécanisme de liaison de paramétres (parameter binding) :
[code:1]
Get-Help Get-Content -Parameter path
-Path <String[]>
Specifies the path to an item. Get-Content gets the content of the item. Wildcards are permitted. The parameter
name (\"Path\" or \"FilePath\"«») is optional.

Obligatoire ? true
Position ? 1
Valeur par défaut
Accepter l'entrée de pipeline ? true (ByPropertyName)
Accepter les caractères génériques ? true
[/code:1]
C'est une des bases à connaître sous PS, sans elle vous rencontrerez ce pb souvent et passerez au travers de fonctionnalités importantes.

Le paramètre 'Path' attend un tableau de chaîne de caractères ( -Path <String[]> ), s'il n'y a qu'une seule chaîne cela fonctionne également.
Pour :
[code:1]
foreach($file in $folderContain)
[/code:1]
$File est un objet de type fichier, celui-ci est donc transformé par PS lors de la liaison de paramètres en une chaîne de caractères, identique à l'instruction suivante :
[code:1]
$File.ToString()
[/code:1]
Ce qui renvoi le nom du fichier et pas son nom complet, ensuite PS ajoute en interne, pour avoir un nom complet, le nom du répertoire courant qui n'est pas celui attendu :

#Information de trace issues de l'instruction 'trace-command parameterbinding {Get-Content $file} -pshost'

DÉBOGUER : ParameterBinding Information: 0 : BIND arg [ast.txt] to parameter [Path]
DÉBOGUER : ParameterBinding Information: 0 : COERCE arg to [System.String[]]

Pour corriger cela on utilise soit le nom complet :
[code:1]
Get-Content $File.FullName
[/code:1]
Soit le pipeline, qui possède un autre comportement lors de liaison de paramètres :
[code:1]
$File|Get-Content
[/code:1]
Dans ce cas l'objet provenant du pipeline est traité comme étant lié au paramètre 'LiteralPath' :
[code:1]
Get-Help Get-Content -Parameter LiteralPath
-LiteralPath <String[]>
Specifies the path to an item. Unlike Path, the value of LiteralPath is used exactly as it is typed. No characters
are interpreted as wildcards. If the path includes escape characters, enclose it in single quotation marks. Single
quotation marks tell Windows PowerShell not to interpret any characters as escape sequences.

Obligatoire ? true
Position ? named
Valeur par défaut
Accepter l'entrée de pipeline ? true (ByValue, ByPropertyName)
Accepter les caractères génériques ? false
[/code:1]
Ainsi on lie bien au cmdlet l'information portée par l'objet fichier :

#Information de trace issues de l'instruction 'trace-command parameterbinding {$File|Get-Content} -pshost'
DÉBOGUER : ParameterBinding Information: 0 : BIND arg
[Microsoft.PowerShell.Core\FileSystem::\\localhost\c$\temp\ast.txt] to parameter [LiteralPath]

En interne le nom de chemin référençant le provider (PSPath) est transformé en un nom complet du FileSytem. Reste à savoir si l'usage de l'UNC ne posera pas d'autres soucis...

Je vous laisse étudier l'usage de \"Position\" et \"Accepter l'entrée de pipeline\"