all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#9792: 24.0.50; process-file and space in filename
@ 2011-10-19  3:43 Leo
  2011-10-19  7:36 ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2011-10-19  3:43 UTC (permalink / raw)
  To: 9792

To reproduce:

1. M-x cd a directory of git repo which has a master branch
2. Eval: (apply 'process-file "git" nil t nil '("--no-pager" "log"
"--pretty=format:* %H %s" "HEAD..origin/master"))

to get this message:
'c:\Program' is not an internal or external command ...

(executable-find "git") => "c:/Program Files (x86)/Git/cmd/git.cmd"

Tested on GNU Emacs 24.0.50.1 (i386-mingw-nt6.1.7601) of 2011-09-19 on
3249CTO

Sorry the network has been extremely slow sometimes less than 1k/s. So
I haven't been able to test the problem in the pretest version.

Leo





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-19  3:43 bug#9792: 24.0.50; process-file and space in filename Leo
@ 2011-10-19  7:36 ` Eli Zaretskii
  2011-10-19 17:23   ` Leo
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-10-19  7:36 UTC (permalink / raw)
  To: Leo; +Cc: 9792

> Date: Wed, 19 Oct 2011 11:43:53 +0800
> From: Leo <sdl.web@gmail.com>
> 
> To reproduce:
> 
> 1. M-x cd a directory of git repo which has a master branch
> 2. Eval: (apply 'process-file "git" nil t nil '("--no-pager" "log"
> "--pretty=format:* %H %s" "HEAD..origin/master"))
> 
> to get this message:
> 'c:\Program' is not an internal or external command ...
> 
> (executable-find "git") => "c:/Program Files (x86)/Git/cmd/git.cmd"

Please produce a Lisp-level backtrace for this.  I think there's a
call to shell-quote-argument missing somewhere; a backtrace might show
where that is.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-19  7:36 ` Eli Zaretskii
@ 2011-10-19 17:23   ` Leo
  2011-10-19 18:02     ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2011-10-19 17:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 9792

On 2011-10-19 15:36 +0800, Eli Zaretskii wrote:
> Please produce a Lisp-level backtrace for this.  I think there's a
> call to shell-quote-argument missing somewhere; a backtrace might show
> where that is.

I don't know how to do that. The message is generated by call-process.

Leo





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-19 17:23   ` Leo
@ 2011-10-19 18:02     ` Eli Zaretskii
  2011-10-20  5:07       ` Leo
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-10-19 18:02 UTC (permalink / raw)
  To: Leo; +Cc: 9792

> From:  Leo <sdl.web@gmail.com>
> Cc: 9792@debbugs.gnu.org
> Date: Thu, 20 Oct 2011 01:23:38 +0800
> 
> On 2011-10-19 15:36 +0800, Eli Zaretskii wrote:
> > Please produce a Lisp-level backtrace for this.  I think there's a
> > call to shell-quote-argument missing somewhere; a backtrace might show
> > where that is.
> 
> I don't know how to do that. The message is generated by call-process.

Who calls call-process?

In general, setting a breakpoint in Fcall_process should produce a
Lisp-level backtrace when you type "bt" after the breakpoint breaks,
if you start GDB from the Emacs `src' directory.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-19 18:02     ` Eli Zaretskii
@ 2011-10-20  5:07       ` Leo
  2011-10-20  7:12         ` Michael Albinus
  0 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2011-10-20  5:07 UTC (permalink / raw)
  To: 9792

On 2011-10-20 02:02 +0800, Eli Zaretskii wrote:
> Who calls call-process?

`process-file' calls it.

> In general, setting a breakpoint in Fcall_process should produce a
> Lisp-level backtrace when you type "bt" after the breakpoint breaks,
> if you start GDB from the Emacs `src' directory.

In this case I probably won't be able to help much.

Leo






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-20  5:07       ` Leo
@ 2011-10-20  7:12         ` Michael Albinus
  2011-10-20  9:14           ` Leo
  0 siblings, 1 reply; 11+ messages in thread
From: Michael Albinus @ 2011-10-20  7:12 UTC (permalink / raw)
  To: Leo; +Cc: 9792

Leo <sdl.web@gmail.com> writes:

> On 2011-10-20 02:02 +0800, Eli Zaretskii wrote:
>> Who calls call-process?
>
> `process-file' calls it.
>
>> In general, setting a breakpoint in Fcall_process should produce a
>> Lisp-level backtrace when you type "bt" after the breakpoint breaks,
>> if you start GDB from the Emacs `src' directory.
>
> In this case I probably won't be able to help much.

`process-file' is a Lisp function. It would be sufficient to activate
edebug for it, for example via

M-x load-library RET edebug
M-: (edebug-instrument-function 'process-file)

When the debugger enters `process-file', you can produce the backtrace
with "d".

> Leo

Best regards, Michael.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-20  7:12         ` Michael Albinus
@ 2011-10-20  9:14           ` Leo
  2011-10-20 10:02             ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2011-10-20  9:14 UTC (permalink / raw)
  To: 9792

On 2011-10-20 15:12 +0800, Michael Albinus wrote:
> `process-file' is a Lisp function. It would be sufficient to activate
> edebug for it, for example via
>
> M-x load-library RET edebug
> M-: (edebug-instrument-function 'process-file)
>
> When the debugger enters `process-file', you can produce the backtrace
> with "d".

This does not enter the debugger. Note when the call-process form is
eval'd in process-file, there is no error from the elisp point of view.
`call-process' returns 1 to indicate failure in executing the external
process.

But I can C-u M-C-x process-file and get a backtrace like this one:
http://paste.pound-python.org/show/13964 if that is helpful.

Leo






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-20  9:14           ` Leo
@ 2011-10-20 10:02             ` Eli Zaretskii
  2011-10-20 11:00               ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-10-20 10:02 UTC (permalink / raw)
  To: Leo; +Cc: 9792

> From: Leo <sdl.web@gmail.com>
> Date: Thu, 20 Oct 2011 17:14:02 +0800
> 
> On 2011-10-20 15:12 +0800, Michael Albinus wrote:
> > `process-file' is a Lisp function. It would be sufficient to activate
> > edebug for it, for example via
> >
> > M-x load-library RET edebug
> > M-: (edebug-instrument-function 'process-file)
> >
> > When the debugger enters `process-file', you can produce the backtrace
> > with "d".
> 
> This does not enter the debugger.

I think you need to load the .el file that defines process-file, with
"M-x load-file", before you invoke edebug-instrument-function.  In
this case, "M-x load-file RET simple.el RET".

> Note when the call-process form is eval'd in process-file, there is
> no error from the elisp point of view.  `call-process' returns 1 to
> indicate failure in executing the external process.

This doesn't matter.  Instrumenting a Lisp function will enter Edebug
when that function is called, regardless of whether there is a
Lisp-level error.

> But I can C-u M-C-x process-file and get a backtrace like this one:
> http://paste.pound-python.org/show/13964 if that is helpful.

Assuming that process-file is called with the name of the program
being just "git", with no leading directories, it sounds like the
problem is born inside call-process and its subroutines; I will have a
look.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-20 10:02             ` Eli Zaretskii
@ 2011-10-20 11:00               ` Eli Zaretskii
  2011-10-21  1:27                 ` Leo
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2011-10-20 11:00 UTC (permalink / raw)
  To: sdl.web, 9792

> Date: Thu, 20 Oct 2011 12:02:48 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9792@debbugs.gnu.org
> 
> > But I can C-u M-C-x process-file and get a backtrace like this one:
> > http://paste.pound-python.org/show/13964 if that is helpful.
> 
> Assuming that process-file is called with the name of the program
> being just "git", with no leading directories, it sounds like the
> problem is born inside call-process and its subroutines; I will have a
> look.

The problem happens when both of the following conditions are true:

  . the command being invoked is a batch file (git.cmd in this case)

  . the directory where it lives included parentheses

I cannot find a workable solution for this situation; the error
happens even if the batch file is invoked via the system shell.
Suggestions for solving this are welcome.  The relevant function is
w32proc.c:sys_spawnve.

Unless someone can suggest how to fix this, I'm inclined to tag this
problem as "wontfix", and suggest that Windows users do not install
such commands in a directory whose name includes parentheses.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-20 11:00               ` Eli Zaretskii
@ 2011-10-21  1:27                 ` Leo
  2011-10-21  7:53                   ` Eli Zaretskii
  0 siblings, 1 reply; 11+ messages in thread
From: Leo @ 2011-10-21  1:27 UTC (permalink / raw)
  To: 9792

On 2011-10-20 19:00 +0800, Eli Zaretskii wrote:
> The problem happens when both of the following conditions are true:
>
>   . the command being invoked is a batch file (git.cmd in this case)
>
>   . the directory where it lives included parentheses

Thanks for looking into this.

But (apply 'process-file "git" nil t nil '("--no-pager" "log")) does not
fail.

Leo






^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#9792: 24.0.50; process-file and space in filename
  2011-10-21  1:27                 ` Leo
@ 2011-10-21  7:53                   ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2011-10-21  7:53 UTC (permalink / raw)
  To: Leo; +Cc: 9792

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 21 Oct 2011 09:27:29 +0800
> 
> On 2011-10-20 19:00 +0800, Eli Zaretskii wrote:
> > The problem happens when both of the following conditions are true:
> >
> >   . the command being invoked is a batch file (git.cmd in this case)
> >
> >   . the directory where it lives included parentheses
> 
> Thanks for looking into this.
> 
> But (apply 'process-file "git" nil t nil '("--no-pager" "log")) does not
> fail.

Sheer luck.  cmd.exe has all kind of fragile heuristics built into it,
when quotes are present on the command line; sometimes it works,
sometimes it doesn't.

In my testing, I put an ls.cmd in such a directory that called the
real ls.exe, and saw it sometimes work, sometimes not, depending on
what were the command-line arguments.





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2011-10-21  7:53 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-19  3:43 bug#9792: 24.0.50; process-file and space in filename Leo
2011-10-19  7:36 ` Eli Zaretskii
2011-10-19 17:23   ` Leo
2011-10-19 18:02     ` Eli Zaretskii
2011-10-20  5:07       ` Leo
2011-10-20  7:12         ` Michael Albinus
2011-10-20  9:14           ` Leo
2011-10-20 10:02             ` Eli Zaretskii
2011-10-20 11:00               ` Eli Zaretskii
2011-10-21  1:27                 ` Leo
2011-10-21  7:53                   ` Eli Zaretskii

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.