9:55 a.m.
================================================================
Dear Bug Team!
Evaluating `M-x browse-url RET http://www.xemacs.org RET'
produces the following backtrace (when `stack-trace-on-error' is
activated):
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (process-error "Running ShellExecute" "Das
System kann die angegebene Datei nicht finden.
" "open" "http://www.xemacs.org")
mswindows-shell-execute("open" "http://www.xemacs.org")
browse-url-default-windows-browser("http://www.xemacs.org" nil)
apply(browse-url-default-windows-browser "http://www.xemacs.org" nil)
#<compiled-function (url &rest args) "...(24)" [url
browse-url-new-window-flag browse-url-browser-function args functionp apply done
(byte-code " Å « ＠Æ ＠\n\"«Ç A\n#ÈÉÊ\" A¬d*ËÌ\n\"" ... 5)] 4
("d:\\Src\\Build\\Beta\\xemacs-packages\\lisp\\mail-lib\\browse-url.elc" .
18794) (browse-url-interactive-arg "URL:
")>("http://www.xemacs.org" nil)
call-interactively(browse-url)
command-execute(browse-url t)
execute-extended-command(nil)
call-interactively(execute-extended-command)
(dispatch-event "[internal]")
--8<---------------cut here---------------end--------------->8---
The localized error message of the first line means in English,
that the system could not find the specified file.
Regards,
Franz.
================================================================
System Info to help track down your bug:
---------------------------------------
OS version:
Microsoft Windows XP [Version 5.1.2600]
OS: Windows_NT
XEmacs 21.5-b22 "cucumber" (+CVS-20051013) configured for `i586-pc-win32'.
Building XEmacs using "nmake".
Building XEmacs using make flags "A ".
Building XEmacs in source tree "d:\\Src\\xemacs-21.5".
For src, using compiler "cl -nologo -W3 -DSTRICT -Zi -Od -MDd -c -TP
-Id:\Src\xemacs-21.5\nt\inc -Id:\Src\xemacs-21.5\src
-I"D:\Src\optional-libs\xpm-3.4k"
-I"D:\Src\optional-libs\xpm-3.4k\lib"
-I"D:\Src\optional-libs\libpng-1.2.8"
-I"D:\Src\optional-libs\zlib-1.2.3"
-I"D:\Src\optional-libs\tiff-3.7.4\libtiff"
-I"D:\Src\optional-libs\jpeg-6b"
-I"D:\Src\optional-libs\compface-1.5.1"
-I"D:\Src\optional-libs\zlib-1.2.3" -DHAVE_MS_WINDOWS -DHAVE_MENUBARS
-DHAVE_SCROLLBARS -DHAVE_TOOLBARS -DHAVE_WIDGETS -DHAVE_DIALOGS -DHAVE_XPM -DFOR_MSW
-DHAVE_GIF -DHAVE_PNG -DHAVE_TIFF -DHAVE_JPEG -DHAVE_XFACE -DHAVE_ZLIB -DHAVE_NATIVE_SOUND
-DMULE -DERROR_CHECK_ALL -DPDUMP -DUSE_KKCC -DMC_ALLOC -DSYSTEM_MALLOC -DDEBUG_XEMACS
-D_DEBUG -DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs -DHAVE_CONFIG_H
-DPATH_VERSION=\"21.5-b22\" -DPATH_PROGNAME=\"xemacs\"
-DEMACS_VERSION=\"21.5-b22\" -DEMACS_PROGNAME=\"xemacs\"
-DSTACK_TRACE_EYE_CATCHER=xemacs_21_5_b22_i586_pc_win32 -DPATH_PREFIX=\"..!
\" -DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSION=22
-DXEMACS_CODENAME=\""cucumber"\"
-DXEMACS_EXTRA_NAME=\"(+CVS-20051013)\"
-DEMACS_CONFIGURATION=\"i586-pc-win32\"
-DPATH_PACKAGEPATH=\""~\\.xemacs;;D:\\Src\\Build\\Beta\\site-packages;D:\\Src\\Build\\Beta\\mule-packages;D:\\Src\\Build\\Beta\\xemacs-packages"\"".
For lib-src, using compiler "cl -nologo -W3 -DSTRICT -Zi -Od -MDd
-Id:\Src\xemacs-21.5\lib-src -Id:\Src\xemacs-21.5\src -DHAVE_CONFIG_H
-DWIN32_NATIVE".
Compiling as C++.
Installing XEmacs in "D:\\Src\\Build\\Beta\\XEmacs-21.5-b22".
Package path is
"~\\.xemacs;;D:\\Src\\Build\\Beta\\site-packages;D:\\Src\\Build\\Beta\\mule-packages;D:\\Src\\Build\\Beta\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in international (MULE) support.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for GZIP compression/decompression.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library.
Compiling in extra internal error-checking.
NOTE: ---------------------------------------------------------
NOTE: Compiling in support for runtime error-checking.
NOTE: XEmacs will run noticeably more slowly as a result.
NOTE: Error-checking is on by default for XEmacs beta releases.
NOTE: ---------------------------------------------------------
Compiling in debugging support (no slowdown).
Using new experimental GC algorithms.
Using new experimental allocator.
Load-Path Lisp Shadows:
----------------------
(d:\Src\Build\XEmacs\site-packages\lisp\auctex\prv-xemacs
d:\Src\Build\XEmacs\site-packages\lisp\preview\prv-xemacs
d:\Src\Build\XEmacs\site-packages\lisp\auctex\preview
d:\Src\Build\XEmacs\site-packages\lisp\preview\preview
d:\Src\Build\XEmacs\site-packages\lisp\auctex\toolbar-x
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\toolbar-x
d:\Src\Build\XEmacs\site-packages\lisp\auctex\texmathp
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\texmathp
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex-mik
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex-mik
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex-info
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex-info
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex-fold
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex-fold
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex-buf
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex-buf
d:\Src\Build\XEmacs\site-packages\lisp\auctex\tex-bar
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\tex-bar
d:\Src\Build\XEmacs\site-packages\lisp\auctex\multi-prompt
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\multi-prompt
d:\Src\Build\XEmacs\site-packages\lisp\auctex\latex
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\latex
d:\Src\Build\XEmacs\site-packages\lisp\auctex\font-latex
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\font-latex
d:\Src\Build\XEmacs\site-packages\lisp\auctex\context
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\context
d:\Src\Build\XEmacs\site-packages\lisp\auctex\context-nl
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\context-nl
d:\Src\Build\XEmacs\site-packages\lisp\auctex\context-en
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\context-en
d:\Src\Build\XEmacs\site-packages\lisp\auctex\bib-cite
d:\Src\Build\Beta\xemacs-packages\lisp\auctex\bib-cite
d:\Dokumente und
Einstellungen\haeuslsc\.xemacs\xemacs-packages\lisp\flyspell
d:\Src\Build\Beta\xemacs-packages\lisp\text-modes\flyspell
d:\Src\Build\Beta\mule-packages\lisp\mule-base\viet-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\viet-util
d:\Src\Build\Beta\mule-packages\lisp\mule-base\korea-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\korea-util
d:\Src\Build\Beta\mule-packages\lisp\mule-base\japan-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\japan-util
d:\Src\Build\Beta\mule-packages\lisp\mule-base\ethio-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\ethio-util
d:\Src\Build\Beta\mule-packages\lisp\mule-base\cyril-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\cyril-util
d:\Src\Build\Beta\mule-packages\lisp\mule-base\china-util
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\mule\china-util
d:\Src\Build\Beta\mule-packages\lisp\mule-ucs\unicode
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\unicode
d:\Src\Build\Beta\xemacs-packages\lisp\xemacs-base\regexp-opt
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\regexp-opt
d:\Src\Build\Beta\xemacs-packages\lisp\xemacs-base\easy-mmode
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\easy-mmode
d:\Src\Build\Beta\xemacs-packages\lisp\build\build-report
d:\Src\Build\Beta\XEmacs-21.5-b22\lisp\build-report)
Installed XEmacs Packages:
-------------------------
(auctex ver: 2005.0929 upstream: 2005-09-29)
Features:
--------
(footnote ispell gnus-topic nndraft nnmh bbdb-gnus bbdb-snarf
mail-extr gnus-demon gnus-cite gnus-agent gnus-srvr gnus-score
score-mode nnvirtual nntp gnus-cache spam spam-stat bbdb-com
hashcash gnus-uu xemacsbug shadow efs-cu debug thingatpt
browse-url font disp-table tex advice advice-preload timer-funcs
lazy-lock paren blink-paren smtpmail gnuserv bbdb regexp-opt
timezone sgml-mode psgml bs x-iso8859-1 x-compose crypt crypt++
font-lock pending-del backup-dir boxquote rect filladapt tex-mik
gnus-msg gnus-art mm-uu mml2015 pgg password pgg-parse pgg-def
mm-view gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
format-spec gnus-start gnus-spec gnus-int gnus-range gnus-win
gnus gnus-ems gnus-xmas wid-edit message messagexmas cus-face mml
mml-sec mml-smime smime dig mm-decode mm-bodies mm-encode mailcap
lpr mail-parse rfc2045 rfc2231 rfc2047 qp ietf-drums mail-abbrevs
sendmail rfc822 nnheader nnheaderxm gnus-util netrc time-date
parse-time mm-util mail-prsvr mail-utils mailheader canlock sha1
executable hex-util skk-autoloads mule-ucs-autoloads
mule-base-autoloads lookup-autoloads leim-autoloads
latin-unity-autoloads egg-its-autoloads edict-autoloads
zenirc-autoloads xwem-autoloads xslt-process-autoloads
xslide-autoloads xlib-autoloads xetla-autoloads
xemacs-devel-autoloads xemacs-base-autoloads x-symbol-autoloads
w3-autoloads vm-autoloads viper-autoloads view-process-autoloads
vhdl-autoloads vc-autoloads tramp-autoloads tpu-autoloads
tm-autoloads time-autoloads textools-autoloads
text-modes-autoloads texinfo-autoloads supercite-autoloads
strokes-autoloads speedbar-autoloads slider-autoloads
sieve-autoloads sh-script-autoloads sgml-autoloads
semantic-autoloads scheme-autoloads ruby-modes-autoloads
rmail-autoloads riece-autoloads reftex-autoloads
re-builder-autoloads python-modes-autoloads psgml-autoloads
ps-print-autoloads prog-modes-autoloads pgg-autoloads
perl-modes-autoloads pcomplete-autoloads pcl-cvs-autoloads
pc-autoloads os-utils-autoloads oo-browser-autoloads
ocaml-autoloads net-utils-autoloads misc-games-autoloads
mine-autoloads mh-e-autoloads mew-autoloads mailcrypt-autoloads
mail-lib-autoloads liece-autoloads jde-autoloads ispell-autoloads
ilisp-autoloads igrep-autoloads idlwave-autoloads
ibuffer-autoloads hyperbole-autoloads hm--html-menus-autoloads
haskell-mode-autoloads gnus-autoloads gnats-autoloads
games-autoloads fsf-compat-autoloads fortran-modes-autoloads
forms-autoloads footnote-autoloads eudc-autoloads eterm-autoloads
ess-autoloads eshell-autoloads escreen-autoloads erc-autoloads
emerge-autoloads eieio-autoloads efs-autoloads edt-autoloads
edit-utils-autoloads ediff-autoloads edebug-autoloads
ecrypto-autoloads ecb-autoloads docbookide-autoloads
dired-autoloads dictionary-autoloads debug-autoloads
cookie-autoloads clearcase-autoloads cc-mode-autoloads
calendar-autoloads calc-autoloads c-support-autoloads
build-autoloads bbdb-autoloads auctex-autoloads apel-autoloads
ada-autoloads tex-site mule-autoloads auto-autoloads loadhist
rsz-minibuf auto-show fontl-hooks canna-leim tibetan lao
devanagari indian slovenian czech romanian ccl code-cmds
gutter-items menubar-items x-menubar dragdrop mode-motion mouse
behavior itimer auto-save lisp-mode easymenu easy-mmode iso8859-1
page buff-menu lib-complete cus-file derived newcomment env
text-props frame obsolete cus-start custom widget cl-extra cl
cl-19 packages backquote unicode mswindows-scrollbars mswindows
toolbar native-sound scrollbar network-streams subprocesses
menu-accelerator-support menubar md5 xemacs mule gutter tiff png
gif jpeg xface xpm xbm lisp-float-type file-coding dde windows-nt
dragdrop-api dialog devices window-system base64)
Recent keystrokes:
-----------------
M-x b r o w TAB TAB TAB RET h t t p : / / w w w . g
o o l BS g o e BS BS l e . d e RET button1 button1up
C-x C-f ~ / . x e m TAB TAB TAB l o TAB BS BS BS BS
BS BS BS BS i n TAB RET down down down down down down
C-SPC down down C-insert misc-user misc-user
Recent messages (most recent first):
-----------------------------------
Loading footnote...done
Loading footnote...
(Next local Ispell command will use english dictionary)
Loading ispell...done
Loading ispell...
No more unread newsgroups
No gnus is bad news
Loading gnus-topic...done
Loading gnus-topic...
Checking new news...done
Checking new news...
Generating the cache active file...done
Generating the cache active file...
Reading d:\Dokumente und Einstellungen\haeuslsc\.newsrc.eld...
Loading bbdb-gnus...done
Loading bbdb-gnus...
Loading gnus-demon...done
Loading gnus-demon...
Loading gnus-agent...done
Loading gnus-agent...
10:33 a.m.
>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> Evaluating `M-x browse-url RET http://www.xemacs.org RET'
Franz> produces the following backtrace (when
Franz> `stack-trace-on-error' is activated):
Franz> Debugger entered--Lisp error: (process-error "Running
Franz> ShellExecute" "Das System kann die angegebene Datei nicht finden.
Franz> " "open" "http://www.xemacs.org")
Sure looks to me like the "open" program is not on your PATH inside of
XEmacs. What does M-: (executable-find "open") RET tell you? If the
program is found, is it the right one?
Thanks for the translation, by the way.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:28 p.m.
Stephen J. Turnbull writes:
>>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> Evaluating `M-x browse-url RET http://www.xemacs.org RET'
Franz> produces the following backtrace (when
Franz> `stack-trace-on-error' is activated):
Franz> Debugger entered--Lisp error: (process-error "Running
Franz> ShellExecute" "Das System kann die angegebene Datei nicht finden.
Franz> " "open" "http://www.xemacs.org")
Sure looks to me like the "open" program is not on your PATH inside of
XEmacs. What does M-: (executable-find "open") RET tell you? If the
program is found, is it the right one?
Hm. There is no program `open'. I guess, it is supposed to work
as follows on MS Windows: The action `open' is provided by the
shell (Explorer ?). When called, the shell looks in the Windows
registry for the program that can be used to open the specified
resource. Which program is started depends on the file type (or
file extension) of the specified resource and this information is
buried in the registry. Therefore I think that the error
message is misleading.
Regards,
Franz.
3:33 a.m.
>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> Hm. There is no program `open'. I guess, it is supposed to work
Franz> as follows on MS Windows: The action `open' is provided by the
Franz> shell (Explorer ?).
Then you'll have to change either the specification in browse-url or
change your shell to one that provides "open".
Alternatively, it's probably trivial to implement "open" as a program
(I know that Mac OS X does, simply by passing the command-line
argument to the Finder). If someone does, and it's not already part
of some well-known suite, I would certainly support adding it to
XEmacs's suite of external utilities.
Franz> When called, the shell looks in the Windows
Franz> registry for the program that can be used to open the specified
Franz> resource. Which program is started depends on the file type (or
Franz> file extension) of the specified resource and this information is
Franz> buried in the registry. Therefore I think that the error
Franz> message is misleading.
Sure, but it's not XEmacs's problem. XEmacs currently doesn't do
message translation, so that message must have come from the shell.
Ie, XEmacs called a shell, and told it to execute the command "open".
The shell told it that no such program exists. How is XEmacs supposed
to know that "open" is actually a builtin that only exists in certain shells?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:14 a.m.
On Wed, 2005-10-19 at 11:33 +0900, Stephen J. Turnbull wrote:
>>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> Hm. There is no program `open'. I guess, it is supposed to work
Franz> as follows on MS Windows: The action `open' is provided by the
Franz> shell (Explorer ?).
Then you'll have to change either the specification in browse-url or
change your shell to one that provides "open".
IIRC one can (also?) say "start $something" to get $something opened
with the program it's asssociated with. I have no idea whether that's a
shell built-in or an external program though.
3:06 p.m.
Ville Skyttä writes:
On Wed, 2005-10-19 at 11:33 +0900, Stephen J. Turnbull wrote:
> >>>>> "Franz" == Franz Haeuslschmid <lukrez(a)gmx.at>
writes:
>
> Franz> Hm. There is no program `open'. I guess, it is supposed to work
> Franz> as follows on MS Windows: The action `open' is provided by the
> Franz> shell (Explorer ?).
>
> Then you'll have to change either the specification in browse-url or
> change your shell to one that provides "open".
IIRC one can (also?) say "start $something" to get $something opened
with the program it's asssociated with. I have no idea whether that's a
shell built-in or an external program though.
You remember correctly: One can write `start www.xemacs.org' in
MS Window's command interpreter `cmd'. It should be an adapter
for the `open' action of the shell. I don't think anyway that
XEmacs is searching for that program as the stable series of
XEmacs encounters no problems opening URLs.
Regards,
Franz.
5:02 p.m.
Stephen J. Turnbull writes:
>>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> Hm. There is no program `open'. I guess, it is supposed to work
Franz> as follows on MS Windows: The action `open' is provided by the
Franz> shell (Explorer ?).
Then you'll have to change either the specification in browse-url or
change your shell to one that provides "open".
The default shell of MS Windows already provides `open'. It is
the default action of double-clicking the icon of the resource
that should be opened or started.
Alternatively, it's probably trivial to implement
"open" as a program
(I know that Mac OS X does, simply by passing the command-line
argument to the Finder). If someone does, and it's not already part
of some well-known suite, I would certainly support adding it to
XEmacs's suite of external utilities.
I think this is what Ville Skyttä had in mind when he posted his
reply.
[Speculations on what MS Windows does when the shell opens a
resource.]
Sure, but it's not XEmacs's problem. XEmacs currently
doesn't do
message translation, so that message must have come from the shell.
Ie, XEmacs called a shell, and told it to execute the command "open".
The shell told it that no such program exists. How is XEmacs supposed
to know that "open" is actually a builtin that only exists in certain shells?
That is quite true. However, it is possible that XEmacs
constructs the "wrong" arguments for a command. I tried to take
a look behind the scenes of executing a shell command on MS
Windows. And I think that this problem is really restricted in
its effect to MS Windows.
And the problem is IMHO located at the C/C++ layer.
The parameters for the shell execution are prepared in source
file `win32.c':
--8<---------------cut here---------------start------------->8---
Extbyte *opext = NULL;
Extbyte *parmext = NULL;
Extbyte *path = NULL;
Extbyte *doc = NULL;
if (STRINGP (operation))
LISP_STRING_TO_TSTR (operation, opext);
/* #### What about path names, which may be links? */
if (STRINGP (parameters))
LISP_STRING_TO_TSTR (parameters, parmext);
if (STRINGP (current_dir))
LOCAL_FILE_FORMAT_TO_TSTR (current_dir, path);
if (STRINGP (document))
LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR (document, doc);
ret = (int) qxeShellExecute (NULL, opext, doc, parmext, path,
(INTP (show_flag) ?
XINT (show_flag) : SW_SHOWDEFAULT));
--8<---------------cut here---------------end--------------->8---
The interesting variable here is `document' that refers to a lisp
object specifying the resource to open. In my case, this could
be `www.xemacs.org'.
This lisp object is converted using the macro
`LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR'. This macro is aliased to
the macro `LOCAL_FILE_FORMAT_TO_TSTR', both are defined in
`syswindows.h'. The later macro contains a call to
`qxe_realpath' in file `realpath.c' in order to convert file
paths into some internal format. The problem now is, that this
function is applied to the URL that I like to open. As there is
no special handling for URLs, that resource is treated as a
relative path and for generating an absolute path for it, the path
of the current working directory is prepended. During the
debugging process, it was tried to open the resource
`D:\Src\xemacs-21.5\nt\www.xemacs.org'. And this file is
definitely not available.
I now think that some sort of checking should be introduced to
decide whether a resource is defined by an URL and to disable the
conversion to an absolute path internally. This is however
beyond my capability yet.
Regards,
Franz.
3:24 a.m.
I've added Ben, who is most qualified to deal with Windows issues.
Please keep Ben in the address list, as he uses his address as a flag
which promotes the thread in his priorities.
>>>> "Franz" == Franz Haeuslschmid
<lukrez(a)gmx.at> writes:
Franz> The default shell of MS Windows already provides `open'. It is
Franz> the default action of double-clicking the icon of the resource
Franz> that should be opened or started.
Well, something there is broken, because the error message from
Windows makes it impossible to determine whether the command "open"
was found and it failed to find a file, or whether the shell failed to
find "open". It's still not possible for XEmacs to diagnose that. In
fact, I now realize that all the useful information in that message
came from XEmacs! *sigh*
[...]
Franz> The parameters for the shell execution are prepared in source
Franz> file `win32.c':
--8<---------------cut here---------------start------------->8---
Extbyte *opext = NULL;
Extbyte *parmext = NULL;
Extbyte *path = NULL;
Extbyte *doc = NULL;
if (STRINGP (operation))
LISP_STRING_TO_TSTR (operation, opext);
/* #### What about path names, which may be links? */
if (STRINGP (parameters))
LISP_STRING_TO_TSTR (parameters, parmext);
if (STRINGP (current_dir))
LOCAL_FILE_FORMAT_TO_TSTR (current_dir, path);
if (STRINGP (document))
LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR (document, doc);
ret = (int) qxeShellExecute (NULL, opext, doc, parmext, path,
(INTP (show_flag) ?
XINT (show_flag) : SW_SHOWDEFAULT));
--8<---------------cut here---------------end--------------->8---
Franz> The interesting variable here is `document' that refers to a lisp
Franz> object specifying the resource to open. In my case, this could
Franz> be `www.xemacs.org'.
Franz> This lisp object is converted using the macro
Franz> `LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR'. This macro is aliased to
Franz> the macro `LOCAL_FILE_FORMAT_TO_TSTR', both are defined in
Franz> `syswindows.h'. The later macro contains a call to
Franz> `qxe_realpath' in file `realpath.c' in order to convert file
Franz> paths into some internal format.
Franz> The problem now is, that this function is applied to the
Franz> URL that I like to open. As there is
Franz> no special handling for URLs, that resource is treated as a
Franz> relative path and for generating an absolute path for it, the path
Franz> of the current working directory is prepended. During the
Franz> debugging process, it was tried to open the resource
Franz> `D:\Src\xemacs-21.5\nt\www.xemacs.org'. And this file is
Franz> definitely not available.
Sounds plausible.
Franz> I now think that some sort of checking should be introduced to
Franz> decide whether a resource is defined by an URL and to disable the
Franz> conversion to an absolute path internally.
Well, assuming that browse-url is using shell-command, I don't think
so; doing any conversion ever is brain-damage (aka attempting to
intuit what the user wants). If you're going to pass user-specified
information to a shell command, you're doing that because you think
the shell or the command will do a better job of interpreting it than
you will. The _only_ thing that XEmacs should do with those arguments
is ensure that they are in an encoding acceptable to the underlying
OS.
Even if we're using something lower level, I think that trying to
guess what is an possibly remote URL and what is a file system object
is bogus. For example, if you use wget you will have lots of
directories that look like "www.xemacs.org" lying around, but most
modern browsers interpret that as an abbreviations for
"http://www.xemacs.org/". And "news:news.example.invalid" is a
perfectly legal local filename, at least on Unix.
Interpretation of those objects should be done either by the system
command being invoked or by a high-level function carefully documented
as doing "convenient" transformations, with some way to suppress them
when inconvenient (such as an alternate command).
Ben?
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:50 a.m.
Stephen J. Turnbull wrote:
I've added Ben, who is most qualified to deal with Windows
issues.
Please keep Ben in the address list, as he uses his address as a flag
which promotes the thread in his priorities.
>>>>>"Franz" == Franz Haeuslschmid <lukrez(a)gmx.at> writes:
>>>>>
>>>>>
Franz> The default shell of MS Windows already provides `open'. It is
Franz> the default action of double-clicking the icon of the resource
Franz> that should be opened or started.
Well, something there is broken, because the error message from
Windows makes it impossible to determine whether the command "open"
was found and it failed to find a file, or whether the shell failed to
find "open". It's still not possible for XEmacs to diagnose that. In
fact, I now realize that all the useful information in that message
came from XEmacs! *sigh*
[...]
Franz> The parameters for the shell execution are prepared in source
Franz> file `win32.c':
--8<---------------cut here---------------start------------->8---
Extbyte *opext = NULL;
Extbyte *parmext = NULL;
Extbyte *path = NULL;
Extbyte *doc = NULL;
if (STRINGP (operation))
LISP_STRING_TO_TSTR (operation, opext);
/* #### What about path names, which may be links? */
if (STRINGP (parameters))
LISP_STRING_TO_TSTR (parameters, parmext);
if (STRINGP (current_dir))
LOCAL_FILE_FORMAT_TO_TSTR (current_dir, path);
if (STRINGP (document))
LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR (document, doc);
ret = (int) qxeShellExecute (NULL, opext, doc, parmext, path,
(INTP (show_flag) ?
XINT (show_flag) : SW_SHOWDEFAULT));
--8<---------------cut here---------------end--------------->8---
Franz> The interesting variable here is `document' that refers to a lisp
Franz> object specifying the resource to open. In my case, this could
Franz> be `www.xemacs.org'.
Franz> This lisp object is converted using the macro
Franz> `LOCAL_FILE_FORMAT_MAYBE_URL_TO_TSTR'. This macro is aliased to
Franz> the macro `LOCAL_FILE_FORMAT_TO_TSTR', both are defined in
Franz> `syswindows.h'. The later macro contains a call to
Franz> `qxe_realpath' in file `realpath.c' in order to convert file
Franz> paths into some internal format.
Franz> The problem now is, that this function is applied to the
Franz> URL that I like to open. As there is
Franz> no special handling for URLs, that resource is treated as a
Franz> relative path and for generating an absolute path for it, the path
Franz> of the current working directory is prepended. During the
Franz> debugging process, it was tried to open the resource
Franz> `D:\Src\xemacs-21.5\nt\www.xemacs.org'. And this file is
Franz> definitely not available.
Sounds plausible.
Franz> I now think that some sort of checking should be introduced to
Franz> decide whether a resource is defined by an URL and to disable the
Franz> conversion to an absolute path internally.
Well, assuming that browse-url is using shell-command, I don't think
so; doing any conversion ever is brain-damage (aka attempting to
intuit what the user wants). If you're going to pass user-specified
information to a shell command, you're doing that because you think
the shell or the command will do a better job of interpreting it than
you will. The _only_ thing that XEmacs should do with those arguments
is ensure that they are in an encoding acceptable to the underlying
OS.
Even if we're using something lower level, I think that trying to
guess what is an possibly remote URL and what is a file system object
is bogus. For example, if you use wget you will have lots of
directories that look like "www.xemacs.org" lying around, but most
modern browsers interpret that as an abbreviations for
"http://www.xemacs.org/". And "news:news.example.invalid" is a
perfectly legal local filename, at least on Unix.
Interpretation of those objects should be done either by the system
command being invoked or by a high-level function carefully documented
as doing "convenient" transformations, with some way to suppress them
when inconvenient (such as an alternate command).
Ben?
You can blame me for this botch. at one point i added to 21.5 the
ability for XEmacs to treat windows shortcuts as symbolic links and
automatically resolve them. the motivation was primarily that cygwin
implements its symlinks as shortcuts, so that they'll still do something
reasonable under windows explorer. the problem is that shortcuts are a
big hack and aren't supported natively in the file system; so we need to
convert them into the appropriate non-symlinked path. this is what's
happening here, and since the shortcut resolving was implemented inside
of qxe_realpath(), it converts to absolute paths as a side effect. if
you set `mswindows-shortcuts-are-symlinks' to nil, this will turn off
all of this behavior, as can be seen in the definition of
PATHNAME_RESOLVE_LINKS in sysfile.h. it would be possible to fix things
so that the call to qxe_realpath() only resolved links and didn't
absolutize the filename. this would probably fix things in practice but
wouldn't be sound, as stephen points out.
ben
4:19 a.m.
Franz Haeuslschmid <lukrez(a)gmx.at> writes:
Stephen J. Turnbull writes:
>>>>>> "Franz" == Franz Haeuslschmid <lukrez(a)gmx.at>
writes:
>
> Franz> Hm. There is no program `open'. I guess, it is supposed to work
> Franz> as follows on MS Windows: The action `open' is provided by the
> Franz> shell (Explorer ?).
>
> Then you'll have to change either the specification in browse-url or
> change your shell to one that provides "open".
The default shell of MS Windows already provides `open'. It is
the default action of double-clicking the icon of the resource
that should be opened or started.
What window OS provides 'open'? I am using XP and there is no
'open' command
but yes there is a 'start' command.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
The best-laid plans of mice and men go oft astray.
4:29 a.m.
Franz Haeuslschmid <lukrez(a)gmx.at> writes:
================================================================
Dear Bug Team!
Evaluating `M-x browse-url RET http://www.xemacs.org RET'
produces the following backtrace (when `stack-trace-on-error' is
activated):
--8<---------------cut here---------------start------------->8---
Debugger entered--Lisp error: (process-error "Running ShellExecute" "Das
System kann die angegebene Datei nicht finden.
" "open" "http://www.xemacs.org")
I think this "open" needs to be "start" for windows.
Even I have faced the same error when installing XEmacs for the first time,
the workaround which I use for this problem is:
M-x Customize browse-url
then set the 'browser-function' option to my favorite browser which happens to
be firefox.
HTH.
--
Surendra Singhi
http://www.public.asu.edu/~sksinghi/index.html
,----
| WHY SHOULD WE SAVE TIGER?
| Ans: Saving the tiger means saving mankind..
|
| Help http://pudang.tripod.com/
| or https://secure.worldwildlife.org/forms/tiger_appeal_1.cfm
`----
6761
days inactive
6766
days old
10 comments
5 participants
participants (5)
-
Ben Wing -
Franz Haeuslschmid -
Stephen J. Turnbull -
Surendra Singhi -
Ville Skyttä