| RE: [cdt-dev] The Shell Game |
|
Hi Chris, This doesn’t answer your question
either, but is https://bugs.eclipse.org/bugs/show_bug.cgi?id=113279
“forward vs back slashes” the same
sort of issue? That is, is the “slash” issue a “shell”
issue, an OS issue, a Tool issues, or something else? If it’s a shell
issue, we might as well consider it at the same time. Regarding “Do we
need to do anything about this right now”, how many bugzillas do we have
requesting support for spaces? Leo From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Recoskie, Chris So I’ve been working for the past week or so on
getting MBS to build files and folders with spaces in them. I’ve
been largely successful thus far, but along the way I ran into some issues
which I thought would be good to bring up. To summarize, I got everything working nicely for the GNU
toolchains under CygWin. But when I tried using the code for my own,
non-CygWin based toolchains on Windows, things started falling apart, because
the way that commands are passed to the shell under bash doesn’t work on
windows. For example, on bash, one can escape special characters in
filenames via use of the backslash. Coincidentally, GNU make also will
let you escape spaces in the same manner. Thus, it was very convenient to
say have an OBJS macro that held a list of object files, and to invoke the
linker with said macro as its input. However, on Windows this broke down,
because the Windows shell (cmd.exe) wants the filenames in double quotes. As a result, in my own makefile generator I had to create
another macro, OBJS_QUOTED, that would hold a list of the objects without
backslashes escaping the spaces, but rather with quotes surrounding each entry.
For the dependencies in the makefile I use OBJS, but for the linker
invocation I use OBJS_QUOTED. A hardcoded hack, but it works. I am thinking other people are going to run into this on
Windows, so I’d like to somehow include a proper solution in CDT rather
than resorting to this sort of hackery in my own non-CDT generators.
However, I’m not entirely sure yet the best way to go about this,
as right now we have no way of telling what shell the user is using, regardless
of host OS. I can’t for example assume that the user is using bash
even in a CygWin environment, because they might be using tcsh or some other
bizarre, custom shell of their own creation. A one-size-fits-all solution
for a given platform will not fully cut it. Since there is no universal
way to determine what the user’s shell is (at least not to my knowledge),
it seems like we would need some sort of user configurable setting for shell
properties. That all being said, my time is a bit scarce right now given
my existing workload. So, right now my current plan of action is to just
leave things as they are. Things in MBS will work as far as I know for
our primary environments that CDT supports out of the box, but those working on
other environments will be somewhat out of luck. So, I ask: a) Does anyone
else think that this issue is going to affect them when using their own
toolchains? b) Does anyone
else think that this might be an issue that affects other parts of CDT?
(Launching/Debugging comes to mind… e.g. will launching a debug session
fail if you try to debug an executable with spaces in the name?) c) Do we need
to do anything about this right now? ___________________________________________ Chris Recoskie Software Designer http://eclipse.org/cdt |