The prompt says that if I install the software into a directory with spaces:
the rebuild build tool used by the D Shared Source System will fail to build
and that I will be
forced to reinstall in a different location
However, I don't like random things in my C:\ drive. D, IMO, belongs in Program Files with PHP and MinGW and so on. How can I get it here?
If it matters, I'm using the Easy D installer package.
You can also use NTFS Link to create junction points (symlinks for all intents and purposes) and hard links on NTFS file systems. The functionality is built into the NTFS drivers, but an interface was never implemented for it, presumably to avoid things like recursive directory structures (endless virus scan loops anyone?). This package exposes an interface to this functionality.
I'd then create a symlink from C:\Program Files\ to something like C:\ProgramFiles\, hence disposing with the problematic space. This means that anything added to one directory will be added to the other, because both directories point to the same place on disk.
More info on NTFS Junction Points.
Info on NTFS symlinks (Vista only, but doesn't need NTFS Link to be installed.)
You could try using the old DOS 8.3 name for the Program Files directory, although this solution is implementation- and locale-dependent, and thus somewhat deprecated. On most US English systems, the 8.3 name of the C:\Program Files directory is C:\PROGRA~1. So, instead of installing to "C:\Program Files\dmd", you'd install to "C:\PROGRA~1\dmd". Hopefully, the configuration files for the misbehaving programs won't know the difference.
You could install it into C:\Program Files, and then use the subst command to make it appear as a new drive letter:
subst x: "c:\program files\d"
I actually use a "c:\Programs" for situations such as this - quite a few applications don't work well in directories with spaces in them.
It doesn't cause confusion since it's different enough from "c:\Program Files" - earlier attempts used "c:\ProgramFiles" (without the space) but this was too similar.
I have a C:\Dev folder on my machine for things like this. That way you only have one folder on the main directory and it stays unclutered.
Related
How do I configure Vim running under Windows to be able to edit Golang code? I have spent 3 hours trawling through incomplete, self referential guides on this subject and I grow weary with the resultant frustration.
Ok more details. I have Vim installed. The folder structure is:
Program Files (x86) -> Vim
vim80
autoload
colors
...
vimfiles
An example of my confusion is the fact that the installation guide to vim-plug, in the sections about Powershell, simply says to issue the line:
md ~\vimfiles\autoload
What are these folders relative to?
I have an existing autoload folder but it is under the vim80 folder, hence my confusion. The aforementioned folder structure is the default one created by the Vim installer.
The ~ in powershell refers to $HOME wnich by default means %USERPROFILE%
So ~\vimfiles\autoload are user settings used by vim80/autoload.
The ~ characters is your Userprofile as said by VonC.
You can therefore create the vimfiles folder under your user directories:
C:\Users\username\vimfiles
These will be loaded after the core files under the vim installation location Program files(x86)\Vim\vim80 but both folders same a similar purpose.
Using the user directory is recommended if multiple users are using the same vim installation while having different plugins and a different vimrc.
Note that this also works with the vimrc file:
You can place your _vimrc or .vimrcin C:\Users\username\ and it will be loaded by vim.
I'm using Windows 10.
I want to give Vim another shot after having some troubles with it in the past. I'm eager to learn it, but I'm confused. I gave a pretty thorough search to find my answer before I resorted to posting this here, but what is the proper way to install my vim plugins. I see two vimfiles folders in two different directories.
One in the $HOME directory.
C:\User\[USERNAME]\vimfiles
And one in the installation directory.
C:\Program Files (x86)\Vim\vimfiles
Is there a reason for there being two of these ? What's the best directory to install my plugins ?
It is related to 'runtimepath' param. Read :help 'runtimepath' for more info . C:\Program Files (x86)\Vim\vimfiles is system folder with default plugins which are shipped with vim itself. C:\User\[USERNAME]\vimfiles is your local runtimepath. And there you should put your plugins. This way if you have multiple users they all will have own vim environment to work in. If you want you can even set different runtimepath but this is whole another question))
C:\User\[USERNAME]\vimfiles is your vim runtime files and C:\Program Files (x86)\Vim\vimfiles is Vim's runtime files. As long as a feature is present in your vim runtime files and vim request it, it will load them and if its not present there, then it will fallback to his runtime path to find it (i.e. C:\Program Files (x86)\Vim\vimfiles ). So you should always install your plugins, colorschemes, syntaxes, ... in your vim runtime files and also back it up in a safe place and never touch vim's runtime files.
The TexLive system uses lualatex. I have an application that needs to know the location of lualatex.exe.
Now, if lualatex is in the PATH evnvironmental variable, I'm in luck. If it isn't there, then I have to go and do a full-computer file-search for the file.
Is there another way I could find it?
I mean, is there some lualatex registry value or directory that is standard in every installation?
[update]
Okay, I have found a certain standard; if TexLive is installed, in the %userprofile% directory, there will be directories for .texlive2012 or .texlive2013 - I wonder if there is a way to use that knowledge to find the installation directory. The contents of those folders do not reveal anything, however.
It depends on what LaTeX installation you are using. If it's MikTeX (under 64 bit Windows) it will be in
C:\Program Files\MiKTeX 2.9\miktex\bin\x64\
So I think it will always be in "the bin folder".
I primarily develop on Linux where there is /usr/bin and /bin directories. I know that Windows does not have any real equivalent of either of these besides C:\Windows and C:\Windows\System32. Many command line programs that I port to windows, I simply will write an installer that will copy them to C:\Windows, because I do not feel like having to set a PATH variable. I know that the proper way is to set a PATH variable, but to me C:\Windows is == to /usr/bin. What do Windows programmers have to think about this? Is this a good habit, is there any real disadvantages, and should I actually install to Programs Files and set a path variable via the registry instead?
Install to Program Files (or even the user's AppData folder for user-specific installs), and provide an option to add the directory to %PATH%.
Installing to Program Files has a number of advantages:
Won't conflict with any other files that happen to be in C:\Windows
Won't override some other tool already on the user's PATH
Makes the components of your program more obvious, instead of a random scattering of files in C:\Windows
Avoids dependency conflicts (DLL hell) if you need to include your own DLLs
Giving users the option to add to %PATH% allows users to skip that step if they run into some other kind of conflict with your app (which is less likely with Program Files, but still possible). If you installed into C:\Windows, you'd have no way to avoid such conflicts.
You should install applications to the proper Program Files directory, generally; there are exceptions though. And there are numerous Environment Variables already set for numerous paths on Windows, %PROGRAMFILES% being one of them (and %PROGRAMFILES(X86)% being another, hence 'appropriate' path).
I'm reinstalling everything on my machine, and amongst those is Cygwin. I'm trying to avoid reinstallation, partly because I don't even know what it is that I've installed. Can I just move the Cygwin directory from one machine to another and expect everything to work, or are there some other important settings that I need to move as well?
As far as I saw, it's pretty self-contained, but one never knows.
Yep! Go for it. You won't encounter any problems.
You can just copy the entire cygwin directory to your new machine, open up the cygwin shell and everything (as long as you are only calling cygwin-internal programs and stuff that's within the path) will just work as if you you are working on your old machine.
The only thing you'll loose is the directory where the "already downloaded and compressed" packages for a possible re-installation are stored. Fortunately this directory is optional, so no problem for migration to another platform. You could copy that directory as well, but most likely all the packages that you have are outdated anyways and a run of setup.exe would fetch the new versions anyway...
Btw - since someone said exactly the opposite some real-life experience: I use this feature quite often with success. I've copied my cygwin dir to USB-sticks and used it on friends computers. I also copied it to the laptop of my fiance when we go to holidays and take a laptop with us.
It always worked without any problems....
The short answer is: No, you can't copy the whole Cygwin folder. You just copy the configuration files(bash files, vim file, etc.) you need.
The long answer is: If you copy the whole Cygwin folder, it may work in some case, and may not in some other case.
The reason is: you will lose linux file mode when copying files on Windows. And that will cause a lot of troubles. However, you may not have the troubles when you use Cygwin just like a common Windows Program(which means you don't care file mode and anything related), and run it as Windows Administrator(which is not required when Cygwin is installed as usual).
BTW: you can export the packages you installed by cygcheck.exe -c and install them on the new Cygwin. You can also install/update Cygwin packages by Cygwin's setup-x86_64.exe in command line like:
setup-x86_64.exe -q -P package1,package2,package3
No, you have to reinstall it from the cygwin installer, sorry!
Most importantly you'll want to copy everything from your home directory (default is c:/cygwin/home/) especially anything w/ a "." in front of the filename.
As for individual application preferences, etc., you may lose those -- but if you do the reinstall while you still have access to your old machine -- you can probably get to 90% of your previous install without too much trouble.
My experience with copying from one cygwin64 (I don't think there is a difference) to another machine is that all of the symbolic links got crushed:
As an example:
What used to be /usr/bin/cc -> /usr/bin/gcc.exe (or something like that)
After the copy /usr/bin/cc became a text file containing the string:
!<symlink>/usr/bin/gcc.exe
My method of copy was merely cp -r /cygwin/c/cygwin64 <dest>
My dest was a FAT32 FS, but I don't think that had anything to do with it.
There were also characters 0x00 and 0xFF sprinkled among many of these 'text' files so that they appeared to be binary.