5

I've got a Powershell V2.0 startup script for my work computer (XP Professional 64-bit), as follows:

start "C:\Program Files (x86)\Microsoft Office\Office12\OUTLOOK.EXE" -ArgumentList "/recycle"
sleep -S 2
start "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -ArgumentList "https://mail.google.com"
sleep -S 2
start "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -ArgumentList "-new-window https://www.google.com/calendar"
sleep -S 2
start "C:\Program Files (x86)\Skype\Phone\Skype.exe"

The sleeps are to ensure that the windows appear on the taskbar in the correct order. I run this from a shortcut on my Quick Launch with the following Target:

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe C:\scripts\initialize.ps1

(Yes, this is 2.0: powershell -Version 2.0 works, as does -Version 1.0, but not -Version 3.0)

Problem is, the command window stays open until the Firefox windows are closed, which is not what I want. Looking at Process Explorer when I run the script, here's what happens:

  1. powershell.exe appears under explorer.exe and the Powershell window appears (with a black background, oddly. But it's not cmd.exe, since when I was debugging the script error messages would appear in red).
  2. outlook.exe appears under powershell.exe and the Outlook window appears.
  3. firefox.exe appears under powershell.exe and a Firefox window appears.
  4. A second firefox.exe appears under powershell.exe and another Firefox window appears. The second Firefox process then exits, as expected, since Firefox only uses one process.
  5. skype.exe appears under powershell.exe and the Skype window appears.
  6. The powershell.exe process inexplicably sticks around, as does the Powershell window.

If I close both Firefox windows, the powershell.exe process exits and the Powershell window closes, and the outlook.exe and skype.exe processes appear under explorer.exe as expected.

I suspect this has something to do with Firefox's standard input, output and error: I wouldn't expect Outlook or Skype to ever output anything to the console, but Firefox has command-line options that allow it to do so. I've looked over my about:config's user set values and didn't find anything suspicious. Finally, if I have a firefox.exe instance already running (started from the desktop shortcut) the problem doesn't occur (the powershell.exe process exits as it ought to).

So what's going on here? I'm going to try adding -WindowStyle hidden to the shortcut next (gotta close this Firefox to test it), but I want to get to the bottom of this, if only to improve my understanding of how Windows consoles work.

1
  • Try -NoNewWindow switch with firefox-es?
    – Maximus
    Commented Oct 1, 2012 at 18:27

2 Answers 2

3

Adding -WindowStyle hidden to the Target worked like a charm; the stray Powershell window is nowhere to be found, either on the taskbar or in Process Explorer. Still not sure why this issue occurred in the first place, but at least it does what it's supposed to.

1
  • A note from the future: starting the programs, not as themselves, but as arguments to explorer.exe, also helps prevent this problem. Commented Jul 9 at 0:33
1

You mention that Firefox may be keeping Standard Input, Output and/or Error open. My own tests could not reproduce your problem (i.e. the PowerShell window closes regardless), but I did notice that Firefox has quite a lot of debug output.

You could try Start-Process's redirection features to redirect Standard Output and Error to NUL (essentially, discarding output).

To do so, simply add the following two arguments to the Start-Process command:

-RedirectStandardOutput "C:\Program Files (x86)\Mozilla Firefox\NUL" -RedirectStandardError "C:\Program Files (x86)\Mozilla Firefox\components\NUL"

NB: While NUL essentially discards output, PowerShell will refuse to use the same 'file' for both Output and Error. Since NUL 'exists' in every directory, using different directories works around that - and we might as well keep it confined to the Firefox directories.

2
  • Interesting. Where did you see the debug output? I didn't actually see any; that was just a guess about what might be happening. Since -WindowStyle hidden seems to be working I'll stick with that, but something like Unix's /dev/null was something I was wishing for, so I appreciate the tip in any case. Also, I think you can use something like 2>&1 to redirect both output and error to the same file. Commented Oct 2, 2012 at 19:45
  • @MatthewPhipps I wasn't sure 2>&1 would work with Start-Process arguments (as opposed to using >NUL). The debug output comes up if I try that command in the PowerShell interpreter window - it's not blocking (i.e. I can still run other commands), but there's still output. You could also try exit at the end, I guess. If you're happy with your current method of hiding the window, you should accept your own answer.
    – Bob
    Commented Oct 3, 2012 at 0:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .