I'm battling with cygwin for quite a while now.
I searched far and wide on how to make cygwin create Windows-style symbolic links.
I tried the following:
export CYGWIN="winsymlinks:native"
export CYGWIN="winsymlinks:nativestrict"
export CYGWIN="winsymlinks:lnk"
I also tried exporting w/o the quotes.
I also tried from both cygwin/x86 and cygwin/x64
For the life of me - I can't get the Windows native symlinks to work.
I'm working on Windows7/64bit; cygwin version 1.7.25.
I'd love to get a solution for this one.
Thank you.
I got the same problem. In my case, I used winsymlinks:nativestrict and received an error report saying: Operation is not permitted.
This is becase of Windows UAC and the terminal emulator not being started with elevated privileges. So I run Cygwin mintty as administrator (you can right click the shortcut and choose "Run as administrator" or set the mintty shortcut property: Advanced -> Run as Administrator). After that, everything just works perfectly.
I also battled with this one for a while on Windows 7 with Cygwin.
Everything I read seemed to say that it needed export CYGWIN="winsymlinks:native", but no luck for me.
Then I read this blog http://zzamboni.org/blog/making-cygwin-windows-and-emacs-understand-th/ which said that just "winsymlinks" was all you need. Tried that and it worked beautifully :)
Just use this environment variable.
export CYGWIN="winsymlinks"
Expect it to work with Windows 10 Creator update when you enable developer mode
Something to consider:
https://github.com/git-for-windows/git/wiki/Symbolic-Links
Symbolic links are only available on Windows Vista and later, most notably not on XP
You need the SeCreateSymbolicLinkPrivilege privilege, which is by default assigned only to Administrators and guarded by UAC, but can be assigned to other users or user groups (see below).
Symbolic links on remote filesystems are disabled by default (call fsutil behavior query SymlinkEvaluation to find out)
Symbolic links will only work on NTFS, not on FAT nor exFAT
Windows' symbolic links are typed: they need to know whether they point to a directory or to a file (for this reason, Git will update the type when it finds that it is wrong)
Many programs do not understand symbolic links
Related
Recently switched to new windows terminal, and after hours of searching on internet I was not able to find anything helpful, all what I want is to set up cmd inside new windows terminal to show git branches just like it's achievable for powershell.
eg like this
I have been very comfortable with cmd especially with its ability to use additional linux commands and don't wanna switch to powershell only because of nice displays of git branches. this is a source where everything is nicely explained for powershell, all I want is to do the same for CMD.
thanks in advance
In order to use Oh My Posh for shell-prompt customization from cmd.exe, the legacy Windows shell (citing from the docs (tab cmd)):
There's no out of the box support for Windows CMD when it comes to custom prompts. There is however a way to do it using Clink, which at the same time supercharges your cmd experience. Follow the installation instructions and make sure you select autostart.
As you later discovered, this issue on GitHub has background information on why native cmd.exe support isn't possible (even though Oh My Posh is generally shell-agnostic) and why third-party software is needed to make it work.
As for your comments re preferring cmd.exe:
I have been very comfortable with cmd
Migrating from the shell one is used to a new one is undoubtedly a painful transition, but well worth considering in this case:
While not without its quirks, PowerShell is vastly superior in just about every respect to cmd.exe, and enables you to do things you simply cannot do in cmd.exe
its ability to use additional linux commands
Linux (WSL) commands called from the Windows side are all mediated via executables (notably wsl.exe and bash.exe), which you can equally call from PowerShell.
I have a French client with the French version of Windows 10. However, our Installshield-built installer is looking for C:\Users\username\Local Settings\Application Data, and fails with "Error 1320. The specified path is too long"
We tried to see if we could connect to the appropriate Local Settings\Application Data folder (in English), but it is either not accessible or even as admin we don't have privileges to go there (even from an admin command line).
I understand Windows 10 has some sort of invisible aliases or compatibility for these standard folders?
Are there any tricks we could use to get the software installed?
Disclaimer: this is a hack and the correct answer was provided by slugster - rebuild the MSI
Now that that's out of the way I do have a suggestion for you that might be able to resolve the problem for you. You can try creating the path that the installer is looking for and then creating a symlink to link that folder to the correct folder on the users machine. no guarantee that this works but might be worth a shot. If you need more info on creating symlinks check out hte TechNet page for MkLink
How can I figure out where the Windows XP SUA ksh .profile file is on a system where I was not the person who installed it? (I'm searching google for the answer, but the combinations of ksh, windows XP, and profile lead to many, many hits that I am still digging through.) It is NOT in my user directory, so it is probably the system default .profile that I need to find?
Problem, if it has any bearing: The path is radically different before and after I start the ksh, and after the ksh starts it includes some contextually bad paths.
All I really want is to keep the path set up in the cmd.com batch environment from before ksh is invoked, but I think I first need to figure out where the change is coming from.
It is apparently located at C:\Windows\SUA\etc\profile
Open the run dialog by hitting Windows-Key+R and type the following command followed by return:
explorer "%USERPROFILE%"
A Windows explorer window should appear showing the content of the current user profile folder. The file you are looking for may be there or in some subdir, especially inside ApplicationData or Local Settings\ApplicationData (note: I work on an Italian XP version and dir names are localized, thus I may have spelled them incorrectly).
Note that you may have to enable the visualization of hidden files, if that .profile file was saved with the hidden attribute set.
Otherwise you may also search in C:\Documents and Settings\All Users, which is the folder where all settings common to all the users are stored.
This is really just an annoyance, but I'd like to see if someone has solved it.
I really love and need to have the Windows power toy "command prompt here".
I installed it first day on the XP laptop my new client gave me.
It works well in All folders EXCEPT those under the control of Base Clear Case.
If I create a junction (symbolic link) to that folder, and navigate to that, it does show in the pop-up menu.
I am thinking the clear case registry entry is overriding the command prompt here,
but I don't need this enough to muck about in registry on my clients machine.
I have seen it working on snapshot views (which are really simple files/directories on the C: drive), but not on dynamic views (which are mounted directory on the device M:)
The ClearCase submenu shouldn't matter, except it doesn't show up on Windows64.
From technote swg1PK36107:
ClearCase is a 32-bit application, therefore, the ClearCase and Windows Explorer integration will only work in a 32-bit Windows Explorer.
Maybe that limitation might have a side-effect for your own "command prompt here" plugin?
Found an alternative method that seems to work using file associations.
These are set under Tools / Folder Options / File Types in windows Explorer.
Reference Method #3 in the following link:
http://www.petri.co.il/add_command_prompt_here_shortcut_to_windows_explorer.htm
Now on to find the next annoyance.
I've recently installed ClojureBox on a Windows 7 machine after using it on a different, XP machine for a while. When I created and saved a file, it wasn't being saved where I expected, but to the \Users\xxxx\AppData\Local\VirtualStore directory. This happened as long as I wasn't running emacs as the local administrator.
A Google search returned only a couple of hits, and with nothing I could really apply other than to run emacs as a local admin.
Any other way to get around this? Is there a windows setting, or something I could configure in emacs?
Thanks.
You can right-click Emacs and "run as Administrator" which I expect will get annoying quickly. Further, if you launch other apps from inside it you might be misled about the behaviour of those apps under normal circumstances. A better approach would be to save your files somewhere other than under Program Files or the root of C, thus avoiding virtualization.