Personally, the purist in me is not too fond of the fact that Start-Process is even taking the PATH environment variable into consideration. I've always found the use of PATH to be asking for trouble and in this case, it's behavior specific to Start-Process, there's nothing about Cmdlets that suggest any particular parameter should be qualified by the PATH environment variable. If you're using Start-Process instead of invoking the exe directly at the command prompt, then you're obviously doing something more specific and you should know where the exe is located.
But having said that, if it works from the FileSystem provider, it would be more intuitive if it worked from any other provider since the idea of the PATH environment variable is to allow a name to be resolved regardless of $PWD. Not to mention, since it uses ShellExecute or CreateProcess and both of them only work on files, it seems perfectly acceptable to restrict Start-Process to the file system.
Josh Einstein
"Roman Kuzmin" <nightroman[ at ]googlemail.com> wrote in message news:ef1c338c-9a0b-426a-8d3c-094cad064bd7[ at ]a29g2000pra.googlegroups.com...
[Quoted Text] > CTP3, new cmdlet Start-Process issue > >> Set-Location hkcu:\ >> Start-Process notepad > Start-Process : Cannot open file because the current provider > (Microsoft.PowerShell.Core\Registry) cannot open a file. > ... > > What do you think: > > 1) it is a bug > 2) it is by design because PowerShell (is | will be) able to start > processes "from provider items" > 3) other thoughts?
|