Another partial work around, indirectly, is not to install
stuff deep in a file hierarchy and never to use spaces in
directory or folder names.
For example, I always install a new release of
Stata in a directory like c:\stata8, never
in c:\program files\stata\stata 8, or wherever.
This may be frowned upon as a violation of
Windows conventions, but the advantages
of less typing and never having to worry
about spaces are considerable over some years
of use.
Naturally, this presupposes that "you" have
control over what goes on "your" machine
and where. I have heard of set-ups where it is presumed
that what comes with the PC and what is provided
by the university centrally will provide all that
you need for research: the possibility that a
researcher would have personal software needs and preferences
beyond this provision was not entertained.
Nick
[email protected]
Stas Kolenikov
>
> An ugly workaround for this is to write the path as
> c:\progra~1\ provided
> that you don't have any folders under c:\ with names starting with
> sequence "progra". Chances are there won't be any... but if you do,
> they'll be named progra~2, progra~3 etc. in order of
> appearance, whatever
> that might mean to Windows. This is the way the long file
> names used to be
> stored under FAT32 file system with 8.3 symbols convention.
>
> If you need to pick a name from registry or an environment
> variable to use
> in your -shell- call, chances are it comes with spaces in it,
> so it might
> be difficult to abbreviate the name properly, other than to
> parse it fully
> with -tokenize, parse("\")- and then abbreviate each token to
> "??????~1".
> It should not take too long to patch Stata kernel at Stata
> Corp side, but
> in the meanwhile you can use this (not very reliable) trick.
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/