Re: [Bug: 21.5-b22] Backtrace with function `browse-url'

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&gt; 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?