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).
Related
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 wish to store my Mac, Windows and Linux vim configuration files in git. On *nix systems, your vim configuration files go in ${HOME}/.vim but for the Windows binary, the same directory is named "vimfiles" Can I configure git to accommodate the different directory name?
You don't need to configure Git, just tell Vim to use ~/.vim for Windows, too, by putting the following fragment into your ~/.vimrc:
" On Windows, also use '.vim' instead of 'vimfiles'; this makes synchronization
" across (heterogeneous) systems easier.
if has('win32') || has('win64')
set runtimepath=$HOME/.vim,$VIM/vimfiles,$VIMRUNTIME,$VIM/vimfiles/after,$HOME/.vim/after
endif
My setup is very simple.
On Mac, the versioned directory is:
/Users/username/.vim
On Linux, it is:
/home/username/.vim
On Windows XP (yes), it is:
C:\Documents and Settings\username\vimfiles
They all point to the same GitHub repository.
My settings are stored in a vimrc (no . or _) file located at the root of the repository. Therefore its versioned and commited/pushed/pulled like all the rest.
The actual default user-specific vimrc,
/Users/username/.vimrc
/home/username/.vimrc
C:\Documents and Settings\username\_vimrc
is a real file, no need for a symlink. It contains only one line:
runtime vimrc
that tells vim to read, and execute, my vimrc.
Because of how :runtime works, I don't need to use a real absolute path which would be different on Unix-like platforms and on Windows.
Setting up a new machine or user is as simple as cloning my repo and typing two easy to remember words.
I also need to share config files for vim and other applications between multiple systems, and I found that git was not only overkill but also required manual syncing on each system to get the latest updates and to publish changes. A better solution for me is to put these config files into Dropbox, make all of my systems connect to my Dropbox account, and create symbolic links to these shared files.
For example, I put my vimrc file under Dropbox/conf/vimrc, and then did
ln -s ~/Dropbox/conf/vimrc ~/.vimrc
You should be able to use Windows' mklink to similar effect to create a _vimrc symlink to that same file. In the same way, a common Dropbox/conf/vim directory could be linked to locally as .vim or .vimfiles or whatever your OS' vim executable prefers.
Dropbox keeps a history of changes over the last 30 days, which is enough to handle recovering from most problems for which I needed git. The cool thing is that you can add that new macro or setting to your .vimrc and it is automatically available on all your systems.
Of course this approach is also handy for your other config files, too (.gitconfig, .gitignore, .bashrc, etc.).
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.
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.