From: Bob Proulx <bob@proulx.com>
To: David Chappaz <david.chappaz@free.fr>
Cc: help-gnu-emacs@gnu.org
Subject: Re: shell-command causes problems with absolute/relative paths in TAGS
Date: Wed, 4 Jan 2012 22:41:42 -0700 [thread overview]
Message-ID: <20120105054142.GA10149@hysteria.proulx.com> (raw)
In-Reply-To: <AA798C0D220E44E5B798734A70C4CF93@EUROPE.ROOT.PRI>
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
next prev parent reply other threads:[~2012-01-05 5:41 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120105054142.GA10149@hysteria.proulx.com \
--to=bob@proulx.com \
--cc=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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).