[GRASS-dev] Re: [GRASS-user] g.manual tries to run C:\Program Files\Internet Exporer\iexplore (the 'L' is missing from 'Explorer')

Glynn_Clements1 · July 26, 2009, 4:40pm

Hamish wrote:

> rem Path to your web browser
> rem set
> GRASS_HTML_BROWSER=%SYSTEMDRIVE%\PROGRA~1\INTERN~1\IEXPLORE.EXE
> ...
>
> I also tried changing the above statement to:
> set GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet
> Explorer\iexplore.exe
>
> but I still got the same error.
>
> C:\OSGeo4W\etc\ini\grass.bat
> ----------------------------
> ...
> set GRASS_HTML_BROWSER=%PROGRAMFILES%\Internet
> Explorer\iexplore
> ...
>
> I can confirm that grass.bat is executed, but it also
> appears to be
> overridden by grass64.bat (I can tell because the g.manual
> error contains
> "iexplorer.exe" rather than just "iexplore").

fwiw, mswindows/GRASS-Installer.nsi in the source code sets
it to iexplore.exe

Could anyone clarify which of the following are valid arguments to
GRASS_HTML_BROWSER?

1. A native filename, e.g.:

C:\GRASS\docs\html\index.html

2. A Unix-ish filename, e.g.:

C:/GRASS/docs/html/index.html

3. A file: URL, e.g.:

file:///C:/GRASS/docs/html/index.html

4. A HTTP URL, e.g.:

http://grass.osgeo.org/

It would be much easier to set GRASS_HTML_BROWSER correctly if I knew
how it's actually meant to be used.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish · July 26, 2009, 10:03pm

Glynn Clements wrote:

Could anyone clarify which of the following are valid
arguments to GRASS_HTML_BROWSER?

1. A native filename, e.g.:
C:\\GRASS\\docs\\html\\index\.html
2. A Unix-ish filename, e.g.:
C:/GRASS/docs/html/index\.html

the above failed on ms windows, which split it into C GRASS..
and didn't know the "C" rfc protocol, and then as the first
part of :// etc.

changed to be:

3. A file: URL, e.g.:
file:///C:/GRASS/docs/html/index\.html

from gis.m AFAIR.

4. A HTTP URL, e.g.:
http://grass.osgeo.org/

I assume that would work, but I believe the goal is to have help
available on the local computer as the software could often
be used on a laptop for field work where no internet access is
available.

It would be much easier to set GRASS_HTML_BROWSER correctly
if I knew how it's actually meant to be used.

I expect exact argument usage is dependent on the browser you
give for GRASS_HTML_BROWSER.

AFAIK g.manual is now fixed on WinGrass, we just wait for new
builds to confirm.

Hamish

Glynn_Clements1 · July 27, 2009, 9:03am

Hamish wrote:

> Could anyone clarify which of the following are valid
> arguments to GRASS_HTML_BROWSER?
>
> 1. A native filename, e.g.:
>
> C:\GRASS\docs\html\index.html
>
> 2. A Unix-ish filename, e.g.:
>
> C:/GRASS/docs/html/index.html

the above failed on ms windows, which split it into C GRASS..
and didn't know the "C" rfc protocol, and then as the first
part of :// etc.

changed to be:

> 3. A file: URL, e.g.:
>
> file:///C:/GRASS/docs/html/index.html

from gis.m AFAIR.

> 4. A HTTP URL, e.g.:
>
> http://grass.osgeo.org/

I assume that would work, but I believe the goal is to have help
available on the local computer as the software could often
be used on a laptop for field work where no internet access is
available.

> It would be much easier to set GRASS_HTML_BROWSER correctly
> if I knew how it's actually meant to be used.

I expect exact argument usage is dependent on the browser you
give for GRASS_HTML_BROWSER.

That's backwards. The user doesn't get to choose what arguments it is
passed; that's built into the software.

The user (and init scripts) need to set GRASS_HTML_BROWSER according
to what it is supposed to be capable of dealing with.

And developers need to ensure that it is only passed arguments
which match what GRASS_HTML_BROWSER is documented as supporting.

But in order to do either of those things, the semantics need to be
documented. And they aren't. AFAICT, the only documentation is (from
lib/init/variables.html):

  GRASS_HTML_BROWSER
  [init.sh, wxgui]
    defines name of HTML browser. For most platforms this should be
    an executable in your PATH, or the full path to an executable

[plus some stuff about OSX.]

Apparently it should identify "an executable". Well, that doesn't
really help much.

As it stands, any and all usage of GRASS_HTML_BROWSER is a bug. It
isn't possible to use it correctly when there's no definition of
"correct".

BTW:

AFAICT, the "right" way to open files on Windows is to simply run them
via the shell, e.g. pointing GRASS_HTML_BROWSER at a batch file
containing:

@echo off
cmd /c "%1"

This will open the file via its registered command, as if it had been
double-clicked in Explorer.

For opening URLs:

@echo off
rundll32 url.dll,OpenURL "%1"

This also appears to work with filenames, with both forward and
backward slashes. However, it returns immediately, while "cmd /c ..."
waits for the command to terminate.

When the command terminates depends upon the command. For Notepad, it
means exiting Notepad. Firefox returns once it has displayed the page
if it uses an existing instance, but waits until you exit it if it has
to start a new instance.

If we can confirm that the OpenURL approach works on most versions of
Windows, we should use that for GRASS_HTML_BROWSER rather than
iexplore.exe (particularly as init.bat currently uses a hard-coded
pathname which will typically be wrong on non-English versions of
Windows; hint: use %ProgramFiles% to get the "Program Files"
directory).

--
Glynn Clements <glynn@gclements.plus.com>

marisn · July 27, 2009, 2:06pm

On Linux proper default would be calling "xdg-open file|URL".

Maris.

2009/7/27, Glynn Clements <glynn@gclements.plus.com>:

BTW:

AFAICT, the "right" way to open files on Windows is to simply run them
via the shell, e.g. pointing GRASS_HTML_BROWSER at a batch file
containing:

--
Glynn Clements <glynn@gclements.plus.com>

Colin_Nielsen_Wren · July 28, 2009, 1:11pm

The variable's value should point to a browser's exe, not the
index.html of the docs folder.

Given that, more odd behaviour of g.manual re the variable. When
running wingrass through an msys terminal (r37101)

The following all worked
export GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
export GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
export GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe
export GRASS_HTML_BROWSER="c:\Programs\Firefox\firefox.exe"
export GRASS_HTML_BROWSER="/c/Programs/Firefox/firefox.exe"

Except that it didn't release my terminal until iexplore.exe was
closed. This was not true when firefox was used instead, the terminal
was released without closing the program. (nb. on my system firefox is
in a directory without spaces but this shouldn't be the problem).

These failed:
export GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe
export GRASS_HTML_BROWSER=c:\Program Files\Internet
Explorer\iexplore.exe (no quotes)
export GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe
("c:ProgramsFirefoxfirefox.exe: command not found")
export GRASS_HTML_BROWSER="file:///c/Program Files/Internet
Explorer/iexplore.exe"
export GRASS_HTML_BROWSER="/c/Program\ Files/Internet\ Explorer/iexplore.exe"
export GRASS_HTML_BROWSER="c:/Program\ Files/Internet\
Explorer/iexplore.exe" (c:/Program\ Files/Internet\
Explorer/iexplore.exe: No such file or directory)
export GRASS_HTML_BROWSER="\c\Program Files\Internet
Explorer\iexplore.exe" (not surprisingly)

This all seems very inconsistent, but in summary for msys:
1) URLs don't work
2) Regular windows paths are fine as long as they are in quotes
3) Unix paths are fine as long as they're not in quotes (unless there
are no spaces, then its ok) and use backslash on spaces.

However, for osgeo4w (non-msys) by putting the following in the
etc/ini/grass.bat:
This worked (though it didn't work above):
set GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe

These did not work:
set GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
set GRASS_HTML_BROWSER="c:\PROGRA~1\INTERN~1\iexplore.exe"
set GRASS_HTML_BROWSER=c:\PROGRA~1\INTERN~1\iexplore.exe
set GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
set GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe

In sum, only a unix path with no quotes or space escapes will work.
This path format does not work in msys. There is no path format that I
found that works in both, clearly a problem.

AFAICT, the "right" way to open files on Windows is to simply run them
via the shell, e.g. pointing GRASS_HTML_BROWSER at a batch file
containing:
   @echo off
   cmd /c &quot;%1&quot;

If you use "cmd /k" instead of "cmd /c" it should return the terminal
without having to terminate the command.

For opening URLs:
   @echo off
   rundll32 url\.dll,OpenURL &quot;%1&quot;
This also appears to work with filenames, with both forward and
backward slashes. However, it returns immediately, while "cmd /c ..."
waits for the command to terminate.

I put the above into a batch file and it worked with the URL format,
unix and windows, but g.manual wouldn't run with this batch file with
it set as the value for GRASS_HTML_BROWSER

When the command terminates depends upon the command. For Notepad, it
means exiting Notepad. Firefox returns once it has displayed the page
if it uses an existing instance, but waits until you exit it if it has
to start a new instance.

Ahh this clears up the firefox exception above. However, when tested
on iexplore, it opens a new instance instead of adding it as a tab and
so won't return until that instance is closed.

If we can confirm that the OpenURL approach works on most versions of
Windows, we should use that for GRASS_HTML_BROWSER rather than
iexplore.exe (particularly as init.bat currently uses a hard-coded
pathname which will typically be wrong on non-English versions of
Windows; hint: use %ProgramFiles% to get the "Program Files"
directory).

I agree with Glynn, this is definitely the way to go if it can be
figured out since it would be better to use the user's preference,
already set in windows, for opening URLs. It worked on Vista, but only
by calling the batch file myself, not when it was set as the value of
GRASS_HTML_BROWSER. Perhaps because the g.manual script looks for an
exe specifically...

-Colin

Glynn_Clements1 · July 28, 2009, 2:52pm

Colin Nielsen wrote:

These failed:
export GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe
export GRASS_HTML_BROWSER=c:\Program Files\Internet Explorer\iexplore.exe (no quotes)

This is down to the "export" command terminating the value at the
first space.

export GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe
("c:ProgramsFirefoxfirefox.exe: command not found")

This is down to the shell interpreting the \ character.

Both of the above issues go away if you use single quotes, e.g.:

export 'GRASS_HTML_BROWSER=c:\Programs\Firefox\firefox.exe'

Note that I'm not concerned with the syntax for specifying the
variable's value, but the syntax of its arguments.

However, for osgeo4w (non-msys) by putting the following in the
etc/ini/grass.bat:
This worked (though it didn't work above):
set GRASS_HTML_BROWSER=/c/Program Files/Internet Explorer/iexplore.exe

Windows' "set" command treats everything after the = as the value,
regardless of any spaces, whereas bash's "export" command terminates
the value at the first unquoted/unescaped space.

As for the /c/... syntax, that will work if $GRASS_HTML_BROWSER is
being used in a bash script (e.g. g.manual), but won't work natively.

These did not work:
set GRASS_HTML_BROWSER="c:\Program Files\Internet Explorer\iexplore.exe"
set GRASS_HTML_BROWSER="c:\PROGRA~1\INTERN~1\iexplore.exe"

The "set" command will treat any quotes literally, as part of the
variable's value.

set GRASS_HTML_BROWSER=c:\PROGRA~1\INTERN~1\iexplore.exe

I suspect that this is a case of the setting setting being "correct"
rather than MSys-compatible.

set GRASS_HTML_BROWSER=c:/Program\ Files/Internet\ Explorer/iexplore.exe
set GRASS_HTML_BROWSER=/c/Program\ Files/Internet\ Explorer/iexplore.exe

Forward slashes and MSys' /c/... syntax won't work in Windows' command
interpreter. MSys' bash will convert filename syntax if it recognises
it as such.

In sum, only a unix path with no quotes or space escapes will work.
This path format does not work in msys. There is no path format that I
found that works in both, clearly a problem.

Indeed. This is why we're giving up on MSys for GRASS 7. It's
impossible to specify filenames which will work both in both MSys and
elsewhere.

> For opening URLs:
>
> @echo off
> rundll32 url.dll,OpenURL "%1"
>
> This also appears to work with filenames, with both forward and
> backward slashes. However, it returns immediately, while "cmd /c ..."
> waits for the command to terminate.

I put the above into a batch file and it worked with the URL format,
unix and windows, but g.manual wouldn't run with this batch file with
it set as the value for GRASS_HTML_BROWSER

Can you modify the script to print its arguments? And g.manual to
print out $GRASS_HTML_BROWSER.

--
Glynn Clements <glynn@gclements.plus.com>

Hamish · July 29, 2009, 1:49am

Glynn wrote:

Can you modify the script to print its arguments? And
g.manual to print out $GRASS_HTML_BROWSER.

note1 that until Maris's space-in-filename fixes in 6.5svn have been
reviewed & backported to 6.4 we may just be chasing things already
fixed and not being efficient in our use of time.

note2 until osgeo4w has a new release, diito with anything having
to do with that version.

note3 (a contingent of) the MSys devs has made it clear that they
won't even apply patches fixing spaces in pathname issues because
if it works at all they worry about being flooded with bug reports
for every GNU util they ship with etc which fails with that. I
don't really agree with that strategy, but it's their project so
whatever. I've got a conglomerate patch in their SF bug tracker
solving some core spaces in pathnames problems which Colin applies
(plus his own improvements). But AFAIK that's just the startup
stuff.

For GRASS_HTML_BROWSER, it is read in a number of contexts by e.g.
by g.manual shell script (6.x), g.manual python (7.x), wxGUI,
tcl/tk GUI, grass-run.bat, gui startups, ...

so it needs to be both cross-platform, cross-language, and cross-
environment (msys vs dos). thus IMO the only portable solution will
be to store it in the OS's native FS format and have each client
code translate downstream as needed rather than guess that up
front.

"C:\Program Files" is not portable due to i18n,
the above-mentioned MSys patch has long -> 8.3 DOS filena~1
batch file translation magic for reference, I assume python has
all the tools you need built in, tcltk can be pursuaded, ...
which leaves msys's /bin/sh.

I find msys to be too large complex to simply say "msys does or
does not support this or that" as a blanket statement.

Hamish

Glynn_Clements1 · July 29, 2009, 10:28am

Hamish wrote:

For GRASS_HTML_BROWSER, it is read in a number of contexts by e.g.
by g.manual shell script (6.x), g.manual python (7.x), wxGUI,
tcl/tk GUI, grass-run.bat, gui startups, ...

so it needs to be both cross-platform, cross-language, and cross-
environment (msys vs dos). thus IMO the only portable solution will
be to store it in the OS's native FS format and have each client
code translate downstream as needed rather than guess that up
front.

That's all well and good, but we still aren't making any progress on
the original question, i.e. what must the specified program accept as
an argument?

Until that's know, developers don't know how to use it, and users
don't know how to set it.

I find msys to be too large complex to simply say "msys does or
does not support this or that" as a blanket statement.

By "MSys", I mean the port of bash.

--
Glynn Clements <glynn@gclements.plus.com>

Colin_Nielsen_Wren · September 11, 2009, 12:09am

From the two possible WinGrass command lines (either cmd.exe or msys)

the following command will open the html index and returns the
terminal:

cmd /c "rundll32 url.dll,OpenURL "file:///C:/Program
Files/GRASS-6-SVN/docs/html/full_index.html""

I incorporated this into g.manual in a bit of an ugly fashion (see
attached patch), it works perfectly for msys but not for cmd. For cmd
it doesn't open the html and it doesn't return the terminal.
Hopefullly someone else can finish the task.

-Colin

On Wed, Jul 29, 2009 at 6:28 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Hamish wrote:

For GRASS_HTML_BROWSER, it is read in a number of contexts by e.g.
by g.manual shell script (6.x), g.manual python (7.x), wxGUI,
tcl/tk GUI, grass-run.bat, gui startups, ...

so it needs to be both cross-platform, cross-language, and cross-
environment (msys vs dos). thus IMO the only portable solution will
be to store it in the OS's native FS format and have each client
code translate downstream as needed rather than guess that up
front.

That's all well and good, but we still aren't making any progress on
the original question, i.e. what must the specified program accept as
an argument?

Until that's know, developers don't know how to use it, and users
don't know how to set it.

I find msys to be too large complex to simply say "msys does or
does not support this or that" as a blanket statement.

By "MSys", I mean the port of bash.

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

g.manual.patch (660 Bytes)