Vista - Getting/Setting filesystem working directory

Since there are some occasions where the location cmdlets don't work well -
for example, relative path names used in functions - I've got a couple of
functions I use to determine the working directory and set it. Note that if
Set-WorkingDirectory is invoked with no arguments, it synchronizes the
working directory with the PowerShell filesystem location.

function Get-WorkingDirectory
{
Param([switch]$Object)
$WorkDir = [IO.DirectoryInfo]([Environment]::CurrentDirectory)
if($Object){$WorkDir}else{$WorkDir.Fullname}
}

function Set-WorkingDirectory
{
Param([string]$Path = (Get-Location -PSProvider FileSystem))
[Environment]::CurrentDirectory = $Path
}

"Alex K. Angelopoulos [MVP]" wrote:

> Since there are some occasions where the location cmdlets don't work well -
http://www.leeholmes.com/blog/SetLoc...Directory.aspx

Lee Holmes has a blog entry on that behavior on "Set-Location, and
[Environment]::CurrentDirectory"

====================
Sung M Kim

Please don''t bother me with spam...

"dance2die" <dance2die@discussions.microsoft.com> wrote in message
news:C0B29903-D4F5-4AB7-A522-D0D1A72DABCD@microsoft.com...
>
> "Alex K. Angelopoulos [MVP]" wrote:
>
>> Since there are some occasions where the location cmdlets don't work
>> well -
> http://www.leeholmes.com/blog/SetLoc...Directory.aspx
>
> Lee Holmes has a blog entry on that behavior on "Set-Location, and
> [Environment]::CurrentDirectory"
>

Actually, that blog entry motivated this post - and the related news post I
made about inconsistent resolution of "." - or at least the _experience_ of
it when we call a .NET method. I can't seem to resolve paths directly using
PathInfo or PathIntrinsics, and Resolve-Path is not very useful for guessing
at the path of an item that does not yet exist.

So far, the only reliable technique I've found is to use this:

function Get-AbsolutePath
{
Param([string]$name)
Resolve-Path $name -ev:errorOut -ea:SilentlyContinue;
if(!$?)
{
$file = New-Item -Path:$name -ItemType:file;
$path = $file.Fullname;
Remove-Item -Path:$file;
$path;
}
}

Using that, a function that deals with a file or folder can get either an
absolute or a relative PSPath from a user and correctly resolve it to a
fully-qualified path usable in .NET method calls. As it is, I occasionally
forget to do this and so I have to go to my home directory and clean out
accidentally created files at regular intervals...

"Alex K. Angelopoulos [MVP]" wrote:

> Using that, a function that deals with a file or folder can get either an
> absolute or a relative PSPath from a user and correctly resolve it to a
> fully-qualified path usable in .NET method calls. As it is, I occasionally
> forget to do this and so I have to go to my home directory and clean out
> accidentally created files at regular intervals...

i am not sure if i understood the usage correctly but,
I usually do this to pass non-existent file names to .NET methods
by using combination of "test-path" and "resolve-path".

[^_^]PS[100]>rvpa .
Path
----
C:\programming\ps\test
[^_^]PS[101]>get-workingdirectory
c:\
[^_^]PS[102]>test-path "$(rvpa .)\bad-file.txt"
False
[^_^]PS[103]>"$(rvpa .)\bad-file.txt"
C:\programming\ps\test\bad-file.txt

Whether the file exists or not, i just simply pass "$(rvpa .)\file_name" to
the .NET method,
that way, you are essentially passing the full name so that .NET would not
have to resolve the file name any further through
[Environment]::CurrentDirectory.

> Resolve-Path is not very useful for guessing at the path of an item that does not yet exist.
By the way, i think "test-path" would come in more handy for testing for a
file that might/might not exist yet.

====================
Sung M Kim

Please don''t bother me with spam...

"dance2die" <dance2die@discussions.microsoft.com> wrote in message
news:606A6FED-FA75-429A-A5AB-3122576FE4E5@microsoft.com...
>
> "Alex K. Angelopoulos [MVP]" wrote:

> i am not sure if i understood the usage correctly but,

Yes, you are understanding what I mean; the solution (snipped) is useful.

> By the way, i think "test-path" would come in more handy for testing for a
> file that might/might not exist yet.

It is, but I would need to repeat the work. Here's an example of a scenario
I have in mind.

Someone begins using PowerShell, learns command basics, and is comfortable
with using Set-Location and commands like Get-ChildItem, Get-Item, and so
on. They know all about specifying paths, and even using relative path
symbols like . and ..

They can do this:
Set-Location C:\Temp
and then when they do this:
Get-ChildItem > .\list.txt
or this:
Get-ChildItem . | set-content list.txt
or this:
Get-ChildItem | Export-Csv list.csv
in every case, they will be listing the files within C:\temp and the output
will go to c:\temp\list.txt or c:\temp\list.csv.

Now let's say someone writes a function or script that takes a filesystem
path as an argument. My To-Stream function might be an example. I don't know
whether the person is trying to pass an absolute path or a relative path.
However, they will expect relative paths to work relative to one's location.
Furthermore, the person writing the function might not know about the
ramifications of this. If you run To-Stream as it is now, you get output
relative to the working directory, not the PS location.

I'm not sure what a good solution is, since we don't want to force
resolution of a PS location, for the reasons Lee points out. I think it
might be useful to declare a type of object called a PSPath that can be
resolved into a fully-qualified PowerShell-style path.

There's another minor aberration I've f