help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: shell-command causes problems with absolute/relative paths in TAGS


From: David Chappaz
Subject: RE: shell-command causes problems with absolute/relative paths in TAGS
Date: Fri, 6 Jan 2012 13:04:57 -0000

Eli Zaretskii wrote
> > If, before doing M-x shell, I evaluate
> > (setq explicit-cmdproxy.exe-args  '("/q"))
> > to prevent shell commands from being echoed, then suddenly the TAGS file
> > is generated properly, with relative filenames.
> 
> I see no such variable in Emacs. 

The variable name depends on which shell you use. By default, only
explicit-bash-args and explicit-sh-args are defined in emacs.
On windows, cmdproxy.exe is the default shell, hence the variable name.

> Also, originally you talked about "M-x shell-command", not "M-x shell".
> Which one is it?

Sorry about the confusion.I'll try to summarise.

With M-x shell-command, the behaviour is always incorrect.
With M-x shell, the behaviour is sometimes correct, sometimes not (more on
that below), depending on cosmetic changes (like explicit-cmdproxy.exe-args)
which should not have any influence (I think).
 
> FWIW, I cannot reproduce this on MS-Windows with Emacs 23.3.  I don't
> have Exuberant CTags, but using the etags program provided with
> Emacs.  I get relative file names with either method.

I need to parse languages which etags doesn't know, which is why I'm using
exuberant ctags.

But I did notice that the behaviour is fine with the vanilla etags provided
with emacs. Therefore, you will have to use exuberant ctags to reproduce the
problem. You can download binaries from
http://prdownloads.sourceforge.net/ctags/ctags58.zip. No install is
required, just copy the .exe in the test directory.

Also, we can't exclude the fact that the problem is in exuberant ctags
itself, but for now I just don't understand at all what's happening.

> Can you reproduce the problem in "emacs -Q"?  If not, there's some
> customization of yours that causes this, or maybe it is a problem with
> Exuberant on Windows.

Yes, same problem with --no-init-file

In fact, after a little debugging, I've devised the following experiment for
you to reproduce (with --no-init-file)

1/ From a freshly opened emacs if do M-x shell followed by:

ctags -e -L filelist.txt

or even

"C:/Program Files/Emacs/emacs-23.3/bin/cmdproxy.exe" /C "ctags -e -L
filelist.txt"

then everything is fine.

2/ Now from e.g. a scratch buffer, I evaluate

(progn
   (cd "C:/test/")
   (call-process-region (point) (point) "C:/Program
Files/Emacs/emacs-23.3/bin/cmdproxy.exe" nil (current-buffer) nil "-c"
"ctags -e -L filelist.txt"))

which is more or less what M-x shell-command would do... then the result is
incorrect.

3/ Worse, if you kill the original shell buffer created in 1/, and repeat
the same operation as in 1/... then the result is incorrect.

So it really looks like something is happening in call-process-region...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]