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: Bob Proulx
Subject: Re: shell-command causes problems with absolute/relative paths in TAGS
Date: Wed, 4 Jan 2012 22:41:42 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

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.

See your message in context here:

  http://lists.gnu.org/archive/html/help-gnu-emacs/2012-01/threads.html#00035

David Chappaz wrote:
> Note that I'm using GNU Emacs 23.3.1, with Exuberant CTags 5.8

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 -

The -L means to read from a file list.  So this is running more, a
screen pager for human consumption, and then piping that to ctags and
telling ctags to read the standard input.  That is a lot of work to do
to accomplish that task.

Also, search the web for "useless use of cat".  This is the same thing
but just using a different program in the same way.  In other words,
don't try to substitute cat for more in the above.

Instead have you tried simply running ctags on the file?  Try this instead:

  ctags -e -L filelist.txt

That should work more reliably the same on all operating systems.
Expecially since pipes on MS-Windows are not speedy.

> 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

If there are multiple files then more can page through all of them and
therefore more shows a visual indicator between files.  Also 'head'
and 'tail' do similar things.  If you are seeing this then more is
trying to page through multiple files to the human.  It isn't intended
to be piped like that.

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.  That is probably somehow related to
your difference in behavior of relative paths versus absolute paths.
In the simple command line case I am sure it is what you see is what
you get.  But in the shell-command case I think a completely different
set of files is being stuffed into the ctags standard input and
because those are different files they only appear to be absolute
versions

I don't have any comments on the other questions about MS since I do
not have that available for testing.

Bob



reply via email to

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