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

[David Chappaz]

> Bob Proulx wrote:
> Please don't hijack discussion threads.  You replied to Drew Adams
> message with the subject "M-x mystery" and changed the subject.  If
> you wish to create a new topic please create a new message.  Changing
> the subject is used for topic drift within a discussion thread and
> does not create a new thread of discussion.  This is to your advantage
> since people who are skipping the thread will also skip your message.

I can't argue with that. You're 100% correct, and I'm just hoping Drew Adams
will forgive me. I replied to an existing message and changed the subject
out of laziness I suppose, and didn't realise it would have unwanted
consequences. I'll learn from this mistake !
Out of curiosity, is there any way to move this discussion in a new thread,
or is it too late ?

> I am not using that version of tags and so I can't check the options
> but to me using "-" (indicating to read standard input) looks to me
> like a strange way to do things.  And piping from more to it is
> strange times strange creating a lot of it.
> 
> > more filelist.txt | ctags -e -L -

As you have guessed, I'm not a shell expert, but I now understand the
example I gave was a bit strange indeed.
In fact I ended up with this command, because I was trying to "debug" a more
complex command, where the result of "find" is piped to ctags:

find -type f -name "*.c" | ctags -e -L -

Presumably this way of doing is more "conventional" but again I'm not an
expert, and if you think this is a bit awkward for any reason, please let me
know !

Because I was getting the absolute/relative path problem I mentioned, I
simply split the command into two fragments, explicitly creating an
intermediate file:

find -type f -name "*.c" > filelist.txt
cat filelist.txt | ctags -e -L -
 
> Instead have you tried simply running ctags on the file?  Try this
> instead:
> 
>   ctags -e -L filelist.txt

Doh, I should have thought of doing that from the start. This is by far the
simplest and most natural way of doing things...
 
> That should work more reliably the same on all operating systems.
> Expecially since pipes on MS-Windows are not speedy.

And yet I still get the same behaviour...
Running "ctags -e -L filelist.txt" directly from the shell and doing the
same in shell-command still produces two different results... How can that
be ?? This is really beyond me !

> > PS, on a slightly different note:
> >
> > 1/ on linux, shell-command also does something funny. 
> 
> Seeing the ":::::::::::::: FILENAME ::::::::::::::" header is a clue
> to your problem.  It tells me that more has been told to read multiple
> files.  But the command you list does not have multiple files.  I am
> sure that when you run it from the command line and saying that it is
> working okay there that it isn't getting multiple files.  So somehow
> when calling that pipeline from shell-command there are multiple files
> being offered to the command.  

Yes that makes perfect sense. I tried something like "more test1.c test2.c"
directly from the command line, and I did get the separator with the
filename. So when doing "more filetest.txt" from shell-command, "more" is
clearly getting multiple files.

> That is probably somehow related to
> your difference in behavior of relative paths versus absolute paths.

Yes I suppose so. 
In fact I've just discovered that "ctags -e -L filelist.txt" works fine when
directly used in a proper windows shell, but does not when used in an
emacs's shell buffer (i.e. that produces the same result, with absolute
paths, as with shell-command)
It sounds to me that the problem is related to an extra termination
character added to the command line by emacs before it's passed to the
shell... But I'm not skilled enough to figure out the details... Any ideas ?