all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "David Chappaz" <david.chappaz@free.fr>
To: <help-gnu-emacs@gnu.org>
Subject: RE: shell-command causes problems with absolute/relative paths in TAGS
Date: Fri, 6 Jan 2012 13:04:57 -0000	[thread overview]
Message-ID: <9287FF55897A4EED8EA883DC00F98BAC@EUROPE.ROOT.PRI> (raw)
In-Reply-To: <83pqexnjrk.fsf@gnu.org>


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	other threads:[~2012-01-06 13:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-02 22:33 M-x mystery Silvio Levy
2012-01-02 23:25 ` Drew Adams
2012-01-04 16:05   ` shell-command causes problems with absolute/relative paths in TAGS David Chappaz
2012-01-04 16:15     ` Vladimir Murzin
2012-01-04 16:27       ` David Chappaz
2012-01-05  5:41     ` Bob Proulx
2012-01-05 12:20       ` David Chappaz
2012-01-05 16:53         ` Unknown
2012-01-05 22:20         ` Bob Proulx
2012-01-06 11:12           ` David Chappaz
2012-01-06 11:38             ` Eli Zaretskii
2012-01-06 13:04               ` David Chappaz [this message]
2012-01-06 15:42                 ` Eli Zaretskii
2012-01-06 16:03                   ` David Chappaz
2012-01-06 16:12                     ` David Chappaz
2012-01-06 18:46                     ` Eli Zaretskii
2012-01-06 11:25     ` Eli Zaretskii
2012-01-06 14:04       ` David Chappaz
2012-01-06 15:12         ` Eli Zaretskii
2012-01-06 15:52           ` Juanma Barranquero
2012-01-06 11:34     ` Eli Zaretskii

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=9287FF55897A4EED8EA883DC00F98BAC@EUROPE.ROOT.PRI \
    --to=david.chappaz@free.fr \
    --cc=help-gnu-emacs@gnu.org \
    /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.