![]() |
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() |
| Welcome to Windows Vista Forums. Our forum is dedicated to helping you find solutions with any problems, errors or issues you are experiencing with Windows Vista. The Vista forum also covers news and updates and has an extensive Windows Vista tutorial section that covers a wide range of tips and tricks. |
| |||||||
![]() |
| |
| | #1 (permalink) |
| Guest | Strange Ctrl-C behavior Here is the scenario. I work in an environment where the users are locked down in general and admins are given an alt ID that has admin rights. As a result, I use a function (called elevate) to run powershell occasionally using my alt ID. The definition of the function is at the bottom of this post. I unfortunately did not document where I got it so I cannot give proper credit to the original author. There is a good chance that the original author reads these fora, so my apologies. The curious behavior is this. When I run a non-elevated powershell session then execute a command with a long run time, for example: Gci -Recurse -Path C:\ I can easily stop it's execution with Ctrl-C. If however I run the exact same command in a powershell session that I stared using the Elevate function (I plan to change the function name to Verb-Noun soon btw), then Ctrl-C will not stop the command execution. Has anyone else seen similar behavior? Here is the definition for the Elevate function. $ndx=0 if ($MyInvocation.PositionMessage -match 'char\d+)') { $ndx = [int]$matchesΏ] } $setDirCmd = "[Environment]::CurrentDirectory = (set-location -LiteralPath '$pwd' -PassThru).ProviderPath" $OFS = "," Write-Debug "`$MyInvocation.Line args index is $ndx; `$args are <$args>" if ($argsΎ] -is [Scriptblock]) { $script = $argsΎ] Write-Debug "Starting PowerShell with scriptblock: {$script}" start-process powershell.exe -verb runas -workingdir $pwd ` -arguments "-noexit -command & {$setDirCmd; $script}" } elseif ($argsΎ].length -gt 0) { $startProcessArgs = $MyInvocation.Line.Substring($ndx) $app = get-command $argsΎ] | select -first 1 | ? {$_.CommandType -eq 'Application'} if ($app) { $startProcessArgs = $startProcessArgs.Substring($argsΎ].Length).Trim() Write-Debug "Starting <$($app.Path)> with args: <$startProcessArgs>" start-process $app.Path -verb runas -workingdir $pwd -arguments $startProcessArgs } else { Write-Debug "Starting PowerShell with args: <$startProcessArgs>" start-process powershell.exe -verb runas -workingdir $pwd ` -arguments "-noexit -command & {$setDirCmd; $startProcessArgs}" } } else { Write-Debug "Starting Powershell without args" start-process powershell.exe -verb runas -workingdir $pwd ` -arguments "-noexit -command & {$setDirCmd}" } |
My System Specs![]() |
| | #2 (permalink) |
| Guest | Re: Strange Ctrl-C behavior It looks like the code you posted is really messed up :-) ----- Shay Levi $cript Fanatic http://scriptolog.blogspot.com Hebrew weblog: http://blogs.microsoft.co.il/blogs/scriptfanatic Quote: > Here is the scenario. I work in an environment where the users are > locked down in general and admins are given an alt ID that has admin > rights. As a result, I use a function (called elevate) to run > powershell occasionally using my alt ID. The definition of the > function is at the bottom of this post. I unfortunately did not > document where I got it so I cannot give proper credit to the original > author. There is a good chance that the original author reads these > fora, so my apologies. > > The curious behavior is this. When I run a non-elevated powershell > session then execute a command with a long run time, for example: > > Gci -Recurse -Path C:\ > > I can easily stop it's execution with Ctrl-C. If however I run the > exact same command in a powershell session that I stared using the > Elevate function (I plan to change the function name to Verb-Noun soon > btw), then Ctrl-C will not stop the command execution. Has anyone else > seen similar behavior? > > Here is the definition for the Elevate function. > > $ndx=0 > if ($MyInvocation.PositionMessage -match 'char\d+)') { > $ndx = [int]$matchesΏ] > } > $setDirCmd = "[Environment]::CurrentDirectory = (set-location > -LiteralPath '$pwd' -PassThru).ProviderPath" > > $OFS = "," > Write-Debug "`$MyInvocation.Line args index is $ndx; `$args > are > <$args>" > if ($argsΎ] -is [Scriptblock]) { > $script = $argsΎ] > Write-Debug "Starting PowerShell with scriptblock: {$script}" > start-process powershell.exe -verb runas -workingdir $pwd ` > -arguments "-noexit -command & {$setDirCmd; $script}" > } > elseif ($argsΎ].length -gt 0) { > $startProcessArgs = $MyInvocation.Line.Substring($ndx) > $app = get-command $argsΎ] | select -first 1 | ? > {$_.CommandType -eq > 'Application'} > if ($app) { > $startProcessArgs = > $startProcessArgs.Substring($argsΎ].Length).Trim() > Write-Debug "Starting <$($app.Path)> with args: > <$startProcessArgs>" > start-process $app.Path -verb runas -workingdir $pwd > -arguments > $startProcessArgs > } > else { > Write-Debug "Starting PowerShell with args: > <$startProcessArgs>" > start-process powershell.exe -verb runas -workingdir $pwd > ` > -arguments "-noexit -command & {$setDirCmd; > $startProcessArgs}" > } > } > else { > Write-Debug "Starting Powershell without args" > start-process powershell.exe -verb runas -workingdir $pwd ` > -arguments "-noexit -command & {$setDirCmd}" > } |
My System Specs![]() |
| | #3 (permalink) |
| Guest | Re: Strange Ctrl-C behavior On Nov 28, 1:55 pm, ebgreen <ebgr...@xxxxxx> wrote: Quote: > Here is the scenario. I work in an environment where the users are locked > down in general and admins are given an alt ID that has admin rights. As a > result, I use a function (called elevate) to run powershell occasionally > using my alt ID. The definition of the function is at the bottom of this > post. I unfortunately did not document where I got it so I cannot give proper > credit to the original author. There is a good chance that the original > author reads these fora, so my apologies. > > The curious behavior is this. When I run a non-elevated powershell session > then execute a command with a long run time, for example: > > Gci -Recurse -Path C:\ > > I can easily stop it's execution with Ctrl-C. If however I run the exact > same command in a powershell session that I stared using the Elevate function > (I plan to change the function name to Verb-Noun soon btw), then Ctrl-C will > not stop the command execution. Has anyone else seen similar behavior? > > Here is the definition for the Elevate function. > > $ndx=0 > if ($MyInvocation.PositionMessage -match 'char\d+)') { > $ndx = [int]$matches] > } > > $setDirCmd = "[Environment]::CurrentDirectory = (set-location > -LiteralPath '$pwd' -PassThru).ProviderPath" > > $OFS = "," > Write-Debug "`$MyInvocation.Line args index is $ndx; `$args are > <$args>" > > if ($args] -is [Scriptblock]) { > $script = $args] > Write-Debug "Starting PowerShell with scriptblock: {$script}" > start-process powershell.exe -verb runas -workingdir $pwd ` > -arguments "-noexit -command & {$setDirCmd; $script}" > } > elseif ($args].length -gt 0) { > $startProcessArgs = $MyInvocation.Line.Substring($ndx) > > $app = get-command $args] | select -first 1 | ? {$_.CommandType -eq > 'Application'} > if ($app) { > $startProcessArgs = > $startProcessArgs.Substring($args].Length).Trim() > Write-Debug "Starting <$($app.Path)> with args: > <$startProcessArgs>" > start-process $app.Path -verb runas -workingdir $pwd -arguments > $startProcessArgs > } > else { > Write-Debug "Starting PowerShell with args: <$startProcessArgs>" > start-process powershell.exe -verb runas -workingdir $pwd ` > -arguments "-noexit -command & {$setDirCmd; > $startProcessArgs}" > } > } > else { > Write-Debug "Starting Powershell without args" > start-process powershell.exe -verb runas -workingdir $pwd ` > -arguments "-noexit -command & {$setDirCmd}" > } This is a known bug, and there are no current workarounds (AFAIK). - Oisin / x0n |
My System Specs![]() |
| | #4 (permalink) |
| Guest | Re: Strange Ctrl-C behavior Thanks Oisin. The bug reports was my next stop. Guess I should have started there instead. ![]() "Oisin Grehan" wrote: Quote: > On Nov 28, 1:55 pm, ebgreen <ebgr...@xxxxxx> wrote: Quote: > > Here is the scenario. I work in an environment where the users are locked > > down in general and admins are given an alt ID that has admin rights. As a > > result, I use a function (called elevate) to run powershell occasionally > > using my alt ID. The definition of the function is at the bottom of this > > post. I unfortunately did not document where I got it so I cannot give proper > > credit to the original author. There is a good chance that the original > > author reads these fora, so my apologies. > > > > The curious behavior is this. When I run a non-elevated powershell session > > then execute a command with a long run time, for example: > > > > Gci -Recurse -Path C:\ > > > > I can easily stop it's execution with Ctrl-C. If however I run the exact > > same command in a powershell session that I stared using the Elevate function > > (I plan to change the function name to Verb-Noun soon btw), then Ctrl-C will > > not stop the command execution. Has anyone else seen similar behavior? > > > > Here is the definition for the Elevate function. > > > > $ndx=0 > > if ($MyInvocation.PositionMessage -match 'char\d+)') { > > $ndx = [int]$matchesΏ] > > } > > > > $setDirCmd = "[Environment]::CurrentDirectory = (set-location > > -LiteralPath '$pwd' -PassThru).ProviderPath" > > > > $OFS = "," > > Write-Debug "`$MyInvocation.Line args index is $ndx; `$args are > > <$args>" > > > > if ($argsΎ] -is [Scriptblock]) { > > $script = $argsΎ] > > Write-Debug "Starting PowerShell with scriptblock: {$script}" > > start-process powershell.exe -verb runas -workingdir $pwd ` > > -arguments "-noexit -command & {$setDirCmd; $script}" > > } > > elseif ($argsΎ].length -gt 0) { > > $startProcessArgs = $MyInvocation.Line.Substring($ndx) > > > > $app = get-command $argsΎ] | select -first 1 | ? {$_.CommandType -eq > > 'Application'} > > if ($app) { > > $startProcessArgs = > > $startProcessArgs.Substring($argsΎ].Length).Trim() > > Write-Debug "Starting <$($app.Path)> with args: > > <$startProcessArgs>" > > start-process $app.Path -verb runas -workingdir $pwd -arguments > > $startProcessArgs > > } > > else { > > Write-Debug "Starting PowerShell with args: <$startProcessArgs>" > > start-process powershell.exe -verb runas -workingdir $pwd ` > > -arguments "-noexit -command & {$setDirCmd; > > $startProcessArgs}" > > } > > } > > else { > > Write-Debug "Starting Powershell without args" > > start-process powershell.exe -verb runas -workingdir $pwd ` > > -arguments "-noexit -command & {$setDirCmd}" > > } > Hi Ebgreen, > > This is a known bug, and there are no current workarounds (AFAIK). > > - Oisin / x0n > |
My System Specs![]() |
![]() |
| Thread Tools | |
| |
Similar Threads | ||||
| Thread | Forum | |||
| USB Strange behavior | Network & Sharing | |||
| Strange Behavior 2 | Live Mail | |||
| More strange behavior | Live Mail | |||
| BUG: Using CTRL+W to Close Folder Window Leads to Bizarre Behavior | Vista General | |||
| strange behavior | Vista General | |||