Windows Vista Forums
Vista Forums Home Join Vista Forums Windows 7 Forum Vista Tutorials Tags
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.

Go Back   Vista Forums > Misc Newsgroups > PowerShell

Vista Tutorial - Strange Ctrl-C behavior

Reply
 
Old 11-28-2007   #1 (permalink)
ebgreen
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 SpecsSystem Spec
Old 11-28-2007   #2 (permalink)
Shay Levi
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 SpecsSystem Spec
Old 11-28-2007   #3 (permalink)
Oisin Grehan
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}"
> }
Hi Ebgreen,

This is a known bug, and there are no current workarounds (AFAIK).

- Oisin / x0n
My System SpecsSystem Spec
Old 11-28-2007   #4 (permalink)
ebgreen
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 SpecsSystem Spec
Reply

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


Vista Forums is an independent web site and has not been authorized,
sponsored, or otherwise approved by Microsoft Corporation.
"Windows Vista", the Start Orb, and related materials are trademarks of Microsoft Corp.
Designer Media Ltd

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46