• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Need quick way to get "My Documents" folder

C

Chris Warwick

#1
Although there are numerous ways to find the user's profile folder
($env:userprofile for example) there isn't a quick way to get the path
to the "WindowsPowerShell" folder or the "My Documents" folder.

It isn't possible (in fact it's a bug) to assume that the "My
Documents" folder is a subfolder of the user's profile. In many
(?most) real world environments the "My Documents" folder is
redirected - usually to a network share.

Since PowerShell is using "WindowsPowerShell" in the "My Documents"
folder and since a bunch of other things insist on using "My
Documents" for all kinds of reasons I think it would be useful to have
a shortcut (a global variable?) which points here.

The best I can currently do to find the folder path is:

[Environment]::GetFolderPath("MyDocuments")

But it's a bit of a mouthful and hardly intuitive.

Thoughts anyone?

Regards,
Chris
 

My Computer

L

Lee Holmes [MSFT]

#2
We represent the WindowsPowerShell folder via the $psHome variable, and you
can always get the location of your profile via the $profile variable.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:4hmlh2puki815blq81nabfbj21rud8ap6s@4ax.com...
> Although there are numerous ways to find the user's profile folder
> ($env:userprofile for example) there isn't a quick way to get the path
> to the "WindowsPowerShell" folder or the "My Documents" folder.
>
> It isn't possible (in fact it's a bug) to assume that the "My
> Documents" folder is a subfolder of the user's profile. In many
> (?most) real world environments the "My Documents" folder is
> redirected - usually to a network share.
>
> Since PowerShell is using "WindowsPowerShell" in the "My Documents"
> folder and since a bunch of other things insist on using "My
> Documents" for all kinds of reasons I think it would be useful to have
> a shortcut (a global variable?) which points here.
>
> The best I can currently do to find the folder path is:
>
> [Environment]::GetFolderPath("MyDocuments")
>
> But it's a bit of a mouthful and hardly intuitive.
>
> Thoughts anyone?
>
> Regards,
> Chris
 

My Computer

J

James Truher

#3
early on in the process, I *knew* that we would be changing installation
directories and where the profile might reside. The variables $pshome and
$profile were created to _ensure_ that we could insulate users from those
changes. As for the My Documents location, from the filesystem, I use:
cd ~/My Documents

jim

--
--
James Truher [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:4hmlh2puki815blq81nabfbj21rud8ap6s@4ax.com...
> Although there are numerous ways to find the user's profile folder
> ($env:userprofile for example) there isn't a quick way to get the path
> to the "WindowsPowerShell" folder or the "My Documents" folder.
>
> It isn't possible (in fact it's a bug) to assume that the "My
> Documents" folder is a subfolder of the user's profile. In many
> (?most) real world environments the "My Documents" folder is
> redirected - usually to a network share.
>
> Since PowerShell is using "WindowsPowerShell" in the "My Documents"
> folder and since a bunch of other things insist on using "My
> Documents" for all kinds of reasons I think it would be useful to have
> a shortcut (a global variable?) which points here.
>
> The best I can currently do to find the folder path is:
>
> [Environment]::GetFolderPath("MyDocuments")
>
> But it's a bit of a mouthful and hardly intuitive.
>
> Thoughts anyone?
>
> Regards,
> Chris
 

My Computer

A

Alex B Chalmers

#4
My solution is to add a PS Drive for folders that I use often. Effectively,
those are My Documents, my Desktop, and some network drives.

A snippet of my profile:

$myDocumentsFolder = [Environment]::GetFolderPath("MyDocuments")
if ( test-path $myDocumentsFolder ) { new-PSDrive -Name MyDocs -PSProvider
FileSystem -Root $myDocumentsFolder | out-null }

I use the test-path element to ensure the path actually exists, which is a
problem for my laptop and network drives. One other thing to note is that
the test-path will error if the variable is null, which I had happen by
using "Desktop" rather than "DesktopDirectory".

The only issue with this particular solution is if you, in one instance,
attempt to open a file with notepad using a fully qualified path, ie
"notepad mydocs:\textfile.txt". The called applicaton cannot resolve this
path and will fail. Note that a relative path will work fine in this
situation. I typically will have this happen when using tab-completion with
a file in a subfolder, because the default tab-completion function will
resolve a fully qualified path.

- Alex B Chalmers


"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:4hmlh2puki815blq81nabfbj21rud8ap6s@4ax.com...
> Although there are numerous ways to find the user's profile folder
> ($env:userprofile for example) there isn't a quick way to get the path
> to the "WindowsPowerShell" folder or the "My Documents" folder.
>
> It isn't possible (in fact it's a bug) to assume that the "My
> Documents" folder is a subfolder of the user's profile. In many
> (?most) real world environments the "My Documents" folder is
> redirected - usually to a network share.
>
> Since PowerShell is using "WindowsPowerShell" in the "My Documents"
> folder and since a bunch of other things insist on using "My
> Documents" for all kinds of reasons I think it would be useful to have
> a shortcut (a global variable?) which points here.
>
> The best I can currently do to find the folder path is:
>
> [Environment]::GetFolderPath("MyDocuments")
>
> But it's a bit of a mouthful and hardly intuitive.
>
> Thoughts anyone?
>
> Regards,
> Chris
 

My Computer

C

Chris Warwick

#5
On Wed, 27 Sep 2006 20:27:25 -0400, "Alex B Chalmers"
<alex@alexbchalmers.com> wrote:

>My solution is to add a PS Drive for folders that I use often. Effectively,
>those are My Documents, my Desktop, and some network drives.
>
>A snippet of my profile:
>
>$myDocumentsFolder = [Environment]::GetFolderPath("MyDocuments")
>if ( test-path $myDocumentsFolder ) { new-PSDrive -Name MyDocs -PSProvider
>FileSystem -Root $myDocumentsFolder | out-null }
>
>I use the test-path element to ensure the path actually exists, which is a
>problem for my laptop and network drives. One other thing to note is that
>the test-path will error if the variable is null, which I had happen by
>using "Desktop" rather than "DesktopDirectory".
>
>The only issue with this particular solution is if you, in one instance,
>attempt to open a file with notepad using a fully qualified path, ie
>"notepad mydocs:\textfile.txt". The called applicaton cannot resolve this
>path and will fail. Note that a relative path will work fine in this
>situation. I typically will have this happen when using tab-completion with
>a file in a subfolder, because the default tab-completion function will
>resolve a fully qualified path.
>
>- Alex B Chalmers
>


Thanks for the suggestion, Alex.

BTW, I wish I could meet the person who thought up the "My Documents"
folder name for Windows 95 and have a reasoned discussion with them!!!

Thankfully Vista has finally fixed it by removing the dreadful
condescending and twee prefix.
 

My Computer

C

Chris Warwick

#6
On Wed, 27 Sep 2006 14:21:41 -0700, "Lee Holmes [MSFT]"
<lee.holmes@online.microsoft.com> wrote:

>We represent the WindowsPowerShell folder via the $psHome variable, and you
>can always get the location of your profile via the $profile variable.


Yeah - thanks Lee, but as noted the $profile variable is pretty much a
waste of space IMHO, I never write stuff there. But I do use "My
Documents" (as a lot of other things do) so I was after a convenience
feature to let me get to this quickly.

As noted I can create my own shortcut easily enough, but that will
only work on my machine (it's like MOW using "New" when he meant
"New-Object" (Sorry MOW!!!)) - so I can't use my shortcut in scripts
and will have to use [environment]::GetFolderPath("MyDocuments") all
the time.

Thanks,
Chris
 

My Computer

C

Chris Warwick

#7
On Wed, 27 Sep 2006 15:22:00 -0700, "James Truher"
<jimtru@news.microsoft.com> wrote:

>early on in the process, I *knew* that we would be changing installation
>directories and where the profile might reside. The variables $pshome and
>$profile were created to _ensure_ that we could insulate users from those
>changes. As for the My Documents location, from the filesystem, I use:
>cd ~/My Documents
>
>jim
>
>--



Thanks Jim

I guess you're forgetting to type the quotation marks?

PS> cd ~/my documents
Set-Location : A parameter cannot be found that matches parameter name
'documents'.
At line:1 char:3
+ cd <<<< ~/my documents


It would be good if I could use:

$SomeFolderPath="~/My Documents/"+"SomeFolder"

But of course this doesn't work...

Further more, you've fallen straight into the trap of assuming that
"My Documents" is in the user profile - which, as I've said, isn't the
case in the majority of real environments:

PS> cd "~/my documents"
Set-Location : Cannot find path 'C:\Documents and Settings\chris\my
documents' because it does not exist.
At line:1 char:3
+ cd <<<< "~/my documents"

PS> [environment]::GetFolderPath("MyDocuments")
\\Sirius\Users\chris\My Documents


Cheers,
Chris
 

My Computer

L

Lee Holmes [MSFT]

#8
Ahh, sorry -- I misunderstood why you wanted the location to your 'My
Documents.' As you've discovered, the most direct way to get it is via the
Environment class.

--
Lee Holmes [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:4l4nh2p12dbt111e9i91uas2pln3eads1o@4ax.com...
> On Wed, 27 Sep 2006 14:21:41 -0700, "Lee Holmes [MSFT]"
> <lee.holmes@online.microsoft.com> wrote:
>
>>We represent the WindowsPowerShell folder via the $psHome variable, and
>>you
>>can always get the location of your profile via the $profile variable.

>
> Yeah - thanks Lee, but as noted the $profile variable is pretty much a
> waste of space IMHO, I never write stuff there. But I do use "My
> Documents" (as a lot of other things do) so I was after a convenience
> feature to let me get to this quickly.
>
> As noted I can create my own shortcut easily enough, but that will
> only work on my machine (it's like MOW using "New" when he meant
> "New-Object" (Sorry MOW!!!)) - so I can't use my shortcut in scripts
> and will have to use [environment]::GetFolderPath("MyDocuments") all
> the time.
>
> Thanks,
> Chris
 

My Computer

A

Alex K. Angelopoulos [MVP]

#9
"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:4hmlh2puki815blq81nabfbj21rud8ap6s@4ax.com...
> Although there are numerous ways to find the user's profile folder
> ($env:userprofile for example) there isn't a quick way to get the path
> to the "WindowsPowerShell" folder or the "My Documents" folder.

.....

> [Environment]::GetFolderPath("MyDocuments")
>
> But it's a bit of a mouthful and hardly intuitive.
>
> Thoughts anyone?


Lots of them. <g>

I see you've already got a couple of answers, particularly involving finding
PS itself, but the overall general problem - "how do I find the official
location for a special folder" - is not answered conveniently with a global
shell variable in my opinion. It clutters things up needlessly, and also is
simply a copied and possibly modified piece of data, rather than a link
directly back to the original source. (The $pshome and $profile variables
are probably worthwhile exceptions since they are of central importance to
PS - although I would still prefer to see them as $Host or $ExecutionContext
properties...)

System.Environment's GetFolderPath method is probably better since it _does_
provide a way of asking the OS, but it has a big limitation. It only knows
about a handful of the standard special folders, and rejects other CSIDL
values. In general that won't matter for simple problems, but sometimes you
really do want to know what those other folders are as well.

Below is one of the scripts I've been using for this for a while. It uses
the Shell.Application COM object and all of the CSIDLs I've found that ever
return an actual filesystem path. Slightly simplified standard names based
on the CSIDL are returned as hash keys with associated values containing the
physical paths.

Additionally, if you specify the -AsDrive parameter, it will create PSDrives
for each path. The names are still a bit cumbersome, but it generally
_works_, which is pretty good. you can do things like:

gci Favorites:

(dir fonts:).Count

This is still far from perfect. I'm currently thinking about extending this
beyond the common CSIDLs, and trying to rework it into a comon scheme for
critical paths. It also clearly needs some some cleanup in the common name
and how the root is displayed.

#######################
#Get-SpecialPath.ps1 begins here.
#Get-SpecialPath.ps1
Param([switch]$AsDrive)
# Utility program for working with the
# Returns a hash containing the CSIDL values found in shlobj.h
# Based on 2005-04-14 version from Platform SDK.
# Names modified as follows:
# Initial CSIDL_ removed for compactness;
# Embedded underscores removed as well.
# Names were slightly recased for readability.
# The concept is that if you "know" the name as a programmer,
# you will probably be able to guess the name used here.
# If you're an end-user, the name will look a lot like the expected
# English display name, but with no spaces.

# NOTE - although this is roughly similar to using
# [System.Environment]::GetSpecialFolder($value),
# it works for all implemented CSIDL values, not just the ones
# defined in the System.Environment+SpecialFolder enumeration.

# STEP 1: Define a hash for the paths.
# This can be extended as appropriate for items added to shell32.

$csidl = @{
"Programs" = 0x0002; # Start Menu\Programs
"Personal" = 0x0005; # My Documents
"Favorites" = 0x0006; # <user>\Favorites
"Startup" = 0x0007; # Start Menu\Programs\Startup
"Recent" = 0x0008; # <user>\Recent
"Sendto" = 0x0009; # <user>\SendTo

# Technically, "DesktopDirectory" - <user>\Desktop
"Desktop" = 0x0010;
"StartMenu" = 0x000b; # <user>\Start Menu
"MyMusic" = 0x000d; # "My Music" folder
"MyVideo" = 0x000e; # "My Videos" folder
"Nethood" = 0x0013; # <user>\nethood
"Fonts" = 0x0014; # windows\fonts
"Templates" = 0x0015;
"CommonStartMenu" = 0x0016; # All Users\Start Menu
"CommonPrograms" = 0X0017; # All Users\Start Menu\Programs
"CommonStartup" = 0x0018; # All Users\Startup
"CommonDesktop" = 0x0019; # All Users\Desktop
"Appdata" = 0x001a; # <user>\Application Data
"Printhood" = 0x001b; # <user>\PrintHood

# <user>\Local Settings\Application Data (non roaming)
"LocalAppdata" = 0x001c;
"AltStartup" = 0x001d; # non localized startup
"CommonAltStartup" = 0x001e; # non localized common startup
"CommonFavorites" = 0x001f;
"InternetCache" = 0x0020;
"Cookies" = 0x0021;
"History" = 0x0022;
"CommonAppdata" = 0x0023; # All Users\Application Data
"Windows" = 0x0024; # GetWindowsDirectory()
"System" = 0x0025; # GetSystemDirectory()
"ProgramFiles" = 0x0026; # C:\Program Files
"MyPictures" = 0x0027; # C:\Program Files\My Pictures
"Profile" = 0x0028; # USERPROFILE
"SystemX86" = 0x0029; # x86 system directory on RISC
"ProgramFilesX86" = 0x002a; # x86 C:\Program Files on RISC
"ProgramFilesCommon" = 0x002b; # C:\Program Files\Common
"ProgramFilesCommonx86" = 0x002c; # x86 Program Files\Common on RISC
"CommonTemplates" = 0x002d; # All Users\Templates
"CommonDocuments" = 0x002e; # All Users\Documents

# All Users\Start Menu\Programs\Administrative Tools
"CommonAdminTools" = 0x002f;
"AdminTools" = 0x0030; # <user>\Start Menu\Programs\Administrative Tools
"CommonMusic" = 0x0035; # All Users\My Music
"CommonPictures" = 0x0036; # All Users\My Pictures
"CommonVideo" = 0x0037; # All Users\My Video
"Resources" = 0x0038; # Resource Directory
"ResourcesLocalized" = 0x0039; # Localized Resource Directory
"CommonOemLinks" = 0x003a; # Links to All Users OEM specific apps

# default is $LocalAppdata\Microsoft\CD Burning
"CdburnArea" = 0x003b;
}

### The following were NOT used since they are not real paths.
# "Desktop" = 0x0000; # <desktop> - this is not technicall
# # the physical folder, although it does have a path.
#"Internet" = 0x0001; # Internet Explorer (icon on desktop)
#"Controls" = 0x0003; # My Computer\Control Panel
#"Printers" = 0x0004; # My Computer\Printers
#"Bitbucket" = 0x000a; # <desktop>\Recycle Bin
#"MyDocuments" = 0x000c; # logical "My Documents" desktop icon
#"Drives" = 0x0011; # My Computer
#"Network" = 0x0012; # Network Neighborhood (My Network Places)
#"Connections" = 0x0031; # Network and Dial-up Connections
# Computers Near Me (from Workgroup membership)
#"ComputersNearMe" = 0x003d;





#Step 2: Set up Shell.Application COM object.
$sa = New-Object -ComObject Shell.Application



#Step 3: Set up hash for paths, collect with "names"
$sp = @{} # Special Paths
foreach($key in $csidl.keys)
{
$sp[$key] = $sa.NameSpace($csidl[$key]).Self.Path;
}


# Map global drives using names from the hash
if($AsDrive)
{
$keys = $sp.Keys;
$keys | %{
$p = $sp[$_];
if($p.Length -gt 0)
{
$n = $csidl[$_] # numeric to help ID the drive...
New-PSDrive -Name:$_ -PSProvider:FileSystem -Root:$p `
-Scope Global -Description:"SpecialFolder$n"
}
}
}else{
return $sp;
}
 

My Computer

?

=?Utf-8?B?ZHJlZXNjaGtpbmQ=?=

#10
Nice script! Until now I had many of these special paths as hard coded
psdrives in my profile. Also, I have two additional psdrives for PowerShell's
own special paths:

PS:\ = (split-path $profile)
PShome:\ = $PShome

--
greetings
dreeschkind


"Alex K. Angelopoulos [MVP]" wrote:

>
> "Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
> news:4hmlh2puki815blq81nabfbj21rud8ap6s@4ax.com...
> > Although there are numerous ways to find the user's profile folder
> > ($env:userprofile for example) there isn't a quick way to get the path
> > to the "WindowsPowerShell" folder or the "My Documents" folder.

> .....
>
> > [Environment]::GetFolderPath("MyDocuments")
> >
> > But it's a bit of a mouthful and hardly intuitive.
> >
> > Thoughts anyone?

>
> Lots of them. <g>
>
> I see you've already got a couple of answers, particularly involving finding
> PS itself, but the overall general problem - "how do I find the official
> location for a special folder" - is not answered conveniently with a global
> shell variable in my opinion. It clutters things up needlessly, and also is
> simply a copied and possibly modified piece of data, rather than a link
> directly back to the original source. (The $pshome and $profile variables
> are probably worthwhile exceptions since they are of central importance to
> PS - although I would still prefer to see them as $Host or $ExecutionContext
> properties...)
>
> System.Environment's GetFolderPath method is probably better since it _does_
> provide a way of asking the OS, but it has a big limitation. It only knows
> about a handful of the standard special folders, and rejects other CSIDL
> values. In general that won't matter for simple problems, but sometimes you
> really do want to know what those other folders are as well.
>
> Below is one of the scripts I've been using for this for a while. It uses
> the Shell.Application COM object and all of the CSIDLs I've found that ever
> return an actual filesystem path. Slightly simplified standard names based
> on the CSIDL are returned as hash keys with associated values containing the
> physical paths.
>
> Additionally, if you specify the -AsDrive parameter, it will create PSDrives
> for each path. The names are still a bit cumbersome, but it generally
> _works_, which is pretty good. you can do things like:
>
> gci Favorites:
>
> (dir fonts:).Count
>
> This is still far from perfect. I'm currently thinking about extending this
> beyond the common CSIDLs, and trying to rework it into a comon scheme for
> critical paths. It also clearly needs some some cleanup in the common name
> and how the root is displayed.
>
> #######################
> #Get-SpecialPath.ps1 begins here.
> #Get-SpecialPath.ps1
> Param([switch]$AsDrive)
> # Utility program for working with the
> # Returns a hash containing the CSIDL values found in shlobj.h
> # Based on 2005-04-14 version from Platform SDK.
> # Names modified as follows:
> # Initial CSIDL_ removed for compactness;
> # Embedded underscores removed as well.
> # Names were slightly recased for readability.
> # The concept is that if you "know" the name as a programmer,
> # you will probably be able to guess the name used here.
> # If you're an end-user, the name will look a lot like the expected
> # English display name, but with no spaces.
>
> # NOTE - although this is roughly similar to using
> # [System.Environment]::GetSpecialFolder($value),
> # it works for all implemented CSIDL values, not just the ones
> # defined in the System.Environment+SpecialFolder enumeration.
>
> # STEP 1: Define a hash for the paths.
> # This can be extended as appropriate for items added to shell32.
>
> $csidl = @{
> "Programs" = 0x0002; # Start Menu\Programs
> "Personal" = 0x0005; # My Documents
> "Favorites" = 0x0006; # <user>\Favorites
> "Startup" = 0x0007; # Start Menu\Programs\Startup
> "Recent" = 0x0008; # <user>\Recent
> "Sendto" = 0x0009; # <user>\SendTo
>
> # Technically, "DesktopDirectory" - <user>\Desktop
> "Desktop" = 0x0010;
> "StartMenu" = 0x000b; # <user>\Start Menu
> "MyMusic" = 0x000d; # "My Music" folder
> "MyVideo" = 0x000e; # "My Videos" folder
> "Nethood" = 0x0013; # <user>\nethood
> "Fonts" = 0x0014; # windows\fonts
> "Templates" = 0x0015;
> "CommonStartMenu" = 0x0016; # All Users\Start Menu
> "CommonPrograms" = 0X0017; # All Users\Start Menu\Programs
> "CommonStartup" = 0x0018; # All Users\Startup
> "CommonDesktop" = 0x0019; # All Users\Desktop
> "Appdata" = 0x001a; # <user>\Application Data
> "Printhood" = 0x001b; # <user>\PrintHood
>
> # <user>\Local Settings\Application Data (non roaming)
> "LocalAppdata" = 0x001c;
> "AltStartup" = 0x001d; # non localized startup
> "CommonAltStartup" = 0x001e; # non localized common startup
> "CommonFavorites" = 0x001f;
> "InternetCache" = 0x0020;
> "Cookies" = 0x0021;
> "History" = 0x0022;
> "CommonAppdata" = 0x0023; # All Users\Application Data
> "Windows" = 0x0024; # GetWindowsDirectory()
> "System" = 0x0025; # GetSystemDirectory()
> "ProgramFiles" = 0x0026; # C:\Program Files
> "MyPictures" = 0x0027; # C:\Program Files\My Pictures
> "Profile" = 0x0028; # USERPROFILE
> "SystemX86" = 0x0029; # x86 system directory on RISC
> "ProgramFilesX86" = 0x002a; # x86 C:\Program Files on RISC
> "ProgramFilesCommon" = 0x002b; # C:\Program Files\Common
> "ProgramFilesCommonx86" = 0x002c; # x86 Program Files\Common on RISC
> "CommonTemplates" = 0x002d; # All Users\Templates
> "CommonDocuments" = 0x002e; # All Users\Documents
>
> # All Users\Start Menu\Programs\Administrative Tools
> "CommonAdminTools" = 0x002f;
> "AdminTools" = 0x0030; # <user>\Start Menu\Programs\Administrative Tools
> "CommonMusic" = 0x0035; # All Users\My Music
> "CommonPictures" = 0x0036; # All Users\My Pictures
> "CommonVideo" = 0x0037; # All Users\My Video
> "Resources" = 0x0038; # Resource Directory
> "ResourcesLocalized" = 0x0039; # Localized Resource Directory
> "CommonOemLinks" = 0x003a; # Links to All Users OEM specific apps
>
> # default is $LocalAppdata\Microsoft\CD Burning
> "CdburnArea" = 0x003b;
> }
>
> ### The following were NOT used since they are not real paths.
> # "Desktop" = 0x0000; # <desktop> - this is not technicall
> # # the physical folder, although it does have a path.
> #"Internet" = 0x0001; # Internet Explorer (icon on desktop)
> #"Controls" = 0x0003; # My Computer\Control Panel
> #"Printers" = 0x0004; # My Computer\Printers
> #"Bitbucket" = 0x000a; # <desktop>\Recycle Bin
> #"MyDocuments" = 0x000c; # logical "My Documents" desktop icon
> #"Drives" = 0x0011; # My Computer
> #"Network" = 0x0012; # Network Neighborhood (My Network Places)
> #"Connections" = 0x0031; # Network and Dial-up Connections
> # Computers Near Me (from Workgroup membership)
> #"ComputersNearMe" = 0x003d;
>
>
>
>
>
> #Step 2: Set up Shell.Application COM object.
> $sa = New-Object -ComObject Shell.Application
>
>
>
> #Step 3: Set up hash for paths, collect with "names"
> $sp = @{} # Special Paths
> foreach($key in $csidl.keys)
> {
> $sp[$key] = $sa.NameSpace($csidl[$key]).Self.Path;
> }
>
>
> # Map global drives using names from the hash
> if($AsDrive)
> {
> $keys = $sp.Keys;
> $keys | %{
> $p = $sp[$_];
> if($p.Length -gt 0)
> {
> $n = $csidl[$_] # numeric to help ID the drive...
> New-PSDrive -Name:$_ -PSProvider:FileSystem -Root:$p `
> -Scope Global -Description:"SpecialFolder$n"
> }
> }
> }else{
> return $sp;
> }
>
>
>
>
 

My Computer

C

Chris Warwick

#11
Hi again Alex!

Great script - added to my library folder:-)

I agree and disagree (obviously!) First of all, I absolutely agree
with the desire to reduce clutter. But what I'm asking for is special
treatment for "My Documents" (which I think could be high-usage) - not
necessarily for all the special folders. I would argue that MyDocs
would be used more often than $profile; to keep the clutter-levels
constant by all means lose the $profile variable and replace it as far
as I'm concerned:-)

Cheers,
Chris
 

My Computer

J

James Truher

#12
nope - sorry, my "cd" function doesn't require quoting for directory names
with spaces (it's a cool little function - I've posted it here before) - I
shall blog it this weekend, yes, siree!

jim

--
--
James Truher [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Chris Warwick" <news@remove.this.bit.nuney.com> wrote in message
news:kl4nh2temgom23tainqlb4a5assvdpch7l@4ax.com...
> On Wed, 27 Sep 2006 15:22:00 -0700, "James Truher"
> <jimtru@news.microsoft.com> wrote:
>
>>early on in the process, I *knew* that we would be changing installation
>>directories and where the profile might reside. The variables $pshome and
>>$profile were created to _ensure_ that we could insulate users from those
>>changes. As for the My Documents location, from the filesystem, I use:
>>cd ~/My Documents
>>
>>jim
>>
>>--

>
>
> Thanks Jim
>
> I guess you're forgetting to type the quotation marks?
>
> PS> cd ~/my documents
> Set-Location : A parameter cannot be found that matches parameter name
> 'documents'.
> At line:1 char:3
> + cd <<<< ~/my documents
>
>
> It would be good if I could use:
>
> $SomeFolderPath="~/My Documents/"+"SomeFolder"
>
> But of course this doesn't work...
>
> Further more, you've fallen straight into the trap of assuming that
> "My Documents" is in the user profile - which, as I've said, isn't the
> case in the majority of real environments:
>
> PS> cd "~/my documents"
> Set-Location : Cannot find path 'C:\Documents and Settings\chris\my
> documents' because it does not exist.
> At line:1 char:3
> + cd <<<< "~/my documents"
>
> PS> [environment]::GetFolderPath("MyDocuments")
> \\Sirius\Users\chris\My Documents
>
>
> Cheers,
> Chris
 

My Computer

Users Who Are Viewing This Thread (Users: 1, Guests: 0)