My organization has a group policy in effect that will only allow executable programs to reside under the Program Files (or Program Files X86) directory. Obviously, these directories are not writable by normal users. I have access to local admin rights, so I can install things there if I want. But of course it doesn't make sense to put the whole cygwin tree there, since users need to be able to write to /home, /tmp, etc. I am thinking I might be able to do something with links, maybe install to c:\cygwin, then move just the /bin directory under Program Files and create a hard link to it?
Has anyone run into a similar situation and come up with an elegant solution? This is Win 7 Enterprise.
Prior to Cygwin 1.7.34, solving such problems required a fair bit of hoop-jumping,¹ but now it's easy:
If you haven't installed Cygwin yet, do so.²
If you have Cygwin installed already and you started with a version of Cygwin prior to 1.7.34, move /etc/passwd and /etc/group out of the way,³ then upgrade to the current version.
Start the Cygwin Terminal.
Open Cygwin's /etc/nsswitch.conf in your favorite text editor.⁴ Add a line like this:
db_home: /%H
That's it! When you next re-start Cygwin, it will treat your Windows profile directory as your Cygwin home directory.⁵ This means you will have useful sub-folders like Desktop and Downloads as sub-folders, which matches the way OS X and a lot of desktop Linuxes work.
Some people might not want these two directories to be treated as equivalents. You can choose any path scheme you like. For example, you could change it to /cygdrive/c/Users/%U/cygwin to put your Cygwin home folder into a cygwin subdirectory of your Windows profile directory.
This new feature of Cygwin is very powerful and can do a lot more than I show here. For example, you can change a Cygwin user home directory via AD instead, if you like. See that documentation for details.
You might also want to rearrange a few other elements of the Cygwin path scheme. You can do so by editing Cygwin's /etc/fstab file. You probably want to move /tmp, /usr/tmp, and /var/tmp to a directory that non-admin users can write to, for one thing:
c:/tmp /tmp ntfs auto 0 0
c:/tmp /usr/tmp ntfs auto 0 0
c:/tmp /var/tmp ntfs auto 0 0
This will let you install (and later update) Cygwin as an Administrator while still letting unprivileged users run Cygwin. This makes Cygwin behave more like Linux or Unix. Since most software in the Cygwin package repository comes from that world, you can count on it to behave correctly under such a scheme.
Footnotes:
The first version of this answer tells you how to do an equivalent thing with older versions of Cygwin.
Cygwin doesn't care where you install it, so if the default doesn't work for you, feel free to change it. Some ideas:
C:\Program Files\Cygwin
C:\Users\jeremy\Cygwin
D:\cygwin
Cygwin will remember your choice on subsequent updates.
If you don't move these files out of the way, they interfere with the solution we build above. This part of Cygwin is complex enough to deserve a whole section in the Cygwin user manual. Hint. :)
Cygwin installs a stripped-down version of the Vim text editor by default.
If you don't like vi, there are many other text editors in the Cygwin package repository.
If you do like vi, I suggest installing the full version of Vim, then adding alias vi=vim to your ~/.bashrc.
You can also use a native Windows GUI text editor. Cygwin's /etc/nsswitch.conf parser appears to cope with DOS line endings.
The Cygwin DLL is building this path from the %HOMEDRIVE% and %HOMEPATH% environment variables, then converting it to POSIX form.
Related
I maintain a private Git repository with all of my config and dotfiles (.bashrc, profile.ps1, .emacs etc.).
On Windows this repository is stored under C:\git\config. Most applications expect the files to be elsewhere, so I added hard links between the repository and the expected locations.
Example
On Linux .emacs is located in ~/git/config/.emacs but emacs expects it to be at ~/.emacs. I run:
$ sudo ln -s ~/git/config/.emacs ~/.emacs
On Windows my .emacs is located in C:\git\config\.emacs, but emacs expects it to be in C:\users\ayrton\.emacs. I run:
PS> cmd /c mklink /H C:\users\ayrton\.emacs C:\git\config\.emacs
Issue
On Linux this seems to work fine: when I update the original file, the contents of the link update and everything stays in sync.
On Windows, the links break after a period of time and the files become out of sync (the file contents are different).
Why do the links break on Windows? Is there an alternative solution?
I've seen this StackOverflow post: Can't Hard Link the gitconfig File
So I’ve finally found a solution that takes the best of both: put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory. Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case. You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
The problem here is that the expected locations are different on Windows vs. Linux. For example, VSCode expects the user settings to be in:
Linux: $HOME/.config/Code/User/settings.json
Windows: %APPDATA%\Code\User\settings.json
Ideally I would like my repository to be platform independent. If take the core.worktree approach (e.g. make core.worktree be / or C:\, then exclude everything except specific files) I would have to maintain two copies of some configuration files when their absolute paths differ across operating systems.
Hardlinks can break if a editor opens/creates the file as a new blank file each time you save. It would not surprise me if Notepad did this because it reads the entire file into memory and has no need for the original file after it has loaded the file.
You can try to create a file symlink instead of hardlink on Windows.
I'm working a programming project from school and decided to give Bash for windows a try. I downloaded the skeleton files for the project and pasted them inside the folder where my bash home folder should be. When I open the terminal and go inside the folder it shows as if there was nothing there even though I'm at the right folder. How can I get the files to be displayed?
EDIT: By now, there is actually a supported way to access these files. You have to use the \\wsl$\Legacy "network" share. For example, you could access your WSL home folder in Windows using \\wsl$\Legacy\home\<username>. Still, you should not directly access the lxss directory.
You are not supposed to touch the LXSS folder ever. The files there are use special attributes which are not understood by normal Windows applications to provide the features of a full Linux file system which NTFS on its own can't provide.
There is one hard-and-fast rule when it comes to Bash on Windows:
DO NOT, under ANY circumstances, create and/or modify Linux files
using Windows apps, tools, scripts, consoles, etc. Creating/changing
Linux files from Windows will likely result in data corruption and/or
damage your Linux environment requiring you to uninstall & reinstall
your distro! Note: Your “Linux files” are any of the files and folders
under %localappdata%\lxss – which is where the Linux filesystem –
distro and your own files – are stored on your drive
If you want to copy a file into a WSL directory which is not under /mnt, then use WSL to copy the file, i.e. use cp /mnt/c/original/folder/of/the/file.txt ~/ for example.
A more advanced alternative is starting a local SSH server in WSL and using Win-SSHFS to mount the WSL root as a drive in Windows. This way, file access will go through WSL.
Its unclear what you're asking in your question. What did you paste? Whole files? Text? Where did you paste it? Did you do the pasting into the bash window? If so was it inside a text file or did you just paste to the prompt? I'm going to assume that you pasted files to the directory that you believe that your bash home opens in i.e ~/. You may not be pasting the files into the correct directory because the default directory for bash on windows is not where you would assume it to be. you should be able to reach your desktop by typing cd /mnt/c/Users/yourUserNameHere/Desktop
I just installed babun, a variant of Cygwin. I want the cygwin user home directory to equal my windows home directory.
So, to be clear, I don't want to add the cygwin home to the C:\Users as a new user, I want it to be the same as my current windows home directory.
Now, according to this post, How can I change my Cygwin home folder after installation?, there is a neat way to make the cygwin home directory point to your windows home directory.
You open the file /etc/nsswitch.conf and make sure is has a line db_home: windows. However, after restarting my pc, echo $HOME still says /home/chiel.tenbrinke, which is not what is should be. It should say something like /cygdrive/c/Users/Chiel.tenBrinke.
Why is this not working?
My cygwin version is CYGWIN_NT-6.1-WOW IM-Chiel-2015 1.7.35(0.287/5/3) 2015-03-04 12:07 i686 Cygwin.
Babun has a surprisingly good FAQ. The last entry in the FAQ is How to Use the Windows home directory as Babun's home directory?
For me, it boiled down to:
Create an env var for $HOME = /Users/my_account_name via Win+R sysdm.cpl
Run mkpasswd -l -p "$(cygpath -H)" > /etc/passwd
Run babun install
I'm not sure why Babun doesn't recognize the standard cygwin setting in /etc/nsswitch.conf, and I'm a bit surprised there was no mention of this setting in the Cygwin FAQ. I'm a bit concerned that in spite of what a great collection Babun is, it may fall out of sync with Cygwin quickly if not properly maintained.
I tried an easier way and works perfectly so far.
Just mv your home folder to the location you want, and make a symlink
The first execution after move may prompt errors, run babun install will fix everything.
in /etc/nsswitch.conf
db_home: /cygdrive/c/Users/%H
Heading says it all really. Using Windows 7 and latest stable gvim, whenever I save (:w) a file it's marked executable. I'm doing cross-platform development and it'd be nice if this didn't happen.
#sceptics: The flag of the files are indeed set as executable. Do a ls -al before and after re-saving the file to observe the issue. (install cygwin, or may be other *nix emulations)
#OP: the question have been raised several times in the past. I don't remember the conclusion on the subject. You should search vim mailing-lists archives (vim_use and vim_dev).
May be you can try to add an hook to your RCS (if it supports that) to proceed to a chmod -x on file extensions that does not correspond to an executable (*.h, *.cpp, *.vim, ...), or on files that do not contain a shebang (unlike perl, I don't know if python source files may contain a shebang)
Is there some sort of general pathname-rewriting/normalizing facility I can exploit in Emacs to allow source files in compile-mode to be translated to local paths based on remote paths? I was hoping to use symbolic links, but that's not working for me in Windows.
I'm running GNU Emacs 23.1.1, and have tried cygwin-mount and w32-symlinks.el (with (customize-option 'w32-symlinks-handle-shortcuts)); I can't get open-file/dired/completions OR compile-mode next-error to follow either windows shortcuts or cygwin symlinks.
I'm remotely compiling (over ssh) and the warnings/errors give filenames where a prefix of the absolute pathnames (e.g. /nfs/topaz) on the remote host needs to be replaced with a different path (z:/, in fact), which I was hoping to do with symbolic links.
/ does go to (gets tab-expanded to in emacs) c:/cygwin and ~ to z:/ (my $HOME).
What I'm hoping for is either: a fix for symlink resolution (tab completion or opening a windows shortcut gets me the .lnk file and not what it points to), or the ability to supply a list of rewrites for prefixes of pathnames. Junctions aren't an option because the replacement path I want is on a different drive (it's also a Samba mount).
Here's a partial solution:
(custom-set-variables '(compilation-search-path (quote (nil "z:/dir1" "~/dir2"))
etc. Of course, I have to add dozens of paths, but it's a huge improvement (next-error actually works now!)
This is also useful in other complicated build environments: I use OpenWRT, and the build process copies (or extracts) source code to a separate build directory in which compilation occurs. So naively following file names in the emacs compilation buffer leads to edit the temporary copies, not the originals. Dangerous.
After re-reading a few times, I still am not quite sure what your situation is -
Are you compiling remotely and editing locally? If so, it seems like you should try doing both tasks on the same machine, or maybe try tramp mode in emacs. I just don't see an easy way to translate a remote path to a local one.