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

[Bob Proulx]

David Chappaz wrote:
> Bob Proulx wrote:
> > > 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.

Oh good.  We all have to start somewhere.

> 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 !

Yes.  That way is much more normal.  Because the find is doing
something useful and contributing positively to the overall task.
That way is a very typical way of doing things.  Good!

Unfortunately it suffers problems when people embed newlines inside of
filenames.  As long as you don't do that, and it is unusual to do so,
then I would keep on doing it exactly that way.  Not using newlines in
a C source code file name is good conventional practice.  If I found
anyone putting newlines in a C source code filename I would convince
them otherwise.  :-)  So you are fine.  But it is useful to understand
where the convention breaks down.

> 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 -

I can now see how you got there.  Like most things knowing the
background story fills in all of the details and makes everything make
sense.  (But in case anyone jumped into the thread here we are all
agreed that the improvement below is better.)

> > 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...

Yay!  Much simpler and more direct.  Simple is good.

> > 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 !

Drat!  I was hoping that the direct filename method would clean things
up and solve your problem.  I don't really have any other hints.
Because I can't recreate your problem.  It works fine for me.

> > 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.

Can you make out the filenames that it is getting from the output?
Can you do some testing and try to figure out what filenames are being
added to the command?  I think if you could deduce what the extra file
names are then that would be a huge big clue to determining where they
are coming from and then fixing the problem.  Perhaps using 'echo' to
echo the args out would be useful.  But the problem is that you are
using an operating system that I don't know the right debug techniques
and so do not know what to suggest.  I would suggest echo but I fear
that the echo I would see and the echo you would see would be
completely different and that will just confound things.  For me a
program such as echo that just echo printed all of its arguments would
allow me to see the extra arguments supplied.  But I don't know what
it will do on your system.  It may or may not be useful.

  M-! echo

> > 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,

That makes sense so far.

>                                           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 like a bug in your port of emacs in the area of
shell-command.  Is there a different port that you could try?  Maybe
it would behave differently.

> 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 ?

I am one of those people what has been using Unix and GNU systems all
of my life and have virtually bypassed ever using an MS machine.  When
I try to use one I am lost and frustrated.  Which is why I have
sympathy for people going the other direction and try to help out when
I can.  But it means that I really have no advice available for you.

Since it looks like an operating system interface bug in shell-command
I think I would try to work around it by using a helper script.  I
would create a helper script which did the actions I wanted (find
piped to ctags in this case) and then call the script instead of the
raw commands.  That could help debug things too since then once you
are inside the helper script you can add more debugging there.

Bob