After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 90592 - Preferred Applications: %s not stubstituted
Preferred Applications: %s not stubstituted
Status: RESOLVED OBSOLETE
Product: libgnome
Classification: Deprecated
Component: general
2.1.x
Other Linux
: High major
: ---
Assigned To: Anders Carlsson
Anders Carlsson
AES[DUPSINK]
: 98513 99257 107224 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-08-13 00:39 UTC by Brad Johnson
Modified: 2003-05-12 12:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2



Description Brad Johnson 2002-08-13 00:39:01 UTC
Description of Problem:

%s does not always seem to be replaced properly in
the command line for the web browser command (and
probably others). The problem probably has to do
with the parenthesis used in these examples:

/opt/mozilla/mozilla -remote 'openURL(%s)'
/opt/mozilla/mozilla -remote openURL\(%s\)

Although both versions of the command work fine
from a terminal, when clicking on a link in Balsa
(also tried from Gnome-terminal), Mozilla instead
tries to load 'www.%s.com'. In an attempt to
circumvent this, I wrote a small script that looks
like:

#!/bin/sh
/opt/mozilla/mozilla -remote openURL\($*\)

At which point things seem to work a lot better.
My apologies if I've filed this in the wrong spot.
I'm not sure which underlying library is
responsible for this (gnome-vfs perhaps?)
Comment 1 Luis Villa 2002-08-20 19:11:03 UTC
I think this is libgnome or something- not sure.
Comment 2 Andrew Sobala 2002-10-31 18:53:31 UTC
-maint: can someone say if this bug is really meant to be in
control-center per Luis' comment?
Comment 3 Luis Villa 2002-11-07 14:38:28 UTC
SPAM as discussed last night. Search for 'SPAM as discussed last night' to catch
these all and delete them. :) 
Comment 4 Andrew Sobala 2002-11-14 18:20:35 UTC
*** Bug 98513 has been marked as a duplicate of this bug. ***
Comment 5 Matt Selsky 2002-11-24 11:46:46 UTC
The problem is in gnome-libs-1.4.X/libgnome/gnome-url.c around line 144.

The code there is something like this:

for(i = 0; i < argc; i++) {
  if(strcmp(argv[i], "%s") == 0)
    argv[i] = (char *)url;
}

So "%s" only gets replaced if it gets picked up as a distinct item in
argv, ie you need to place spaces around it.

This works to open urls in a new tab:

gnome-moz-remote --remote=openURL( "%s" , new-tab)
Comment 6 Andrew Sobala 2002-11-24 14:37:45 UTC
Moving to libgnome then. It would be really nice to get this fixed
soon-ish.
Comment 7 Paul B 2002-12-07 21:46:44 UTC
I hope it is appropriate to make this comment here:

If I add "gnome-moz-remote --remote=openURL( "%s" , new-tab)" to
~/.gnome/Gnome, for instance in the line: 

     "default-show=gnome-moz-remote --remote=openURL( "%s" , new-tab)"

or in the line:

     "ghelp-show=gnome-moz-remote --remote=openURL( "%s" , new-tab)"

mozilla will correctly open the requested help-page or url, but always
in an new-window.

Actually, as far as I can see, any "line" in ~/.gnome/Gnome that
manages to open an page using gnome-moz-remote will always open the
url or help-page in a new window, regardless of the parameters used.
(It seems you might just as well simply use "gnome-moz-remote "%s"".)

Of course, this behaviour can hardly be considered more than a minor
bug. Do keep up the good work!
Comment 8 Andrew Sobala 2003-03-01 11:14:12 UTC
*** Bug 99257 has been marked as a duplicate of this bug. ***
Comment 9 Andrew Sobala 2003-03-01 11:14:27 UTC
*** Bug 107224 has been marked as a duplicate of this bug. ***
Comment 10 Kjartan Maraas 2003-05-03 17:26:48 UTC
There's been some work in libgnome lately in this area. Probably worth checking out the next libgnome release to see if that changes anything.
Comment 11 Kjartan Maraas 2003-05-12 12:22:36 UTC
I don't think gnome-moz-remote is there any more.