Oh, I quite agree. I'm not being very unfair -- but I certainly didn't say or intend to imply that the script is not at fault.
The one bit of unfairness is I inadvertently lay the blame for "the problem" on your IT department. I intended only the blame for your inability to bypass the (entirely foreseeable) problem! LONG experience tells me developers should not work under C:\Documents and Settings. It's an unfortunate reality that scripts VERY frequently fail under this condition, and thus it is prudent for we script users to avoid triggering the script-writers' bugs. The point about your OS was not that this was the cause of your problem! I was pointing out that this problem was so common, Microsoft even got rid of the space in later OS versions. The vast majority of the software you run does not involve scripts. It's very unusual for applications to have this bug. But it's tricky getting the quoting right when you're building a command-line in a script. It's somewhat harder with cmd.exe than it is with the various Unix shells, but it's tricky in either environment, and so often not tested. I've even fallen into that trap myself. So have a bit of sympathy for the script writers! But nonetheless, you are entirely correct that there was a serious testing failure involved here. This is absolutely something that should be part of the testing for any publicly-distributed script, on any platform. Just FYI, and not relevant to this issue at all -- XP has by most measures, at this point, dropped below the 50% point -- and that includes ancient home computers never upgraded, computers in the third- world, pirated copies, etc. Tricky to measure, tricky to even define what you want to measure. But given the insecurity, lack of support, lack of support for current hardware, and even application compatibility issues, it's not so common now in a corporate setting, though there are some glaring exceptions. I even know of a large corporation still on Windows 2000 as of a few months ago. But the reason I brought up IT is because it MAY (or may not) be a viable strategy for you to make it their problem. I would strongly recommend that you actually try this, regardless of whether it's likely to succeed, because if you do succeed, you will avoid future script problems as well. Just don't put all your eggs in that basket. I didn't intend to imply this was hopeless; I only intended to acknowledge that it might not be viable in your environment. On Dec 19, 12:28 pm, H <[email protected]> wrote: > Thanks for your comment, but you are being a bit unfair there. Competent IT > department or not, there really shouldn't be a problem with spaces in the > folder name as the vast majority of all the other software I run on my > windows machine has no problem whatsoever. > > I don't want to get into the argument about the number of developers on > windows and the number on other machines, but surely the windows users are > still a sizeable proportion of android developers. So this release of ADT > should have at least been tested on a standard build of windows - the > windows build being the most used, which is still XP, I believe. If this was > the case, they would have spotted that (a) the default for eclipse is to put > a workspace under "Documents and Settings" and (b) the default for a temp > folder is under the "Documents and settings\Local settings\temp". > > Telling me that I'm using the wrong operating system is not helpful as the > android dev documentation clearly says that this all works on windows and > also on xp. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
