Vista - Resolve-path on non existing file

Hi,

lets say I have the following PS script:

param(
[string] $StartTime="end-12h",
[string] $EndTime="now",
[string] $SourceDb="cpuUsage.rrd",
[string] $ImageFileName="cpuUsage.png"
)

rrdtool.exe graph $ImageFileName # ... something like that

To make this script work even with fancy psdrives I normaly would
rewrite this script as follows:

$ImageFileName=Resolve-Path $ImageFileName

However, rrdtool is supposed to _create_ this file so Resolve-Path
doesn't work in this case.

Any ideas?

tia

Max

"Maximilian Hänel" <ngSpam@smjh.de> wrote in message
news:OOmcAWt$GHA.3536@TK2MSFTNGP03.phx.gbl...
> However, rrdtool is supposed to _create_ this file so Resolve-Path doesn't
> work in this case.
>
> Any ideas?

Yes, first you can't really create files based on a path with wildcards in
it. On the other hand if there are wildcards you need to resolve the path
to mulitple paths. So what you need to do is first test to see if there are
any wildcards in $ImageFileName. You can do that like so:

23#
[Management.Automation.WildcardPattern]::ContainsWildcardCharacters($ImageFileName)
True

If there are wildcards, then jump directly to resolve-path. If there aren't
wildcards (a single file) then use Test-Path to see if it exists. If it
doesn't then create it if necessary.

--
Keith

Hi Keith,

> Yes, first you can't really create files based on a path with wildcards in
> it. On the other hand if there are wildcards you need to resolve the path
> to mulitple paths.

Actually I don't care much about wildcards. But lets say I invoke a
"regular" .exe with a path like this as an argument:

~\Test.png

The programm (rrdtool.exe in my case) doesn't know how to resolve that
filename. The same yields true for custom PSDrives etc.

So how can I expand/resolve such filenames in a PS like manner?
Of course I could create this file if it doesn't exist run Resolve-Path
on it and eventually delete that file just before calling my external
programm. But to me this sounds more like a hack than a real solution.


Thanks,

Max

PS> RESOLVE-PATH ~\TEST
Resolve-Path : Cannot find path 'C:\Users\jsnover.NTDEV\TEST' because it
does not exist.
At line:1 char:13
+ RESOLVE-PATH <<<< ~\TEST
PS> $ERROR[0].TargetObject
C:\Users\jsnover.NTDEV\TEST

jps

$x=resolve-path ~\Tango -ev Error -ea silentlycontinue
if (!$x)
{
$x = $error[0].targetobject
}
$x


ENJOY!

http://blogs.msdn.com/powershell/arc...rvariable.aspx
jps

Unfortunately, this might still cause problems using external (legacy) apps
together with "fancy psdrives" as I think Maximilian does in his example in
the first posting.
The problem occurs if you are in a custom PSDrive that is derived from the
filesystem like for instance:

PoSh C:\> new-psdrive -name PS -psprovider FileSystem -root (Split-Path
$profile) | out-null
PoSh C:\> cd PS:\
PoSh PS:\> resolve-path ./nonexistent -ea silentlycontinue
PoSh PS:\> $error[0].targetobject
PS:\nonexistent

As you know, you cannot pass PowerShell path names like this one directly to
legacy apps, because the original developers of MS-DOS did not think of drive
names like 'PS:'. Therefore I suggest using Get-Item instead to resolve the
underlying filesystem path:

PoSh PS:\> Get-Item ./nonexistent -ea silentlycontinue
PoSh PS:\> $error[0].targetobject
E:\Eigene Dateien\WindowsPowerShell\nonexistent

So the final code might look like this:

#################################
$x = Get-Item .\Tango -ev myError -ea silentlycontinue
if (!$x) {
$x = $myError[0].targetobject
}
$x
#################################

PS 1: Note that naming the ErrorVariable "Error" is probably not a good
idea, because this might cause: "Cannot overwrite variable Error because it
is read-only or constant."

PS 2: To be even pettier, one should also test whether the path belongs to a
FileSystem drive at all. :-)

--
greetings
dreeschkind

"Jeffrey Snover" wrote:

> $x=resolve-path ~\Tango -ev Error -ea silentlycontinue
> if (!$x)
> {
> $x = $error[0].targetobject
> }
> $x
>
>
> ENJOY!

Thanks Jeffrey -and dreeschkind !

> So the final code might look like this:
>
> #################################
> $x = Get-Item .\Tango -ev myError -ea silentlycontinue
> if (!$x) {
> $x = $myError[0].targetobject
> }
> $x
> #################################

It works!!! ;-)

However, shouldn't PS provide a first class cmdlet or special parameter
for this purpose? What about introducing a "force" parameter or
something like that on resolve-path? I think calling legacy apps is
something that will be used quiet frequently - at least until PS is a
full replacement for everything ;-)

$happyPath=Resolve-Path .\Tango -force

I have a bad feeling relying on the content of an error object and
misusing it as return value. While this works today, it might break in
future versions as the content of an exception/error is or should not be
part of a cmdlets contract.

Thanks again,

Max

> PS 1: Note that naming the ErrorVariable "Error" is probably not a good
> idea, because this might cause: "Cannot overwrite variable Error because
> it
> is read-only or constant."

Oops! You are absolutely correct.
Jeffrey Snover [MSFT]
Windows PowerShell/MMC Architect
Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx

> However, shouldn't PS provide a first class cmdlet or special parameter
> for this purpose? What about introducing a "force" parameter or
That would be a good thing to add. Please file a bug.

Jeffrey Snover [MSFT]
Windows PowerShell/MMC Architect
Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx