Re: Windows x86-64 One-Click Install (9.1.2-1, 9.0.6-1) hangs on "initialising the database cluster" (with work-around)

Hi Dave and Dharmendra,

It is not the "%COMSPEC% /c" call that causes the window to popup, but
the WindowStyle parameter to WShell.Run (see Table 3.9 in MS TechNet WSH
Objects / Running Programs
<http://technet.microsoft.com/en-us/library/ee156605.aspx>). Setting
WindowStyle to "0" creates a hidden window. This is how the code in the
installer is currently written. Setting it to "1" creates a visible
window. This happens when using "%COMSPEC% /c" or when calling the batch
file directly.

Here is a another site recommending
<http://classicasp.aspfaq.com/general/how-do-i-execute-a-dos-command/batch-file/exe-from-asp.html>
the use of "%COMSPEC% /c" with a "0" second parameter, along with a note
about the window (in)visibility:

"[...] do not run any command that raises a prompt, dialog, msgbox
or any other GUI. This [...] could hang your entire system (since the
invisible GUI will be waiting for a reply [...]"

Test code is attached that demonstrates using COMSPEC with a "0" versus
a "1".

Output from SET command is also attached. Note that I've verified that
this problem still occurs in Safe Mode.

Any other suggestions? I've also posted to StackOverflow
<http://stackoverflow.com/questions/9038927/vbscript-hangs-when-launching-batch-file-with-wshell-script-run>
for adivce.

A separate line of reasoning for using COMSPEC is that the calling of
the .bat directly assumes that default action is to execute the batch
file. If a user has modified their default .bat actions (which I have
not), the postgres installer will fail. Using COMSPEC will avoid that
pitfall.

I'll keep you posted if I discover why my machine doesn't execute batch
files by default, or how it ended up in this condition. The computer is
only about 2 months old, so I haven't had *that* much time to overwhelm
it with installs.

Eric

On 1/27/2012 3:15 AM, Dharmendra Goyal wrote:
> Installer works at our end without any issue.
>
> I remember we had considered using "%COMSPEC% /c" earlier but dropped
> it because command windows opens up for every new file execution.
>
> On Fri, Jan 27, 2012 at 3:40 PM, Dave Page <dpage(at)pgadmin(dot)org
> <mailto:dpage(at)pgadmin(dot)org>> wrote:
>
> iirc, using %COMSPEC% /c will cause the scripts to run in a visible
> command window, which is pretty ugly, and doesn't seem to be necessary
> anywhere except on your machine!
>
> What's the output from the "set" command on that box?
>
> On Thu, Jan 26, 2012 at 6:54 PM, Eric Borts <eborts(at)bltek(dot)com
> <mailto:eborts(at)bltek(dot)com>> wrote:
> > Also, here is a link to the same issue on StackOverflow:
> >
> http://stackoverflow.com/questions/3559719/wscript-shell-run-doesnt-work-consistently
> >
> > Also solved using %COMSPEC% /c, though it doesn't say why this
> is a problem.
> >
> > Cheers,
> > Eric
> >
> >
> > On 1/26/2012 11:37 AM, Eric Borts wrote:
> >
> > On 1/26/2012 1:17 AM, Dave Page wrote:
> >
> > Dharmendra, can you look into this please?
> >
> > Eric, is there anything unusual about the configuration of your
> > machine? Suffice it to say, this doesn't normally happen.
> >
> > Hi Dave, I'm guessing the answer to that question is "yes". The
> machine came
> > preinstalled with Norton Internet Security, but this was turned
> off when I
> > ran the install. After further investigation to the .bat file, I
> realized
> > that I am also missing the "Edit" option when I right click a
> batch file.
> >
> > I investigated, uninstalled stuff, disabled a lot of stuff in my
> registry,
> > and nearly bricked my computer. After three hours, I'm going to
> have to ask
> > for suggestions. Here's what I found/tried:
> >
> > 1. uninstalled Norton Internet Security (and rebooted)
> > 2. uninstalled Acrobat Reader
> > 3. disabled all ContextMenuHandlers by
> > a. renaming HKCR/*/shellex to oldshellex
> > b. renaming HKCR/AllFileSystemsObjects/shellex to oldshellex
> > c. tried, but was unable to rename HKCR/batfile/ShellEx, so
> renamed
> > HKCR/batfile/ShellEx/ContextMenuHandlers to oldContextMenuHandlers
> > 4. disabled all non-Microsoft shell extensions using ShellExView
> > 5. rebooted - computer bricked (black screen when Windows should
> be loading)
> > 6. booted in safe mode
> > 7. tested script (from my original response) and right click.
> > a. no Edit option in batch file context menu
> > b. script hung as before
> > 8. Undid steps 3 and 4 in safe mode
> > 9. Rebooted - booted into windows properly
> > 10. Still no Edit in context menu and script still hangs
> >
> > I'm open to suggestions. I think it might be related to Edit
> menu missing
> > from my batch file, as this is the only odd thing that I can
> tell about my
> > machine. I have another similar machine (earlier model Vaio)
> that both has
> > the Edit menu and runs the test script successfully. I compared the
> > HKCR/batfile registry trees (using TortoiseSVN diff) and they
> are identical.
> > Short of comparing the entire registry I'm at a loss.
> >
> > Would it be too dangerous to use WScript.Shell.Exec or to use
> > WScript.Shell.Run "%COMPSEC% /c" ? This has been an 11 hour
> struggle for me
> > so far, and I know at least a few others have had this same
> problem. Here is
> > a link to my work around on enterprisedb.
> >
> > Thanks,
> > Eric
> >
> > Reference Links:
> >
> http://www.pcreview.co.uk/forums/edit-print-open-missing-shell-context-menu-cmd-and-bat-files-t2551124.html
> > http://windowsxp.mvps.org/slowrightclick.htm
> > http://www.nirsoft.net/utils/shexview.html
> >
> >
>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>
>
> --
> Dharmendra Goyal
> Senior Software Engineer
> EnterpriseDB Corporation
> The Enterprise Postgres Company
>
> Phone: +91-20-30589493
> Mobile: +91-9552103323
>
> Website: http://www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
>