Powershell scripts not found on psdrive despite $env:path entry -

update: added factoid @ bottom.

---

i going nuts trying understand why simple / obvious / necessary functionality doesn't work (for me). haven't been able find same problem, not i've changed system default (bad habit) , screwed myself , find myself on receiving end of "just desserts", still ...

problem statement:

given working powershell scripts found , executable ... why aren't these scripts found when they're moved psdrive and implicitly invoked via $env:path (which includes script folder referenced psdrive)? (this para edited clarity)

test case:

1) create local disk psdrive running:

new-psdrive -name home -psprovider filesystem -root $home 

2) copy (working) posh script (call "script.ps1") $home

3) $env:path += ";home:"

4) change directory place $home.

5) open posh command window run: "script" or "script.ps1"

i submit script should found reference "home:/" component in $env:path.

the script isn't found.

just grins (and eliminate content problem), let contents of $home/script.ps1 string:

"hello world" 

when run

home:/script 

or

&"$home/script" 

or (invoking $home/documents)

../script 

the script prints ...

hello world 

quelle surprise, eh? when run

script 

or

script.ps1 

i familiar error message:

the term 'script' not recognized name of cmdlet, ... 

yet home: in path:

$ $env:path -split ";" %systemroot%\system32\windowspowershell\v1.0\ c:\windows\system32 c:\windows c:\windows\system32\wbem c:\windows\system32\windowspowershell\v1.0\ c:\program files\sysinternals c:\program files\vim\vim73\ c:{my home directory}/psbin home:/ 

if move script.ps1 $home/psbin (also in $env:path, regular folder, not psdrive) , run script again, get:

$ script hello world 

summarizing:

posh scripts not found when

1) script in psdrive folder

2) psdrive folder in $env:path

3) script invoked (implicitly) relative psdrive folder component in $env:path rather absolute or relative path.

note in test case above script on psdrive rooted locally on c: drive.

note further "finding"/"not finding" not function of script itself; it's function of location of script (specifically: psdrive / not psdrive) , whether invocation relies on $env:path.

note further script runs if invoke absolute or relative-to-current-directory path (suggesting again isn't acl/attr/gpo problem.)

why isn't script found $env:path???

background information:

1) see behavior in win7pro running vmware workstation 8.0.6 guest, win7homepremium ditto, , in bare-metal whs2011 server (connecting via rdp);

2) see behavior on 32b win7pro (vm), 64b win7homepremium (vm) , 64b whs2011 (rdp);

3) execution policy set "bypass" current user & machine (and undefined in other scopes).

4) powershell version 2.0

5) pathext augmented .ps1:

$ $env:pathext .com;.exe;.bat;.cmd;.vbs;.vbe;.js;.jse;.wsf;.wsh;.msc;.ps1 

6) win7 / whs2011 systems patched

---

what doing wrong?

fwiw, use psdrives because have very long paths (with embedded spaces ... thanks, vmware!) files on host machine. don't use symlinks because posh comes symlink easter egg:

https://connect.microsoft.com/powershell/feedback/details/727149/powershell-rm-rec-traverses-symbolic-links-and-removes-items-in-target

h/t:

http://blog.rlucas.net/rants/dont-bother-with-symlinks-in-windows-7/

should posh+symlink user read this, rm -rf symlink-to-$home-folder deletion no theoretical concern: came within keystroke of deleting large fraction of linux home directory way (via symlinks vmware host shared folders, should point unclear.)

update:

if add long path (in case of interest me, unc path convert-path returns) $env:path rather psdrive-relative path, posh finds script.

which (again) says problem isn't acl/gpo/attr problem network drive (which script is).

in code, powershell resolves path script if set $env:path variable with:

$env:path += ";//vmware-host/shared folders/blah/psbin" 

rather than

$env:path += ";blah:/psbin" 

where blah: psdrive rooted @ //vmware-host/shared folders/blah.

not radical or anything, appears powershell can't resolve psdrives in $env:path variable.

can explain why should so? thought languages should closed wrt own semantics.

or overlooking fundamental / obvious point?

get-item, new-item, get-childitem, etc in microsoft.powershell.management module.

in powershell 3, possible start powershell without management module, , hence, , no *-item commands.

get-command, invoke-command, in microsoft.powershell.core module.

now fun part.

remove-psdrive -name home -ea silentlycontinue [void](new-psdrive -name home -psprovider filesystem -root $home) push-location home: ; set-location \; push-location c: ; cd $home   get-item home:, c: | select -property psdrive, root, fullname, pspath | ft -autosize  psdrive root fullname             pspath                                                     ------- ---- --------             ------                                                     home    c:\  c:\users\direkitten\ microsoft.powershell.core\filesystem::c:\users\direkitten\ c       c:\  c:\users\direkitten  microsoft.powershell.core\filesystem::c:\users\direkitten  

oh look, it's same.

tldr: providers work *-item cmdlets, else expects native windows unc path.