exec trouble
Erik Leunissen
I'm stumbling across invoking the firefox browser using [exec].
What I am trying to accomplish in Tcl is what the following shell
command does (on Linux):
> /usr/bin/firefox -remote 'openUrl(http://www.google.com,new-window)'
Assuming that a firefox instance is running, this command opens a new
browser window in which it displays the google page.
Doing (what I thought to be the equivalent in Tcl):
% exec /usr/bin/firefox -remote "openUrl(http://www.google.com,new-window)"
results in the following error, returned by firefox:
Error: Failed to send command: 500 command not parseable
Upon this error, I tried various quoting alternatives:
% exec /usr/bin/firefox -remote 'openUrl(http://www.google.com,new-window)'
Error: Failed to send command: 500 command not parseable
% exec /usr/bin/firefox -remote {openUrl(http://www.google.com,new-window)}
Error: Failed to send command: 500 command not parseable
% exec /usr/bin/firefox -remote
"'openUrl(http://www.google.com,new-window)'"
Error: Failed to send command: 500 command not parseable
I'm stuck.
Is this behaviour reproducible? If so, what's wrong?
For your information:
% info patch
8.4.16
% exec /usr/bin/firefox -v
Mozilla Firefox 2.0.0.8, Copyright (c) 1998 - 2007 mozilla.org
% exec uname -orm
2.6.18.8-0.7-default i686 GNU/Linux
Thanks in advance,
Erik Leunissen
--
leunissen@ nl | Merge the left part of these two lines into one,
e. hccnet. | respecting a character's position in a line.
Uwe Klein
works like a charm: SuSE 9.3, tcl 8.4.9 Mozilla Firefox 1.0.7,
firefox 2.0.0.2 on another remote machine does not start up, sorry.
uwe
Ralf Fassel
| % exec /usr/bin/firefox -remote "openUrl(http://www.google.com,new-window)"
| %
| works like a charm: SuSE 9.3, tcl 8.4.9 Mozilla Firefox 1.0.7,
| firefox 2.0.0.2 on another remote machine does not start up, sorry.
FWIW, on Opensuse 10.2:
$ tclsh
% info patchlevel
8.4.14
% exec /usr/bin/firefox -v
Mozilla Firefox 2.0.0.8, Copyright (c) 1998 - 2007 mozilla.org
% exec /usr/bin/firefox -remote "openUrl(http://www.google.com,new-window)"
%
No problem here either...
R'
Isaac Raway
Works for me. 8.4 on Ubuntu 7.04 with FireFox 2.0.0.3
IJr
Erik Leunissen
Indeed a tclsh, launched from a terminal behaves as expected. However,
if the command is issued from a tkcon console which was launched from
the KDE panel, the error message as I specified in my previous message,
is returned.
The crucial difference appears to be whether the process that issues the
firefox invocation (tclsh, tkcon, wish app, ...), has a controlling
terminal or not. If it is launched from the KDE panel, it doesn't unless
one explicitly indicates otherwise:
If I toggle the checkbutton for "run in a terminal window" in the KDE
panel option, then tkcon is launched with a controlling terminal, and
the firefox invocation succeeds as expected.
I hope that my idiom has been appropriate, because I'm not at all
familiar with terminals. consoles, background/foreground processes.
Is there anybody out there who is more experienced in this area, and who
can explain the behaviour that I observe, and possibly if this behaviour
is to be expected, or if it is a bug (on the part of firefox or Tcl or ...).
Thanks in advance,
Erik
====
For all clarity, here is how to reproduce the error:
1. launch firefox
2. launch tkcon "without a controlling terminal", e.g. from the panel of
your desktop (I use KDE). You do this by leaving the panel option "run
in a terminal window" unchecked.
3. issue at the prompt:
exec /usr/bin/firefox -remote openUrl(http://www.google.com,new-tab)
Launching tkcon in step 2 with a terminal attached, will produce the
desired, non-erroneous behaviour.
Erik Leunissen
> Thanks Uwe. Your response made me look into another direction:
>
Oh, and all the others who replied in the meantime!
Alexandre Ferrieux
>
> Is there anybody out there who is more experienced in this area, and who
> can explain the behaviour that I observe, and possibly if this behaviour
> is to be expected, or if it is a bug (on the part of firefox or Tcl or ...).
I'm not experienced in this precise area, but in such situations, with
a strong suspscion of OS trickery, I'd give a try to strace. First,
try
exec strace -f -o /tmp/tra firefox -remote openurl(...) 2>@ stderr
Then do the same in the pty-controlled case, and see where the traces
diverge.
-Alex
Synic
> I'm stumbling across invoking the firefox browser using [exec].
This is what I use:
================================
proc urlOpen {url} {
global env tcl_platform
switch [tk windowingsystem] {
"x11" {
if {![info exists env(BROWSER)]} { set env(BROWSER) [findBrowser] }
if {[catch {exec $env(BROWSER) -remote $url}]} {
# perhaps browser doesn't understand -remote flag
if {[catch {exec $env(BROWSER) $url &} emsg]} { tk_messageBox -type ok -message "Please visit URL: $url" }
}
}
"win32" {
if {$tcl_platform(os) == "Windows NT"} {
set rc [catch {exec $env(COMSPEC) /c start $url &} emsg]
} else {
# Windows 95/98
set rc [catch {exec start $url &} emsg]
}
if {$rc} { tk_messageBox -type ok -message "Please visit URL: $url" }
}
"aqua" {
# Crunch goes the formatting.
if {[catch { AppleScript execute "tell application \"Safari\"
activate
open location \"$url\"
end tell"} emsg] } { tk_messageBox -type ok -message "Please visit URL: $url" }
}
}
}
==============================
I'm pretty sure a lot of that is sourced from the Wiki. No doubt
any/all horrible cruft is attributable to me :-).
> I'm stuck.
Hope this helps.
Glenn Jackman
Interesting. I'll have to study that a bit.
I have an app in which I do:
# how to launch a url
proc = x {set x}
set launch_url [auto_execok [switch -glob $tcl_platform(os) {
Darwin { = open }
"Windows *" { = start }
default { = netscape }
}]]
#...
eval exec $::launch_url "" $url &
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
Erik Leunissen
> I'm not experienced in this precise area, but in such situations, with
> a strong suspscion of OS trickery, I'd give a try to strace. First,
> try
>
> exec strace -f -o /tmp/tra firefox -remote openurl(...) 2>@ stderr
>
> Then do the same in the pty-controlled case, and see where the traces
> diverge.
>
Hello Alexandre,
I did as you indicated. I've got strace output files for the two
different cases, and I produced a diff from them. Interpreting the
differences is tricky, because of my lack of experience with system
calls and process management. Therefore, drawing conclusions is hardly
possible for me.
One particular part in the diff did draw my attention. I present it here
(please note that to produce a usable diff, I needed to replace the
PID's in the first column of both files, using "PID1", "PID2", etc. for
the subsequent process ID's):
--- strace_noterm.pidrepl.out 2007-10-24 23:00:27.000000000 +0200
+++ strace_withterm.pidrepl.out 2007-10-24 23:02:39.000000000 +0200
[snipped some lines ... ]
-PID1 open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = -1 ENXIO (No
such device or address)
-PID1 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf8339f8) = -1 ENOTTY
(Inappropriate ioctl for device)
+PID1 open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
+PID1 close(3) = 0
I interpret that as:
- process with PID1, launched without a controlling terminal, tries to
open /dev/tty and fails.
- process with PID1, launched with a controlling terminal, tries to open
/dev/tty and succeeds.
From a previous line in the diff:
+PID1 execve("/usr/bin/firefox", ["firefox", "-remote",
"openurl(http://wiki.tcl.tk/0.htm"..., "stderr"], [/* 90 vars */]) = 0
, I assume that PID1 stands for firefox (am I correct?).
All this might be significant, but it doesn't lead *me* to conclusions
w.r.t. whether any process is misbehaving. I also cannot tell whether
this difference is causing the observed error.
If you believe that you can conclude more out of such a diff, and if you
are in a position to do so, I'm happy to send it (to the newsgroup or to
an email adress). Gzipped size: almost 50 kB.
Best regards,
Erik
Alexandre Ferrieux
> If you believe that you can conclude more out of such a diff, and if you
> are in a position to do so, I'm happy to send it (to the newsgroup or to
> an email adress). Gzipped size: almost 50 kB.
Hi Erik,
I'd be happy to try to help you.
Please send it to my Gmail address.
-Alex
Alexandre Ferrieux
I've looked at your files, and I'm baffled.
What I understand is the following:
1) The fatal "500 command not parseable" is not an immediate
consequence of the failing open(/dev/tty): many things happen in
between.
The offending line is near the end of the noterm file:
...
7505 read(6, "\34?\6\10\243\0 \3\366\1\0\0W`
\1\1\0\0\0\0\0\0\0\0\243"..., 32) = 32
7505 write(6, "\24\1\6\0\243\0 \3\366\1\0\0\37\0\0\0\0\0\0\0\0@
\0\0", 24) = 24
7505 read(6, "\34\324\7\10\243\0 \3\366\1\0\0X`
\1\1\1\0\0\0\0\0\0\0\0"..., 32) = 32
7505 read(6,
"\1\10\7\10\7\0\0\0\37\0\0\0\0\0\0\0\31\0\0\0\0\0\0\0\0"..., 32) = 32
7505 readv(6, [{"500 command not parseable", 25}, {"\0\0\0", 3}],
2) = 28
When crawling up from that point, we can only see that 6 is the X11
socket, and dozens of pages of binary exchanges embody the X-heavy
setup of the firefox GUI I guess.
So, my bet is that the lack of a /dev/tty indirectly triggers a
sequence of events that later uncovers a latent bug or
misconfiguration of the app / X server / xrdb / wm ...
If you can afford the time, the natural next steps would be to:
(1) Try the same comparison (with or without tty) on a remote X
display, with a completely different X setup (eg a Solaris or Exceed,
or a different version of XFree)
(2) If it still misbehaves, use a protocol analyzer like tethereal on
the wire in between. With luck, the offending primitive/parameter may
show up on the human-readable message summaries.
(3) Try inserting xscope between firefox and the X server. There
you'll see the offending message.
(4) Once you know its name, GIYF :-)
Good luck,
-Alex
Erik Leunissen
> So, my bet is that the lack of a /dev/tty indirectly triggers a
> sequence of events that later uncovers a latent bug or
> misconfiguration of the app / X server / xrdb / wm ...
>
Thanks for your analysis Alex: highly appreciated.
Just to be sure: when you say "app", did you mean "firefox" here, or do
you mean to exclude firefox from the equation? (see below for my own
suspicion).
> If you can afford the time, the natural next steps would be to:
>
Yes, I intend to pursue this a few steps further.
All along, I've had a gut feeling which does *not* focus on firefox as
the culprit:
The observed error did not occur a few months ago, and that may be
attributable to a complete upgrade of my Linux distribution (SuSE9.0 =>
SuSE10.2), which of course brings along a new X server, and KDE desktop
(including wm). I suspect one of these components, but have little idea
about how they interact with firefox. "The desktop" is a quite large
concoction of functionality, and it is not so clear to me which parts of
it interact with firefox (maybe it's just the window manager: KWM).
Thanks also for your suggestions for further investigation. Something
along the lines of your suggestion (1) had also crossed my mind, but I
was still unsure about that being the right track.
For now, it seems to me quite an undertaking to provide the necessary
variation for a proper test-setup myself (the combinations of different
X version, different version of KWM, different desktop altogether).
Therefore, I'm thinking about a setup that involves the participation of
others (in this newsgroup?), and use whatever combinations are they have
installed.
Still brooding ...
To be continued ...
Erik.
> (1) Try the same comparison (with or without tty) on a remote X
> display, with a completely different X setup (eg a Solaris or Exceed,
> or a different version of XFree)
>
> (2) If it still misbehaves, use a protocol analyzer like tethereal on
> the wire in between. With luck, the offending primitive/parameter may
> show up on the human-readable message summaries.
>
> (3) Try inserting xscope between firefox and the X server. There
> you'll see the offending message.
>
> (4) Once you know its name, GIYF :-)
>
> Good luck,
>
> -Alex
>
Alexandre Ferrieux
>
> Just to be sure: when you say "app", did you mean "firefox" here, or do
> you mean to exclude firefox from the equation? (see below for my own
> suspicion).
Sorry - I meant firefox. But its down-to-the-details X behavior may
largely be a result of local customization (themes), not to mention
its interaction with the window manager.
Come to think of it, couldn't the lack of /dev/tty switch on a new
toplevel window to display error messages ?
It would explain everything you witnessed by saying there's buggy code
in a seldom-used branch of firefox -- but not excuse it :-)
Another random thought: look at the system-wide console (dmesg), or at
the console from which you started X (typically Ctrl-Alt-F1). IIRC the
X server sometimes complains there; the error messages may not be
crystal-clear, but could at least steer the inverstigation.
> All along, I've had a gut feeling which does *not* focus on firefox as
> the culprit:
>
> The observed error did not occur a few months ago, and that may be
> attributable to a complete upgrade of my Linux distribution (SuSE9.0 =>
> SuSE10.2), which of course brings along a new X server, and KDE desktop
> (including wm). I suspect one of these components, but have little idea
> about how they interact with firefox. "The desktop" is a quite large
> concoction of functionality, and it is not so clear to me which parts of
> it interact with firefox (maybe it's just the window manager: KWM).
As usual, when a 2-party exchange breaks when you upgrade one of the
two, it can be either that the new one is buggy, or that the not-
modified one has been buggy all the time, but the other was unduly
tolerant ;-)
> Thanks also for your suggestions for further investigation. Something
> along the lines of your suggestion (1) had also crossed my mind, but I
> was still unsure about that being the right track.
>
> For now, it seems to me quite an undertaking to provide the necessary
> variation for a proper test-setup myself (the combinations of different
> X version, different version of KWM, different desktop altogether).
> Therefore, I'm thinking about a setup that involves the participation of
> others (in this newsgroup?), and use whatever combinations are they have
> installed.
I realize that all this can generate *hours* of sweat.
However, an isolated trial of (1) takes seconds: just select a machine
on your LAN that has another X version / OS / wm, set DISPLAY to it,
and run your test.
-Alex
Erik Leunissen
> On Oct 26, 5:56 pm, Erik Leunissen <l...@the.footer.invalid> wrote:
>
> Come to think of it, couldn't the lack of /dev/tty switch on a new
> toplevel window to display error messages ?
> It would explain everything you witnessed by saying there's buggy code
> in a seldom-used branch of firefox -- but not excuse it :-)
>
> Another random thought: look at the system-wide console (dmesg), or at
> the console from which you started X (typically Ctrl-Alt-F1). IIRC the
> X server sometimes complains there; the error messages may not be
> crystal-clear, but could at least steer the inverstigation.
>
Checked that: all quiet there (while performing a terminal-deprived launch).
> ...
> I realize that all this can generate *hours* of sweat.
> However, an isolated trial of (1) takes seconds: just select a machine
> on your LAN that has another X version / OS / wm, set DISPLAY to it,
If that were readily available ...
I do have another networked machine, but I'd need to install/configure a
another Linux distro on it first.
Still brooding ...
Thanks,
Erik
> and run your test.
Erik Leunissen
Alexandre Ferrieux and Ralf Fassel, I've come to the preliminary
conclusion that this is an issue with Firefox2.0.0.8, which is not
present in Firefox 2.0.0.7.
It has nothing to do with Tcl or [exec] or quoting of arguments.