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

[David Chappaz]

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

I tried, and tried... but didn't succeed. From a plain shell, "more" does
not insert any header, unless there are multiple files Now, when I do "more
test1.c" from shell-command, a header is inserted (as if there were multiple
files), but no second or third header appears (as if there was only one...),
would it be with a blank file name.

But I'm only seeing this behaviour on linux, and although it might be
related to my problem (on windows), it doesn't really affect me. Perhaps
this is something you can reproduce and investigate.

Now, on Windows, 

> > I've just discovered that "ctags -e -L filelist.txt" does not [work] 
> > when used in an emacs's shell buffer (i.e. that produces the same 
> > result, with absolute paths, as with shell-command)

After more detailed investigations, I've found out the following.
If, before doing M-x shell, I evaluate

(setq explicit-cmdproxy.exe-args  '("/q"))

to prevent shell commands from being echoed, then suddenly the TAGS file is
generated properly, with relative filenames. 

In other words, the same command has two different behaviours when issued in
an emacs shell buffer, depending on if explicit-cmdproxy.exe-args is set to
"" or "/q". That does not make any sense, or does it ? 

Something looks really odd. Also, shell-command is not affected by the value
of explicit-cmdproxy.exe-args, and always behaves the same.

> Which is why I have
> sympathy for people going the other direction and try to help out when 
> I can.

I appreciate your support, and even if you're not a MS-Windows expert, your
ideas are very welcome !
To be honest, most of the time I use emacs on linux, so the lisp package I'm
developing works fine. But occasionally I use it on Windows, which is why
I'm trying to get it to work on this platform too... 
 
> 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.

Yeah, in the short term, that's a very good plan indeed to work around the
problem!