I would like to build/launch the VSCode source code in the native Bash for Windows client. I have followed the steps outlined in the VSCode wiki on how to contribute, and everything is working as expected (All commands have been run on the WSL terminal following the Linux instructions)
After running yarn run watch, I try to launch VSCode by running DISPLAY=:0 ./scripts/code.sh from the source code directory, but nothing happens. I get two duplicate warnings:
[21496:1128/120229.392130:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
but I'm not sure if this is causing the problem. I have an X Server client running, and have used to to successfully launch native Windows applications through WSL (terminator, emacs, etc.)
Is what I'm trying to do possible? If so, how can I make it work?
Amazing that you asked this! I was attempting to do the exact same thing at (it seems) the exact same time. Here's my process.
Install XMing
Install the xfree apps
Set DISPLAY=:0
Run xeyes ==> Awesome googly eyes!
Attempt to build vscode from source. The build docs seem to be incomplete b/c I had to install a ton of libraries beyond those listed e.g.
yarn
gulp
gulp-cli
pkg-config
libx11-dev
libxkbfile-dev
libsecret-1-dev
libgtk2.0-dev
libxss-dev
gnome-dev
libgconf2-dev
libnss3-dev
libasound2-dev
Eventually get the yarn tasks to finish such that I could run code.sh
./scripts/code.sh
[20474:1128/153959.035267:ERROR:bus.cc(427)] Failed to connect to the bus: F
ailed to connect to socket /var/run/dbus/system_bus_socket: No such file or
directory
[20474:1128/153959.081986:WARNING:audio_manager.cc(295)] Multiple instances
of AudioManager detected
[20474:1128/153959.082101:WARNING:audio_manager.cc(254)] Multiple instances
of AudioManager detected
Looking at ps I see that the process was running.
Conjectures
It seems that building from source from WSL is not yet supported. Or maybe you can build the artifact, but you can't connect to the Windows display to show it. Based on the quality of the xeyes session, it looks like a very, very, very primitive experience e.g. still using WinXP-style minimize / maximize / close icons.
I was literally writing an Issue on their github page when I thought I'd do one last search and found this post. Much of vscode treats WSL as a second-class environment on Windows. Recent work seems to suggest that things are going to get better as driving to integration between Windows' two internal environments continues to improve (e.g. https://github.com/Microsoft/vscode/issues/39144)
Update 2017-11-30
Based on some pursuit via Github, it seems that this issue has been reported to the WSL team: https://github.com/Microsoft/WSL/issues/2293. It appears to be under active consideration by the WSL team. I've added some commentary about my use case there.
I have two gnome-shell extensions that don't appear to be loading after upgrading to 3.24. In gnome-tweak-tool they have a warning sign icon with "Error loading extension", and nothing else. I tried using looking glass (lg), and it just says "Error", and that the extension "has not reported any errors".
How can I debug the extension to find out why exactly it's not loading?
I found the error in the systemd journal:
$ sudo journalctl /usr/bin/gnome-shell
Just simply run this on terminal:
gnome-extensions-app
and enable it to make the extensions work.
Works perfectly with GNOME 40
As mentioned on the Github page.
A Shell reload is required. Press Alt+F2 r Enter and the extension has to be enabled with gnome-tweak-tool or with dconf.
As mentioned on Dash to Dock's User reviews. Make sure you disable Ubuntu Dock if you are using this in Ubuntu, otherwise you are going to have conflicts.
To disable Ubuntu Dock type the following in terminal:
gnome-extensions disable ubuntu-dock#ubuntu.com
I also experienced the same error. I think I will like to state the procedures that I took to make mine to work, and then you can check to see if you got it wrong somewhere.
Here are the steps
First install the Gnome shell extensions package from the terminal
sudo apt install gnome-shell-extensions
And then reboot your system. After that, start GNOME Tweaks and you’ll find a few extensions installed. You can just toggle the button to start using an installed extension.
Next, go to GNOME Extensions website (GNOME User Themes Extensions) and download the extension with the latest version (Although, I often prefer to download the version next to the latest version, since it may be more stable).
Extract the downloaded file to the ~/.local/share/gnome-shell/extensions (home/.local/share/gnome-shell/extensions) directory. You can press Ctrl + H to show hidden folders. Create the extensions folder if you don't have it yet.
Now restart GNOME Shell. Press Alt+F2 and enter r to restart GNOME Shell.
Restart GNOME Tweaks tool as well. You should see the manually installed GNOME extension in the Tweak tool now. You can configure or enable the newly installed extension here.
That's all
I hope this helps
Loging in without wayland works for me.
My extension was not enabling. I just log out and log in back and ran this command.
gnome-extensions enable example#hammad.example.com
It worked in my case.
I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
I have a CI setup with multiple slaves. I'd like to install different versions of the iOS simulator, but this needs to be done from the Downloads tab in the Xcode Preferences. Ideally there would be a command line tool that we could run to download and install specific versions. Does this exist?
If you don't care about having the system keep track of the package receipts, you can just install them on one of your systems and then rsync /Library/Developer/CoreSimulator/Profiles/Runtimes over to the other systems.
Note that after the transfer, I'd suggest doing 'sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService' on the other slaves since the service expects the profiles to be moved into place and might not respond well to the rsync.
I have put together a bash script that automates the installation and removal of various apks.
The script uses adb to install to sdcard then uninstall packagename to remove. If it has problems finding the package name (it's only happened if the AndroidManifest is broke) it reverts to using adb to get to the applications menu via shell input keyevent "direction" to the sdcard section then as there will only be one app here it selects it and removes it.
The problem is that the script now has to run on a nexus 5 running kitkat.. so the only way to view the app list is by way of 'downloaded apps', 'running apps' and 'all apps'. The install will now be to the handset not sdcard as nexus has no sdcard.
Can anyone recommend a way to find the last installed app to android 4.4 so I can use its name within a variable to remove it? I've been told to try pm list packages, but this is no good as I won't know what the app is called when away from the phone.
The handset is rooted if that helps..
thanks