From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] trunk r116230: Fix bug #16558 with w32-shell-execute on remote file names. Date: Mon, 03 Feb 2014 18:17:57 +0200 Message-ID: <83lhxs2mru.fsf@gnu.org> References: <83ob2q4nbv.fsf@gnu.org> <83k3de41sc.fsf@gnu.org> <83iosx4iid.fsf@gnu.org> <83txcg3fle.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1391444301 30614 80.91.229.3 (3 Feb 2014 16:18:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Feb 2014 16:18:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 03 17:18:28 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WAME1-0008Ej-Fy for ged-emacs-devel@m.gmane.org; Mon, 03 Feb 2014 17:18:21 +0100 Original-Received: from localhost ([::1]:48400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAME1-0006F9-0U for ged-emacs-devel@m.gmane.org; Mon, 03 Feb 2014 11:18:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAMDu-0006EZ-8W for emacs-devel@gnu.org; Mon, 03 Feb 2014 11:18:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAMDp-0000Dj-4D for emacs-devel@gnu.org; Mon, 03 Feb 2014 11:18:14 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:46134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAMDo-0000Cd-RQ for emacs-devel@gnu.org; Mon, 03 Feb 2014 11:18:09 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N0F00800H0GJX00@mtaout24.012.net.il> for emacs-devel@gnu.org; Mon, 03 Feb 2014 18:17:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0F007SPH95BO20@mtaout24.012.net.il>; Mon, 03 Feb 2014 18:17:29 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169368 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 03 Feb 2014 09:06:33 -0500 > > >> I'm having trouble understanding the above: can you give an example of > >> a file which is neither absolute nor relative to the directory passed > >> to the system API? > > I think it happened to me with shr.el, since it doesn't set the > > current directory of the buffer where it renders an HTML document. > > Sounds like a bug in the code that extracts the name from the buffer and > passes it to w32-shell-execute, or in the code that (fails to) set the > buffer's default-directory. > IOW the same would happen under GNU/Linux passing that file to call-process. > > Or is there something different going on? > > > In any case, this is not worse than what happened before the change > > that introduced the call to expand-file-name: then, the ShellExecute > > API was always called with a file name as passed to w32-shell-execute. > > I guess the question for me now is "why call Fexpand_file_name"? > I see it was introduced in: > > timestamp: Tue 2013-12-24 19:21:06 +0200 > message: > Minor fixes in w32-shell-execute. > > src/w32fns.c (Fw32_shell_execute): Ensure DOCUMENT is an absolute > file name when it is submitted to ShellExecute. Simplify code. > Don't test DOCUMENT for being a string, as that is enforced by > CHECK_STRING. Doc fix. > > But I don't know which problem it was trying to solve. The problem happened when using a function in shr.el that no longer exists. To recreate that, I'd need to restore that function and trace through that. The result I do remember: w32-shell-execute failed because DOCUMENT was a non-absolute file name, but not in the directory where the function expected it to be.