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

[Vladimir Murzin]

Hi David 

AFAIK "less"/"more" are pagers and suitable for reading files by human. Have 
you tried using "cat"?
Best wishes, Vladimir Murzin

-----Original Message-----
From: "David Chappaz" <david.chappaz@free.fr>
Sender: help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.orgDate: Wed, 4 Jan 2012 
16:05:13 
To: <help-gnu-emacs@gnu.org>
Subject: shell-command causes problems with absolute/relative paths in TAGS

Hi everyone,

I'm having trouble when generating a TAGS file on windows. I should say that
everything works fine on Linux (almost, see bottom of the message), so it
really seems to be a windows specific problem.

Note that I'm using GNU Emacs 23.3.1, with Exuberant CTags 5.8

So here is the thing. Say I have a "test" folder, with 2 source files, e.g.
test1.c and test2.c
I also have a "filelist.txt", e.g. generated with "GnuWin32 find", which
contains :

./test1.v
./test2.v

Now, I generate my TAGS file from a plain windows shell, with the following
command:

more filelist.txt | ctags -e -L -

This works fine, and, as expected, the paths to the source files in the TAGS
file are relative, so the entire "test" folder and the TAGS file can be
moved to a different location.

I'm developing a small emacs package to provide some sort of IDE. So now I'm
trying to do the same from within emacs. If I do:

M-x shell-command
more filelist.txt | ctags -e -L -

...then the result is different, and now paths in the TAGS file become
absolute. Even using the explicit option --tag-relative=yes does not change
anything.

I am not sure whether Exuberant CTags or Emacs shell-command is to blame. I
believe it's got something to do with "shell-command", but it's just a guess
really. Can anyone reproduce the problem and/or explain what's happening ?

PS, on a slightly different note:

1/ on linux, shell-command also does something funny. Try "more
filelist.txt" and check the output buffer. It contains some sort of "header"
with "::::::::::::::" so the same command obviously fails. Use "less"
instead of "more" and then everything works

2/ I have also found that "GnuWin32 find" is painfully slow on network
(unix) drives, and that using the built-in dos command "dir /b /s" is much
faster (but less powerful of course). Has anyone experienced the same ? Also
"find" miserably fails if any directory it traverses contains (unix)
symbolic links (which can't be resolved from windows, of course, but this
shouldn't be a problem).