8.5 Windows XP "exec <cmd> &"--mSoft Word and Adobe PDF hang (not Firefox)

[raz...@gmail.com]

I create commands for "exec <cmd> &" invocation from the "Open"
strings in the Windows registry.

I'll show some consoles. Here's an invocation of Firefox that works
wonderfully:

------------- start console -------------
XW,3.09,ttimes9,3,0 -> h -b lookup
Launching...eval exec -ignorestderr C:\\PROGRA~1\\MOZILL~1\
\FIREFOX.EXE -url "file:///J:/xword/help/lookup.html" -requestPending
&
Done.

XW,3.09,ttimes9,3,1 ->
------------- start console -------------

(Note the debug output of the command being executed.(after
"Launching...").)

This works fine.

But this one hangs:

------------- start console -------------
XW,3.09,ttimes9,3,1 -> h -p 000
Launching...eval exec -ignorestderr "C:\\Program Files\\Adobe\\Acrobat
7.0\\Acrobat\\Acrobat.exe" "J:\\xword\\docs\\MSAdobeDocs\
\000_TitlePage.pdf" &
Done.

XW,3.09,ttimes9,3,2 ->
------------- start console -------------

The app comes up, the file even loads, but then I get the hourglass,
and wind up having to ask the system to end the task ("End Now"), and
then have to deal with the followup system dialog request to report
the crash to headquarters.

Ditto with Word:

------------- start console -------------
XW,3.09,ttimes9,3,3 -> h -d 000
Launching...eval exec -ignorestderr "C:\\Program Files\\Microsoft
Office\\Office10\\WINWORD.EXE" /n /dde J:\\xword\\docs\\MSAdobeDocs\
\000_TitlePage.doc &
Done.

XW,3.09,ttimes9,3,4 ->
------------- start console -------------

Actually, this time, 1) I just get that standard Office app "splash
panel", which hoses up and doesn't refresh when other windows move in
front of it; then 2) when the tclsh is exited, a Word window comes up,
but I get a funky dialog telling me the file opened badly the last
time and asking if want to proceed to open it now, If I say "OK", then
the doc is NOT loaded, and once again the app hangs, necessitating a
system "End Now" operation to clean things up.

I'll bet this is old hat to someone out there!

I'll haunt the newsgroup, but please feel free to write:
raz...@gmail.com

-raz

[Roy Terry]

What's the line above ^^^^^?

> Launching...eval exec -ignorestderr "C:\\Program Files\\Microsoft
> Office\\Office10\\WINWORD.EXE" /n /dde J:\\xword\\docs\\MSAdobeDocs\
> \000_TitlePage.doc &
> Done.

What would that eval be doing for you? Looks like that's the
trouble. If not...

My straight trial of
exec "C:/Program Files/Microsoft Office/Office/winword.exe"
sysSetupNewComputer-Howto.doc &

worked fine. and my 8.5a5 won't accept -ignorestderr. Not much
to suggest besides simplifying until it works. Perhaps if you
explained /n and /dde that would help others understand. BTW,
you really don't need to keep using the double backslash.

Roy

[raz...@gmail.com]

Roy,

Thanks!

I use eval and "backslash hell" because I get the command from the
registry (a "horse's mouth" approach), process it to swap in Windows
environment variables ("%var%") and the target file to Open ("%1", or
tacked onto the ending) and hold it all in a string. Using 'eval' is
the only way I can think of to get the 'exec' to see the separate
parameters.

The /n and /dde come from the Open string in the registry for Word.
I guess I could try stripping them out...but it seems dirty; I want to
try and take all my cues from the registry.

Your suggestions are encouraging; I'll look again at how I can
simplify this. But, with respect to the idea that I'm somehow
confusing matters by fibbergidgetting with backslashes and all
that...don't forget that Firefox works OK. It's only Word and Adobe
that're giving me grief. So the underlying methodology to prep
registry Open strings for passing to the exec (via eval) appears to be
fundamentally sound.

In fact, when you think of it, this is sort of what happens when you
double-click on a file icon; the system gets the string from the
registry, does the substitutions, and then the system has to do a
simple parse to identify individual parameters; sort of like an
'eval'.

If yr curious, here's the code:

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # # # #
#
# Sic an exec of some sort on a file.
#
proc runTheExec {__thefile runexec} {

global env Env

if {![string length [set bstr $runexec]]} { return 1 }

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# # #
#
# First, normalize everything.
#
set __thefile [file normalize $__thefile]

# Convert the filename to a URL, if indicated.
#
if {[string match {.html} [file extension $__thefile]]} {
set __thefile "file:///$__thefile"
} else {
set __thefile [file nativename $__thefile]
}

# Substitute any weird, windowy "parameter one" var with a proper
var.
#
if {[regsub {%1} $bstr "\$__thefile" newbstr]} {
set bstr $newbstr
} else {
set bstr "$bstr $__thefile"
}

# Continuing in this vein, find any/all windowy env vars and swap
# them out with proper vars.
#
while {[regexp {^([^%]+?)(%[^%]+?%)(.*)} $bstr ta pre var post]} {
set bstr "$pre\$env([string range $var 1 end-1])$post"
}

# Perform variable substitutions.
#
set bstr [subst -nobackslashes -nocommands $bstr]

# Prepare for EVAL BACKSLASH HELL!!!
#
regsub -all {\\} $bstr {\\\\} bstr

# That's it! Let's rock'n'roll!
#
puts -nonewline {Launching...}; flush stdout

puts "eval exec -ignorestderr $bstr &"
eval exec -ignorestderr $bstr &

puts {Done.}

return 0
}

[Alexandre Ferrieux]

On Jun 24, 12:11 pm, raza...@gmail.com wrote:
>
> I use eval and "backslash hell" because I get the command from the

> registry ...

Then the whole string coming from the registry is likely to be
suitable for "cmd /c":

exec cmd /c $that_ugly_string_untouched &

-Alex

[David Gravereaux]

In boiled down form, you want to use Win32's ShellExecute() rather than
CreateProcess(). [exec] uses CreateProcess() for setting up pipe communication,
but you don't need that service. ShellExecute also does the registry lookup for
you based on extension type. IOW, If I ShellExecute() "C:/whatever/someFile.txt",
the default application is opened for that file to handle that type -- probably
notepad, in this case.

I wrote an extension with that in it a number of years ago:
http://tomasoft.cvs.sourceforge.net/*checkout*/tomasoft/winutils/winutils.html?revision=1.15#shell
http://sourceforge.net/project/showfiles.php?group_id=1616&package_id=2092

You might also be able to get away with:
exec {*}[auto_execok start] {*}$cmdline

As start.exe (or the built-in command based on OS feature) is a connection to
ShellExecute()

--
This game lends itself to certain abuses.
--- Calvin

[Alexandre Ferrieux]

On Jun 25, 12:37 am, David Gravereaux <davyg...@pobox.com> wrote:
>
> You might also be able to get away with:
> exec {*}[auto_execok start] {*}$cmdline

David, what's wrong with

exec cmd /c $cmdline &

?
(assuming cmdline starts with an executable name -- I'm deliberately
avoiding the extra extension-lookup mechanism of 'start' here)

-Alex

[David Gravereaux]

1) On Win98, the shell is command.com, [auto_execok] takes care of that.
2) On XP anyways, that works great. On Win2k, I don't think you get the same
behavior.

(Desktop) 4 % exec cmd.exe /c WinDebug.txt &
2784
(Desktop) 5 % exec cmd.exe /c vid-02-02.mpg &
3248
(Desktop) 6 % exec cmd.exe /c TclDemo.zip &
292
(Desktop) 7 % parray tcl_platform
set tcl_platform(os) {Windows NT}
set tcl_platform(osVersion) 5.1
...

--
"I'm a simple man with complex tastes." -Calvin

[raz...@gmail.com]

> signature.asc
> 1KDownload

David,

Thanks very much for the guidance.

I've got this:

set __thefile [file nativename [file normalize $__thefile]]

puts -nonewline {Launching...}; flush stdout

exec -ignorestderr cmd.exe /c $__thefile &
puts {Done.}

It *should* work, except that the child process (say, launching a
*.doc in Word) is hosed and won't initialize, then kicks in when the
invoking tclsh exits. This is consistent with all apps (Word(doc)/
Adobe(pdf)/Firefox(hmtl)). Do I need to redirect I/O or something?

Agin, thanks bunches! I'm getting closer and closer to something
perfectly simple and perfectly effective.

-raz