From: Eli Zaretskii <eliz@gnu.org>
To: Jarek Czekalski <jarekczek@poczta.onet.pl>
Cc: 15461@debbugs.gnu.org
Subject: bug#15461: 24.3; exec-path on ms windows should contain current directory
Date: Sun, 15 Dec 2013 23:16:50 +0200 [thread overview]
Message-ID: <83k3f5erwd.fsf@gnu.org> (raw)
In-Reply-To: <52AE11CC.5030500@poczta.onet.pl>
> Date: Sun, 15 Dec 2013 21:32:12 +0100
> From: Jarek Czekalski <jarekczek@poczta.onet.pl>
>
> Some analyzis done:
>
> 1. shell-command uses libexec\emacs\24.3.50\i686-pc-mingw32\cmdproxy.exe
> and this proxy locates files in the current directory. Side note: it
> ignores exec-path and uses only system PATH variable
cmdproxy emulates a shell, so it does what every shell would: ignore
exec-path (which is an Emacs feature, unknown to other programs), and
use PATH.
> 2. call-process does not run programs from the current directory (a new bug)
It's not a bug. Again, please keep in mind that each buffer in Emacs
has its own "current directory".
> Now the Stefan's suggestion:
>
> > Completion should mirror the behavior of the code that spawns the
> > process
>
> , which seemed perfectly at the beginning, makes less sense. Which
> code's behaviour should be copied?
>
> I guess first call-process should be fixed to include the current
> directory, then its behaviour may be copied.
I suggest to stay focused on the issue at hand: completion of
executable files. If we extend the issue to how executables are found
by call-process, cmdproxy, shell-command, etc., we will just add
unneeded complexity.
> Any suggestions in which direction to go? Maybe the simplest consing
> exec-path is still an option?
No, it is not. Again, let's stay focused on completion.
next prev parent reply other threads:[~2013-12-15 21:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 13:24 bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-09-25 15:48 ` Eli Zaretskii
2013-09-26 17:23 ` bug#15461: why do I need it Jarek Czekalski
2013-09-26 17:59 ` Eli Zaretskii
2013-09-26 20:39 ` Stefan Monnier
2013-09-26 20:40 ` bug#15461: answer Jarek Czekalski
2013-12-15 20:32 ` bug#15461: 24.3; exec-path on ms windows should contain current directory Jarek Czekalski
2013-12-15 21:16 ` Eli Zaretskii [this message]
2013-12-16 8:06 ` Jarek Czekalski
2013-12-16 16:45 ` Eli Zaretskii
2013-12-18 8:15 ` Jarek Czekalski
2013-12-25 23:14 ` bug#15461: 24.3; [PATCH] " Jarek Czekalski
2013-12-26 16:23 ` Eli Zaretskii
2013-12-26 22:27 ` Jarek Czekalski
2013-12-26 23:22 ` Juanma Barranquero
2013-12-27 8:19 ` Eli Zaretskii
2013-12-27 21:02 ` Jarek Czekalski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83k3f5erwd.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=15461@debbugs.gnu.org \
--cc=jarekczek@poczta.onet.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.