I use Linux subsystem of windows 10(windows 10 version 1803)
I can use command line:
user#laptop:~$ wslpath -w /c/
C:\
But when I try to use
user#laptop:~$ wslpath -w ~
wslpath: /home/user: Result not representable
Even I use:
user#laptop:~$ wslpath -w /home/user
wslpath: /home/user: Result not representable
why?
how to translate the /home/user to windows path?
my home folder path in windows is C:\Users\winuser\AppData\Local\lxss\home
I expect some command line can give me return that string.
Updated guidance for users of Windows 10 1809 or later:
In Windows 10 1809, we (finally) shipped filesystem integration allowing you to access the files in your WSL distros from Windows via the \\wsl$ UNC path:
If you're interested in the details behind how this works, please visit this blog post: https://devblogs.microsoft.com/commandline/a-deep-dive-into-how-wsl-allows-windows-to-access-linux-files/
This now allows wslpath to provide a Windows-accessible path to files within your distro's filesystem:
In the up-coming Windows 10 May 2020 Update (2004), you won't have to remember the somewhat obscure \\wsl$\ UNC path - instead you'll just click on the Tux (Linux penguin) icon in your File Explorer:
Warning for WSL1 users:
Do not try to spelunk to the %localappdata%\lxss\... folders containing your WSL1 Linux files from Windows - there be dragons!
Please read this post: https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
This guidance has not, and will not change, though it will become less important over time: In particular, WSL2 does not use %localappdata%\lxss - instead it stores your linux files within EXT4 formatted VHDX files delivering near-native IO performance for the distro's local filesystem.
To convert a WSL Linux path to a Windows path use wlspath -w. For example:
$ wslpath -w /mnt/c/Users
C:\Users
$ wslpath -w /usr/bin
\\wsl$\Debian\usr\bin
(Yep, the answer is in the question, but some people, like me, are going to skip straight to the answers without reading the question.) The problem reported by the OP doesn't exist in WSL2.
Related
I use WSL almost exclusively, and only switch to main windows for browsing and running Windows native programs. I have a git repository located at /mnt/c/myrepo. In order to "install" the code inside /mnt/c/myrepo I need to move it to /mnt/c/otherlocation/renamed. Instead of executing cp -r /mnt/c/myrepo /mnt/c/otherlocation/renamed every time I do a git pull from /mnt/c/myrepo, I would like to symlink /mnt/c/myrepo to /mnt/c/otherlocation/renamed. However when I do this, the program which consumes /mnt/c/otherlocation/renamed isn't able to view the "contents" of renamed as a directory.
I have been all over the WSL github repo and issue tracker trying to find a solution to this issue. I see a lot of exclamations about how symlinks "just work". I have enabled every Windows 10 developer feature I can find, I even followed some reddit thread where someone claimed that purchasing Pengwin and creating a symlink from Pengwin would ensure this compatibility, but I still can't seem to make this work.
The basic usage I need, is allow me to view "renamed" as a directory from windows, or for windows to recognize the symlink as a symlinked directory.
from wsl:
ln -s /mnt/c/myrepo /mnt/c/otherlocation/renamed
from windows:
open file explorer
navigate to c:\otherlocation
open mydir and view the contents as if it were a native directory
How do I do this?
Do the symlink in Windows, in cmd.exe:
mklink /d C:\otherlocation\renamed C:\myrepo
It doesn't make sense creating the symlinks in WSL if both directories are in Windows.
This symlink will work in WSL as well.
The solution to this problem is simply to use the relative path when declaring the link. If you want to link from windows to windows, you should relatively path from the current directory and then you can link anywhere you wish.
From the example, instead of this:
ln -s /mnt/c/myrepo /mnt/c/otherlocation/renamed
Do this:
cd /mnt/c/otherlocation
ln -s ../../myrepo ./renamed
Git Bash for Windows (v 4.4.19) mounts "C:/Program Files/Git" as "/" and mounts "C:/Program Files/Git/usr/bin" as "/bin"
This means that /usr/bin and /bin are being mounted to the same exact underlying Windows folder. This creates a problem because bash and git are not recognized unless I add /c/Program Files/git/cmd directly to my PATH.
Is there a config file to change this? Why is the same folder being mounted twice?
Having /bin linked to /usr/bin is something that is now also being done on a number of linux and unix distributions. You can read the rational for that here: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
Make sure, before calling bash, to have your %PATH% (Windows CMD PATH) set to:
set G=c:\path\to\latest\git
set PATH=%G%\bin;%G%\usr\bin;%G%\mingw64\bin
set PATH=%PATH%;C:\windows\system32;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\
You will then see, in a bash, session that:
/usr/bin is set to the full content of %G%\usr\bin and %G%\mingw64\bin
/bin is only displays %G%\bin plus builtin commands only
That is:
vonc#vonc:/$ ls /usr/bin|wc -l
1160
vonc#vonc:/$ ls /bin|wc -l
149
That started with the support of MingW2 in 2015, and later the mingw-w64 project.
Yet, /bin is mounted to %G%\usr\bin.
Is there a config file to change this?
Yes: /etc/mtab
$ cat /etc/mtab
D:/prgs/git/latest / ntfs binary,noacl,auto 1 1
D:/prgs/git/latest/usr/bin /bin ntfs binary,noacl,auto 1 1
C:/Users/vonc/AppData/Local/Temp /tmp ntfs binary,noacl,posix=0,usertemp 1 1
So /bin is only mounted once: to .
Why is the same folder being mounted twice?
Since / is mounted to %G%, /usr/bin is also a reference (not a mount) to %G%\usr\bin.
Git 2.5.2.2 (Sept 2015) illustrates this with issue 405 and commit bf980fd. (see also PR 79).
I ran into this issue myself with Conda on Windows. I believe that the answer is given in the Cygwin mount table docs. By default, Cygwin will automatically mount {cygwin-prefix}\bin to /usr/bin. But this behavior can be overridden if there's an entry in your /etc/fstab that mounts something else to /usr/bin. This code on GitHub looks like the implementation of that logic.
Now the astute reader will note that this is backwards! In the original question, and my experience with Conda, {cygwin-prefix}\usr\bin is mounted to /bin. That's because MSYS2, which uses a fork of Cygwin for its runtime, switches the prefixing pattern.
Either way, if you can edit your /etc/fstab, you can avoid the issue. For my Mambaforge install in an IE Edge Windows 10 VM, the following line adds a mount that is redundant, but prevents the shadowing:
C:/Users/IEUser/mambaforge/Library/bin /bin whatever binary,posix=0,noacl,user 0 0
Adding /usr in the first two items would be appropriate for a stock Cygwin setup, I think.
PS: In Conda installs, at least, I should note that while this solution is technically correct I have found it not to work reliably, because package updates will overwrite your /etc/fstab file. Both the git and m2-filesystem packages provide (slightly different, sigh) versions of the file. I haven't tried it, but it's possible that a user-specific file in /etc/fstab.d, as mentioned by the Cygwin docs linked above, might provide a way to avoid this issue. But I just futz with my $PATH.
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
I installed Git Extensions which automatically downloaded and installed Git for Windows, and when I use Git Bash, it shows the file path as /c/whatever/folder rather than C:\whatever\folder, and if I paste in a path from Windows Explorer, it chokes on it because it's expecting forward-slashes and no colon after the drive letter.
When I installed Git for Windows by itself previously, it showed the slashes/colon properly, but was much more limiting and harder to use (especially with copy/paste).
Why is it showing/expecting file paths with slashes and no colon, and how do I fix it?!
http://imgur.com/vMc7fU6
You could also try adding single quotes in the directory path copied from Windows Explorer and pasted in the Terminal prompt (e.g. cd 'D:\Documents\Developer Tools & Docs'). It worked for me. Check out the solution posted in the following link:
Escaping backslash in windows paths passed to unix programs
It's getting tripped up because the \ is an escape character in the Unix/Linux world. If the path you paste is like c:\\somefolder\\anotherfolder, it would be ok, because \\ says "I want a literal \. That said, my git bash understands a single \ as long as the path does not end with it. So cd c:\folder works, but cd c:\folder\ does not work.
BTW what error message is it giving you when it chokes, and can you give an example of a pasted path it chokes on.
This is caused by the Git Bash (Ming) shell, not because of anything git itself is doing.
If you run the mount command inside this shell, you will find that /c/ is the folder where your hard drive is mounted. If you want Git Bash to use a different folder name for your hard disk, you can map your disk to a different folder.
By the way, you shouldn't have to care about this when using git. Repos typically don't (and typically shouldn't) contain files in the root directory of a volume. Even if they did, git references files relative to the repository root. Since any folder that is the root level of a volume will also be the root level of any repo it's in, it will be called / in git, regardless of how the underlying operating system or shell labels it.
For your convenience, here is the output of mount from inside Git Bash on my laptop. You should get similar results. You can see that it indicates that C:\ is mounted on the /c folder.
chris#caerdydd MINGW64 ~
$ mount
C:/Program Files/Git on / type ntfs (binary,noacl,auto)
C:/Program Files/Git/usr/bin on /bin type ntfs (binary,noacl,auto)
C:/Users/chris/AppData/Local/Temp on /tmp type ntfs (binary,noacl,posix=0,usertemp)
C: on /c type ntfs (binary,noacl,posix=0,user,noumount,auto)
I want create a hidden ini file under macosX environment with Firemonkey (XE3).
But unfortunaly this command is not known anymore in system.utilys
Somebody tips?
On a Mac, there are two ways to make file "hidden" or "invisible".
Like Linux or Unix, you can start the filename with a dot (.).
You can also use the setfile tool that ships with Xcode to set attributes to make it invisible ([setfile a -V filename][3]).
Depending on the way, you will have to replace the Win32 specific SetFileAttr call with a Mac specific rename, or find out which API setfile uses to set the attributes.
In UNIX (and in this layer Mac OS is largely spin-off from FreeBSD) there is no "hidden" flag on file, instead special files should have their name started with dot. http://en.wikipedia.org/wiki/Dot-file
So if you want to hide a file - rename it.
That is not the question about Delphi = that is the question of operating system, Windows vs UNIX.
Open console/terminal/whatever they call command prompt in Apple, go to ur home folder and issue two commands: ls and ls -a - compare the file lists in output.
Well, for starters you can do it in Linux - http://bellard.org/jslinux/ - wait few seconds for it to boot, then issue ls, ls -l, ls -a, ls -la and see the difference.
Dot-files are treated specially and hidden by default.