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
Related
I am using Git Bash to practice Unix commands.
What does the following line mean as soon as I open the console?
palex02#LAPTOP-TO2B6AA MINDF64
Also, when I try to use the ls Desktop command I don't see any files or directories. Also with mkdir (always on the Dsktop) I do not see the folder created (but if I go to the Desktop folder I see that it has been created).
This is the path I use:
~/Desktop
How can I solve this problem?
I've seen that happen when someone is using OneDrive, and they're backing up the desktop.
If that is the cause of your situation, C:\Users\<username>\Desktop exists but its contents were moved. The typical methods of accessing Windows Desktop are now using a different folder called "Desktop" in the OneDrive controlled folder.That would be C:\Users\<username>\OneDrive\Desktop or C:\Users\<username>\OneDrive - <your business name>\Desktop.
In such cases, it's common for the same kind of change to apply to "Documents" and "Pictures" folders, but they're each optional.
I'm currently practicing basic Shell Commands in WSL, Windows Subsystem for Linux (I do not have a linux system but I want to get familiar with commands).
I start a bash session on the command prompt window and navigate to my desktop using cd . In desktop I noticed that after using ls -lF some files with the prefix ~$ appear, such as: '~$executable.x'* or '~$file.txt'
These files are not currently present under the desktop directory, but I was able to remember that they were at one point (varying from a week to months ago).
When I do the same process in powershell windows (not using linux commands) I noticed that files displayed match the desktop and no extra files are listed.
I was wondering if anyone could explain what ~$ means in this context? my intuition is telling me they are backed up files that are somehow hidden in the desktop. After googling, all I could find is that ~ reefers to the home. I also understand that $ is the default prompt symbol for the bash shell when it is waiting for me to type something, but I'm still confused on why it would show up as a prefix for the name of a file.
Hope I made my question clear.
I'm currently reading "Linux® Command Line and Shell Scripting BIBLE" by Blum and Bresnahan but I could not find an answer there, this is my last resource after many googling attempts. Any other source for more information on the topic would be helpful.
On Windows, files that start with ~ are used for hidden files. More specifically,, the prefix ~$ are often used as backups for programs, should they crash before writing updates to a file (e.g. Microsoft Word, etc.)
From Wikipedia:
The tilde symbol is used to prefix hidden temporary files that are created when a document is opened in Windows. For example, when you open a Word document called “Document1.doc,” a file called “~$cument1.doc” is created in the same directory. This file contains information about which user has the file open, to prevent multiple users from attempting to change a document at the same time.
See: Why does Word make temporary files?
Relevant superuser question: https://superuser.com/questions/405257/what-type-of-file-is-file
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.
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.
So I just moved from Ubuntu to Windows (read forced to move, thanks to compatibility issues) and am using Git Bash to pull in my files. I've noticed something extremely strange.
Git Bash is installed in C:\Program Files (x86)\Git\, and when I first run the Git Bash program, the default location is this. Normal right? Right.
But here's the weird part..
When I run the command mkdir srv in the Git Bash command line, I can see it in the Bash window - but I can't see it in Windows Explorer?! What the heck. Same thing happens with files created using vi in the CLI. Invisible in Windows Explorer. (Yes, I have enabled the Show hidden files option in Explorer, so it's not that).
Here are some snapshots (no, I'm not blind - nor am I insane). Help?
You might not be able to see the folder because of missing privileges. Try running your explorer as Administrator and look again.
The proposed solutions above didn't help me. However, I copied the hidden directories to another place via git bash. Then I copied them once again via windows explorer to the original place. Now they've become visible. I created those invisible folders via git bash with git clone command before.
I had similar issue, but with file attributes, not with missing privileges.
In cmd under C:\Program Files (x86)\Git\ run command attrib
attrib *
You will know if srv folder has System or Hidden file attribute.
If you would like to view it in cmd then use dir /a:s