I recently installed WSL version 2 according to the instruction. Everything work greatly. But I notice that the folder /mnt/c is not available any more.
I understand the new WSL using vhdx as file system which gives us better FS performance, but I could not find a way to access files in Windows.
I also tried to check the wsl --help but I could not find anything helpful.
Any suggestions?
After read more, I notice that WSL 2 is actually an optimized VM on Windows 10, which means the running WSL 2 has no idea about where it self. Seems there should be a way to pass some Windows folders while launch it. Haven't figured out how.....
By default, the command prompt in WSL is located at C:\Users\username. WSL considers this /home/user but you can can reference any directory on your Windows machine by starting at the root directory with /../../.
Here is an example command: find "/../../mnt/c/anyFolder/subfolder" -name "test" -type d
Related
I'm using Windows Subsystem for Linux (WSL2), and OneDrive mounted using rclone, on a Windows 10 machine.
When using WSL2 in the local directories, I can create a virtual environment for a project:
python -m venv myenv/
However, if I'm in a directory on OneDrive, and I run this command, I get an error:
Error: [Errno 5] Input/output error: 'lib' -> '/home/andrew/onedrive/myproject/venv/lib64'
If I look in the myproject directory, I can see that directory venv has been created. However it is incomplete, in that it only has 'lib' and 'include' subdirectories. When it is created properly (that is, in a directory not on OneDrive), it has 'lib, 'include', 'bin', 'lib64', 'share', and 'pyvenv.cfg'.
'lib64' is a symbolic link pointing to 'lib' in the normal installation. In the error message above, it seems that lib is actually pointing to lib64, so I suppose this is the input/output error?
Is there a way to get venv to work on OneDrive directories when mounted via rclone and using WSL2?
My hunch is that something in the way Rclone works is causing your issue. It purports to be "inspired by rsync", which means that it isn't really "mounting", but is "syncing" the cloud storage.
I did a quick install of rclone in a new WSL instance, and I'm seeing the same "Input/Output error" that you experienced.
I'm guessing that you would see the same problem even if under a "full" Linux installation. In other words, I doubt this has anything to do with the interaction between WSl and rclone. It's probably more about the interaction between Python's venv module and rclone. I don't know for sure, but I have my doubts that rclone is designed for "live" usage. It's more for being able to access (and write) files on cloud-storage providers from Linux.
The good news is that there's likely an alternative. Windows automatically makes your OneDrive folder available in %userprofile%\OneDrive. From WSL, you can access this with:
cd $(powershell.exe -c 'Write-Host -NoNewLine $env:userprofile' | xargs -0 wslpath)/OneDrive
That's usually /mnt/c/Users/<yourusername>/OneDrive.
From there, python3 -m venv myvenv/ worked correctly for me.
That said, I highly recommend against doing this in WSL2, as performance of NTFS files is abysmal. Best to use a WSL1 instance if you really need to do it.
I have set up a local Perl web environment on my Windows machine. The application I'm working on is originally from a Linux server, and so the shebang for source .pl files look like so:
#!/usr/bin/perl
This causes the following error on my Windows dev machine:
(OS 2)The system cannot find the file specified.
Is it possible to change my Apache 2 conf so that the shebang is ignored on my Windows machine? Of course I could set the shebang to #!c:\perl\bin\perl.exe, that much is obvious; but the problem comes to deploying the updated files. Clearly it would be very inconvenient to change this back on each deploy. I am using ActivePerl on Windows 7.
Update:
I should have mentioned that I need to keep the shebang so that the scripts will work on our shared hosting Linux production server. If I did not have this constraint and I didn't have to use the shebang, the obvious answer would be to just not use it.
I use #!/usr/bin/perl in my scripts and configure Apache on Windows to ignore the shebang line. Add
ScriptInterpreterSource Registry-Strict
to your httpd.conf and set up the Windows Registry key as explained in the Apache docs.
Here is what I get when I export the key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="c:\\opt\\perl\\bin\\perl.exe"
I have been using this setup with Apache and ActiveState Perl on my Windows laptop and the Apache and Perl distributions that come with ArchLinux on my server.
The Apache docs (to which I linked above) state:
The option Registry-Strict which is new in Apache 2.0 does the same thing as Registry but uses only the subkey Shell\ExecCGI\Command. The ExecCGI key is not a common one. It must be configured manually in the windows registry and hence prevents accidental program calls on your system. (emphasis mine)
There is no portable shebang line. Even on the same platform and architecture, someone might have installed perl is a different location.
The trick is to not install modules and scripts by hand. When you package everything as distributions and use the module toolchain, the shebang lines are modified automatically to point to the perl you used to install everything. You shouldn't have to think about these details. :)
I use #! /usr/bin/env perl as the shebang on all of my perl, whether on *nix or Windows. Windows just ignores it, and the Unixen follow env to the chosen perl disto.
The way I had this working was to copy perl.exe to c:/usr/bin/ and rename it to perl (strip the .exe)
In win7 and up you can also do this with the "dos" command mklink.
Start a cmd shell as administrator and do something like the following:
mklink /d c:\usr c:\Perl # Activestate perl in c:\Perl\bin\perl.exe
mklink /d c:\usr c:\xampp\perl # Xampp perl in c:\xampp\perl\bin\perl.exe
Install any Windows Bash flavor (such as Cygwin, MSYS2 or GnuWin32);
Create a trivial redirecting shell script:
exec "#"
Create a registry entry:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
[HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command]
#="<path-to-sh> <path-to-script>"
(...and so on.)
Jot in your httpd.conf file:
ScriptInterpreterSource Registry
Apache will now resolve Unix shebangs relative to the interpretation given by your choosen Bash flavor. This gives much more flexibility than hardcoding interpreter paths in the registry.
I don't have Windows handy, but perlcritic says:
my $desc = q{Found platform-specific perl shebang line};
my $expl = q{Perl source in parrot should use the platform-independent shebang line: #! perl};
So, I guess #! perl should work.
Edit: doesn't work on linux; apparently works in parrot, although I don't see how they manage that.
How to use Linux shebang (#!/usr/bin/perl) when running Perl based web-site with {site-name} on localhost in Windows 10?
This works for me:
XAMPP on localhost\{site-name} (C:\xampp\htdocs\{site-name})
independently installed Strawberry Perl (C:\Perl\perl\bin) because Perl included in XAMPP package is not satisfactory
In default configuration you must use this shebang:
#!C:\perl\perl\bin\perl.exe -IC:\xampp\htdocs\{site-name}
Is it possible to include directory (after -I switch) permanently to #INC?
Yes, you can do it by setting the PERLLIB or PERL5LIB environment variables. This works when running perl script from command line, but surprisingly it is ignored by apache server in XAMPP. However one of #INC directories (C:/Perl/perl/site/lib) is usually empty so you can make symbolic link to your web-site directory:
mklink /D c:\perl\perl\site\lib C:\xampp\htdocs\{site-name}
Now, you can use this shebang:
#!C:\perl\perl\bin\perl.exe
Moreover, you can create directory c:\usr\bin
md c:\usr\bin
and copy perl.exe from C:\perl\perl\bin\
copy C:\perl\perl\bin\perl.exe c:\usr\bin\perl.exe
(Another mklink trick is not working here from some reasons.)
Finally, you can use Unix-styled shebang on Windows:
#!/usr/bin/perl
I'm trying to change the permissions of some files on windows to 'rw' only for owner user. As you can see it says that the files are changed to 'rw-------'. When I list the files again nothing is changed.
chmod is just emulated in Windows for Cygwin and MSys.
The best way to solve the issue is to use icacls to change permissions.
The command line could be found in official doc from Microsoft, like here
Note that the chmod status in Msys or Cygwin might not be correct. For example, this is what I get in Msys after removing all accesss to "toto.txt"
I'm trying to run an application using vagrant. I have a directory where the codebase of app is placed and the .vagrant dir that is created there after its initializing. It looks so:
[app_codebase_root]/.vagrant/machines/default/virtualbox
There is a some very short manual about what to do (https://github.com/numenta/nupic/wiki/Running-Nupic-in-a-Virtual-Machine) and I stopped at the point 9 where is said:
9) Expose [app] codebase to the vagrant instance... If you have the
codebase checkout out, you can copy or move it into the current
directory...
So it's not clear for me what to copy and where? Does it mean some place within vagrant (if yes, then which exactly?) or some another place? Or I should just make a command vagrant ssh now?
From the Vagrant documentation:
By default, Vagrant will share your project directory (the directory with the Vagrantfile) to /vagrant.
So you should find your codebase root should under /vagrant on your guest.
This is always going to be a little confusing, so you need to separate the concepts of the host system and the VM.
Let's say the shared directory (the one with the Vagrantfile) is [something]/vagrant on your host system. Copy your app directory to [something]/vagrant/nupic (or run git clone in that directory) while still in Windows. Check using Windows Explorer that you see all the source files.
In a console window, cd to [something]/vagrant and run vagrant ssh.
You are now in the VM, so everything is now the VM's filesystem. Your code is now in /vagrant/nupic. Edit .bashrc as per the instructions to point to this directory, and run the build commands.
what's the procedure I should follow to run a simple test on a domain www.example.com? I'm on Windows environment and have installed WAMP server 2.1.
I actually know which command I should use (Ex. ab -n 1 http://www.example.com/) but don't know where I should type it.
I don't know the path WampServer is installed to, so I'll just show you how I do it under WampDeveloper (which is what I use).
Run cmd.exe.
Inside...
C:
cd \WampDeveloper\Components\Apache\bin
ab -n 1 http://www.example.com/
To answer your question, you type it in the command line changed to the bin folder of your Apache folder since this is where ab.exe exists. If this folder location is in the system path, you can also just type it in anywhere (without changing paths in cmd.exe).
This 1st line changes the drive letter. Then second the path (aka working directory). The third runs ab.exe.
I do agree, PATH ENVIRONMENT setup manually
C:/YOUR_INSTALLATION_APACHE2/bin
Path to environment on control panel system settings.