I recently installed unison on my home machine (OSX 10.9) and on my remote server (Ubuntu 12.04 64-bit).
I have version 2.40.102 installed in both place. I used 'brew install unison' on my Mac, and I compiled from source on the server.
The issue is that I can't get "-repeat watch" to work. It connects, but then does nothing.
Contacting server...
Connected [//... -> //...]
And that's it. If I pass anything, like, '1' to the -repeat flag it works just fine.
Is there something else that I need to do in order to get it to watch for changes and sync when something changes?
You should update unison to the latest version. According to the manual, prior to version 2.48.3 if the file-monitoring program failed it would silently ignore the issue. In the changelog for 2.48.3:
The file watcher now fails when unable to watch a directory, rather than silently ignoring the issue.
You should update unison to the latest version so at the very least you will get an error message if it is the file watcher that is failing. Version 2.48.3 also made quite a few improvements to the file watcher (unison-fsmonitor), so this should fix your problem.
Related
I've been using Cypress locally on my MacBook for some time and it's been going great. Lately my device has been having trouble, so I set up WSL on my PC so I could have a backup in case the worst were to happen.
We use yarn to handle dependencies, and I used NPM to install Cypress and Yarn.
Originally everything I was installing was going into a mounted virtual drive, where nothing was working. I eventually got it running off the linux directory, and Yarn and the dependencies installed fine. I also was able to install Cypress#9.5.4, which is the current version I'm using.
Every time I try to run Cypress headed or headless, I'm being met with the following:
No version of Cypress is installed in: /home/workterminal/.cache/Cypress/9.5.4/Cypress
Please reinstall Cypress by running: cypress install
----------
Cypress executable not found at: /home/workterminal/.cache/Cypress/9.5.4/Cypress/Cypress
----------
A couple coworkers took a stab at it, and this is as far as we could get before I decided to reach out for help here. We got me off the mounted virtual drive, we got NPM and Yarn installed properly after using the linux directory, and then reinstalled Cypress using yarn add cypress#9.5.4, which completed successfully.
We've tried expanding $PATH to include everywhere where Cypress exists, but it always looks in .cache. What can I do to toubleshoot further?
I'm trying to setup GoLand to use WSL 2 as in this guide: https://www.jetbrains.com/help/go/how-to-use-wsl-development-environment-in-product.html
I've installed Go in the Ubuntu distro following the linux instructions on the GoLang website, and go version prints outs the version I downloaded, so it appears that Go is working inside WSL.
So now I tried to create a new project in GoLand, and I'm getting errors, which appear to come from the fact that the SDK isn't loaded in GoLand. The guide doesn't offer much guidance on this, so I just tried to add a local SDK.
When I select /usr/local/go I get an error that it's not a valid SDK.
So I created the ~/go directory, and then updated my .zshrc file to export the GOPATH and GOROOT environment variables, even though they already showed up when I ran go env, doing this got them to show up on a simple env call.
But I'm still getting the invalid SDK error like above.
Is there a configuration step I'm missing that isn't spelled out in the guide? I came across this old post about creating symlinks to fake the expected directory structure. I haven't done this because it's a really old post, has comments that say this has been fixed, and seems like a really odd solution.
Support for Go SDK in WSL2 will be available in the next 2021.3 release, please see GO-10618.
October 2021 update.
2021.3 reaches Early Access Program at the moment. GoLand suggests selecting Go SDK on WSL2 mount if the location of the project is on WSL2 as well.
I experienced this on my Debian machine and I wasn't using WSL2. I found that the actual cause of the issue is that Goland is unable to read the directory /usr/local/go/bin due to inadequate permission.
A possible solution is to run the goland.sh script as root. The script can be found in the bin/goland.sh directory of the Goland IDE folder. Here is a simple command to do run Goland as the root
export HISTIGNORE='*sudo -S*' && echo "sudo-password-here" | sudo -S /absolute-path-to-goland.sh
export HISTIGNORE='*sudo -S*' tells bash history to ignore caching any command matching sudo -S* to bash history. This way, your sudo-password isn't saved into the bash-history file.
echo "sudo-password-here" | pipes your sudo password as input to the next command.
sudo -S tells bash to read input for password prompt from stdin, which has been provided through the echo command.
Alternatively, you can just install the latest version of Goland. Hopefully, it doesn't come with this bug
So I am having some issues with vagrant. I had initially tried to report this as an issue on the vagrant github issue boards, but they kept closing the issues without responding to them. I guess they decided I wasn't worth their time, or they were just behaving unprofessionally. Anyway, Here is the problem: I use vagrant with virtualbox, and a new version of virtualbox was recently released that is, unfortunately, not compatible with the latest vagrant installation.
However, the people at hashicorp have already updated the source code so that it is compatible with the new version of virtualbox, but you have to build the vagrant executable from the source repo (instructions here). So I followed the instructions and vagrant is working just like it used to.....when the only command I need to run is vagrant up. I should also mention ahead of time that, in order to run the vagrant dev build, the current working directory needs to be the root of the source code repo and the dev build can only be run using the following command with ruby:
bundle exec vagrant
With that being said, I needed to update one of my custom boxes, so I built a vm in the updated version of virtualbox and ran the below command
bundle exec vagrant package --base go --vagrantfile ../../vagrant/vagrantfile
After an extended period of time, vagrant spat back out the following error
The executable 'bsdtar' Vagrant is trying to run was not found in the %PATH% variable. This is an `error. Please verify this software is installed and on the path.`
I should also note that I use a windows machine and that this error never occurred when using the installed version of vagrant. At this point, I had posted the issue on github to get some input from the devs, but they (very unprofessionally) decided to ignore my requests for help and close the issues without providing any response. I used the GNUwin32 project to make numerous unix commands available to my Windows environment and added the folder to my PATH environment variable. I then run the same command again to create my new box and it works!! So then I upload it to the vagrant cloud and attempt to update the vagrant box that is stored on my system by running the following command:
bundle exec vagrant box update
Then, after waiting for a while, vagrant then spat this error out at me:
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and that enough disk space
is available and then try again.
The output from attempting to unpackage (if any):
C:\gnuwin32\bin/bsdtar.EXE: invalid option -- s
Usage:
List: bsdtar.EXE -tf <archive-filename>
Extract: bsdtar.EXE -xf <archive-filename>
Create: bsdtar.EXE -cf <archive-filename> [filenames...]
Help: bsdtar.EXE --help
Another error, and still involving this bsdtar tool. It does not appear that anyone else is reporting the issue I am running into because I think they are just waiting for hashicorp to release the new official installation, but, just to give you a look into their priorities, the version of virtualbox that was released which no longer worked with vagrant was released back on December 10. It has been over a month since and there is still no updated release.
So, I am hoping that someone out there might be able to find out why I keep running into these errors when trying to use vagrant's dev build and provide a solution. If not, then maybe if someone else is able to reproduce the issue and report it to hashicorp, maybe they will listen to someone else.
If you are on Ubuntu 20.04 then bsdtar was removed. Try to install libarchive-tools package.
$ sudo apt-get install libarchive-tools
I figured it out. My original hypothesis was correct: since vagrant is a tool that was built primarily to be run on linux machines, then vagrant runs in windows, the installation includes a mingw environment with all of the dependencies vagrant needs to function and which the installed vagrant executable imports into the console session when run. This why the dev build kept failing: because it was not importing this mingw environment. So, in order to fix the issue, I first cloned the vagrant source code repo from github and followed the instructions I linked to above to build the executable from the source repo. I then copied all of the files in the source repo into the following folder:
<hashicorp install folder root>\Vagrant\embedded\gems\2.2.6\gems\vagrant-<version num>
So, for me, the destination directory is C:\HashiCorp\Vagrant\embedded\gems\2.2.6\gems\vagrant-2.2.6
This directory is identical to the source code repo, and copying the source code repo to the above folder replaces the installation version of vagrant with the dev build. After I did this, running the vagrant commands which had failed previously normally (as in, without using ruby or bundle) worked. I hope this helps someone else out there who Hashicorp has decided is not worth their time.
I'm new to Selenium webdriver but the issue that I am running into does not seem like a common problem (looked everywhere for solutions for 4+ hours).
macOS High Sierra 10.13.2 - Selenium 3.13.0 [via pip3] -
ChromeDriver 2.40 [via web source] - Chrome 68 - Python 3.7
Here's what happened:
Initially chromedriver is in my Applications directory with .bashrc and .bash_profile including:
export PATH="$PATH:/usr/local/Cellar/python/3.7.0/bin:/Applications"
I was building a scraper in Python 3.7 everything is working fine executing from command line:
python3.7 scraper.py
I want to start running scraper.py from inside SublimeText3.
I copy chromedriver into /usr/local/Cellar/python/3.7.0/bin to be available for my python3 Sublime build system.
Doesn't work: something to do with it not being the original.
Accidentally deleted original.... So I remove all traces of chromedriver and redownload to Applications directory (original working conditions).
Now, I try to run again from command line and I'm getting Only local connections are allowed.
I try to execute chromedriver on the command line and I get bash: command not found. Even when I am in the Applications directory! Whereas before I could execute chromedriver from any directory.
Every solution online suggests that it's either a compatibility issue or a PATH issue but neither is the case.
Tried rebooting my system, reinstalling python, reinstalling Selenium, reinstalling chromedriver again, moving chromedriver/redirecting PATH, rebooting my system again, everything...
Any input would be greatly appreciated. I'm thinking it has more to do with the OS then anything else. But can't make heads or tails of this. Also wondering if using a virtualenv would be able to circumvent this issue?
UPDATE: To anyone experiencing a similar issue, I would recommend just using a virtualenv. This allows you to work in an isolated python environment without having to clutter up your system with global packages and potentially risking a bug in your system's configuration.
Trying to install Vagrant on Windows 7 X64 with installer from Vagrant - vagrant_1.7.0.msi
Installation goes fine, however unable to use vagrant. On any command, for example vagrant -v the below is shown:
Failed to find Vagrant!
What I did:
Googled. Only 1 link with such an error on github regarding to installer. Not sure if this is relevant.
Checked that vagrant in PATH. Yes it is. Otherwise it would not start at all.
Reinstalled, and repaired - few times.
All the above with no luck. Any idea where to dig?
Thank you.
just to add my own version of this problem too:
i installed version 1.7.0
error message after a "vagrant up": "Failed to find Vagrant!"
checked paths, other environment variables in win7, should work..
so i uninstalled it and installed an older version (1.6.5)
and yes, the older version solved the problem.
i got it from their official website: https://www.vagrantup.com/download-archive/v1.6.5.html
i guess the problem was in this file:
https://github.com/mitchellh/vagrant-installers/blob/master/substrate/launcher/main.go
Same Issue on Windows 7 64.
Downgraded back to Vagrant 1.6.5
Have you gone through the installation instructions on vagrant side listed here :
https://docs.vagrantup.com/v2/installation/index.html
This is what I see listed at their site:
The installer will automatically add vagrant to your system path so that it is available in terminals. If it is not found, please try logging out and logging back in to your system (this is particularly necessary sometimes for Windows).
Please try running it from Git Bash too and let me know if it works for you.
And if you still run into issues, try using an older version of vagrant https://www.vagrantup.com/download-archive/v1.6.5.html
Vagrant 1.7.1 should fix this. https://github.com/mitchellh/vagrant/issues/4924#issuecomment-66808666