I'm trying to use nvim (or vim) to edit a file on a remote machine from my Ubuntu 20.04 host like this:
$ nvim scp://developer#devvm//home/developer/junk
From what I understand remote editing is handled by the netrw plugin.
I installed nvim my Ubuntu machine via snap because the apt-get version is very old.
When I start nvim, the netrw plugin is not loaded. The only reference to it that I found was in /snap/nvim/2789/usr/share/nvim/runtime/ and its subdirectories so I added that directory to the 'set runtimepath' command in my ~/.config/nvim/init.vim file. After that, ':help netrw' works but when I try the remote edit it just says:
:!scp -q 'developer#devvm:/home/developer/junk' '/tmp/nvim.developer/gqbnmh/1'
shell returned 1
and I don't see the file contents.
I also tried to put the set runtimepath in my ~/.vimrc instead and run /usr/bin/vi but then I get all kinds of "command is not available in this version" errors.
$ which nvim
/snap/bin/nvim
$ nvim -version | head -1
NVIM v0.8.2
$ which vi
/usr/bin/vi
$ vi --version | head -1
VIM - Vi IMproved 8.1 (2018 May 18, compiled Jan 11 2023 23:54:11)
Any help is appreciated.
Related
I need to configure File share for DockerDesktop installed into my Windows10 machine. With earlier dockerDesktop versions I just added C: into Settings - Resources - File sharing and the changes into any code file below driver C: were immeditely seen in the application running in the corresponding container.
But after update to version 20.10.14
$ docker --version
Docker version 20.10.14, build a224086
such setting is no more available in DockerDesktop. So, how can I set the fileshare now ?
As far as I undestand the mode is wsl 2 backend:
$ wsl.exe -l -v
NAME STATE VERSION
* Ubuntu-18.04 Stopped 1
docker-desktop-data Running 2
docker-desktop Running 2
I'm trying to get unison working after upgrading to Mac OS X Catalina. Unfortunately, macports installs a more recent version of ocaml (4.08.1), which means that the unison 2.51.2 release won't compile.
Well, that's no problem, I just update to git master on unison, and recompile. Unfortunately, this fails at sync time because the version of ocaml used to compile on the mac (4.08.1) is different from the one used to compile on the other machine (4.07.1). Sigh. Okay, use opam magic to install 4.07.1 on my machine. Everything should be fine, right? No!
Here's the error:
Connected [//zzzmyhost//home/clements/unison-home -> //zzzmyotherhost//Users/clements/clements]
Looking for changes
Uncaught exception Failure("input_value: ill-formed message")
Raised at file "/private/tmp/unison/src/lwt/lwt.ml", line 126, characters 16-23
Called from file "/private/tmp/unison/src/lwt/generic/lwt_unix_impl.ml", line 102, characters 8-23
Called from file "/private/tmp/unison/src/update.ml" (inlined), line 2105, characters 2-69
Called from file "/private/tmp/unison/src/uitext.ml", line 978, characters 16-56
Called from file "/private/tmp/unison/src/uitext.ml", line 1066, characters 6-90
Called from file "/private/tmp/unison/src/uitext.ml", line 1088, characters 19-66
Called from file "/private/tmp/unison/src/uitext.ml", line 1144, characters 21-43
What's going on?
Sigh... the problem here (very non-obvious) is actually with a corrupted/wrong-format syncronization file, created when doing the failed sync in the earlier test.
The solution is just to go into ~/Library/Application Support/Unison (on a UNIX machine this path would presumably live in ~/.unison and delete the archive file that's causing the problem (probably the most recent one). In a pinch, just delete all of the archive files and start over.
I've got the same problem between Windows and Ubuntu 20.04 after upgrading from Ubuntu 18.04. I tried the binary from Ubuntu 18.04 in 20.04, which still fails, so the incompatibility is likely inside one of the dependencies.
As a workaround I created a Docker image based on Ubuntu 18.04:
FROM ubuntu:18.04
RUN apt-get update && apt-get dist-upgrade -y
RUN apt-get install unison -y
RUN useradd martin --home /home/martin
WORKDIR /home/martin
USER martin
Building it with docker build -t unison:18.04 .
And then I added a wrapper to ~/bin/unison-2.48.4-docker:
#!/bin/bash
docker run --rm -i \
-v /home/martin/dirtosync:/home/martin/dirtosync \
-v /home/martin/.unison:/home/martin/.unison \
--hostname $(hostname) \
unison:18.04 unison "$#"
Setting the --hostname is important, since the hostname is part of the archive file.
Inside the profile on my Windows machine I configured:
servercmd = ~/bin/unison-2.48.4-docker
In my setup with two windows clients and one Ubuntu 18.04 server, connected by ssh, the problem startet with a second server running on Ubuntu 20.04. Neither the old server nor the windows clients could sync with the new machine.
My solution: Copying the binary from Ubuntu 18.04 to a new directory in the Ubuntu 20.04 machine. This new file is referenced in the "authorized_keys" file of ssh on the new machine.
So far, everything works great with unison 2.48.4.
Is there a way to use the VSCode Remote SSH extension to interact with a remote host that does not allow outbound internet connections?
Is it possible to download the vscode-server files from another system and copy to host?
I read this but I can't connect the server to internet.
When you connect to a host it executes a bash script that wgets or curls a tarball and extracts it in a directory in your home directory. Here's an offline workaround.
Attempt to connect, let it fail
On server, get the commit id
$ ls ~/.vscode-server/bin
553cfb2c2205db5f15f3ee8395bbd5cf066d357d
Download tarball replacing $COMMIT_ID with the the commit number from the previous step
For Stable Version
https://update.code.visualstudio.com/commit:$COMMIT_ID/server-linux-x64/stable
For Insider Version
https://update.code.visualstudio.com/commit:$COMMIT_ID/server-linux-x64/insider
Move tarball to ~/.vscode-server/bin/$COMMIT_ID/vscode-server-linux-x64.tar.gz
Extract tarball in this directory
$ cd ~/.vscode-server/bin/$COMMIT_ID
$ tar -xvzf vscode-server-linux-x64.tar.gz --strip-components 1
Connect again
You'll still need to install any extensions manually. There's a download button next to all the extensions in the marketplace. Once you have the .vsix file you can install them through the GUI with the Install from VSIX option in the extensions manager.
This is kind of a pain and hopefully they improve this process, but if you have a network-based home directory, you only have to do this once.
open vscode -> about
Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:17:14.222Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 17.7.0
$COMMIT_ID = cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
A new feature is being added to support offline install
However, you can now solve this issue by a new user setting in the Remote - SSH extension. If you enable the setting remote.SSH.allowLocalServerDownload, the extension will install the VS Code Server on the client first and then copy it over to the server via SCP.
Note: This is currently an experimental feature but will be turned on by default in the next release
https://code.visualstudio.com/blogs/2019/10/03/remote-ssh-tips-and-tricks
A a work around I have done the following:
Desktop ~/.ssh/config
...
Host *
RemoteForward 54321
...
Remote: ~/bin/wget in which ~/bin is added to PATH via .bashrc
#!/bin/bash
export LD_LIBRARY_PATH=$HOME/opt/lib/tsocks/
export TSOCKS_CONF_FILE=$HOME/opt/tsocks/tsocks.conf
$HOME/bin/tsocks /usr/bin/wget $#
Remote: ~/opt/tsocks/tsocks.conf
server = 127.0.0.1
server_port = 54321
server_type = 5
note tsocks binary has been scp-ed to ~/bin/tsocks and ~/opt/tsocks/ has been created with libtsocks.so which is normally stored in /usr/lib64/libtsocks.so
This is a work around that allows me to have wget functionality with out messing with anything outside my profile to get it to work (eg: no root required ... even though I have it).
Current Version of VS Code: 1.48.2
I just kill the wget process on the server end, and let the client download the archive and transfer it to the server end. That's quite easy as below.
make sure that you set in settings.json
"remote.SSH.allowLocalServerDownload": true,
execute the shell scrpits below.
# to find the <pid>
ps aux | grep wget | grep vscode-server
# kill the process
kill -9 <pid>
# then wait for the client downloading and transferring
# optional: If you want to know the progress, just
cd ~/.vscode-server/bin/<commit-id>/
watch -n 1 -d ls -rthl
How do I use btgatt-client command line tool? Am I missing something very simple here?
As of Bluez 5.50, it is under in the tools folder (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/btgatt-client.c)
But when I try inputting the command, nothing seems to work.
pi#raspberrypi:~ $ btgatt-client
-bash: btgatt-client: command not found
pi#raspberrypi:~ $ sudo btgatt-client
sudo: btgatt-client: command not found
pi#raspberrypi:~ $ btgatt
-bash: btgatt: command not found
pi#raspberrypi:~ $ sudo btgatt
sudo: btgatt: command not found
Bluez sources needs to be compiled with tools support (by default it is enabled), but may be disabled in your raspberry PI build.
You can configure the source using
./configure --enable-tools
If want to cross compile, you may also need to use, "--host"
Or you can directly install the package "bluz-utils" from the package manager repository. For debian,
sudo apt-get install bluez-utils
I'm trying to get gnome-terminal to work in codelite under
setting > preferences > terminal
I tried
gnome-terminal -x '$(CMD)'
but it gives me the following error
Failed to execute child process "/bin/sh -f /usr/lib/codelite/codelite_exec ./program" (No such file or directory)
I'm running Linux Mint 18.
Solution is to run
sudo update-alternatives --config x-terminal-emulator
from a terminal and select
/usr/bin/gnome-terminal.wrapper
as default terminal.
CodeLite uses x-terminal-emulator. So as long as you define x-terminal-emulator to point to the correct terminal it will work.
See this post for more information
I just came across this problem after upgrading to CodeLite 10.0 from the CodeLite repository. The problem occurs because CodeLite is now installing things in different directories - namely codelite_xterm and codelite_exec, which are now installed to /usr/bin/.
For me, on Ubuntu 16.10, I found the easiest solution was to change Settings > Preferences > Terminal to:
/usr/bin/codelite_xterm '$(TITLE)' '$(CMD)'
You can then run:
sudo update-alternatives --config x-terminal-emulator
to select the terminal you wish to use (the default on Ubuntu 16.10 is gnome-terminal, so you won't have to run the last command if you're happy with gnome-terminal).