I try to use neovim with fzf plugins. Part of my init.lua is
-- Plugin imstallation section
local install_path = fn.stdpath('data')..'/site/pack/paqs/opt/paq-nvim'
if fn.empty(fn.glob(install_path)) > 0 then
cmd('!git clone --depth 1 https://github.com/savq/paq-nvim.git '..install_path)
end
-- Load the plugin manager
cmd 'packadd paq-nvim'
-- Set the short hand
local plug = require('paq-nvim').paq
-- Make paq manage it self
plug {'savq/paq-nvim', opt=true}
plug {'scrooloose/nerdtree', opt=true}
plug {'vim-airline/vim-airline', opt=true}
plug {'vijaymarupudi/nvim-fzf', opt=false}
plug {'ibhagwan/fzf-lua', opt=false}
require('paq-nvim').install()
require('paq-nvim').clean()
When I try to use command FzfLua files I observe message
fzf error 2 : unknown option: --headless
I work under Windows 10 and I use lua plugins : fzf-lua and nvim-fzf
fzf binary was installed and reachable
I cannot understand why rzr run with this strange option
What I did wrong?
Fzf-lua uses nvim-fzf actions for previews (and other functions) which calls lua functions by running neovim —headless … <lua function id>.
It seems that your neovim version does not support the headless option, I know of other users running fzf-lua on WSL, try with the official 0.5.1 appimage
Related
I'm trying to connect to my local docker engine running on OSX (m1 chip) in order to create a dynamic inventory.
I've created a host file with the following config
I made sure that docker_containers module is well installed.
plugin: community.docker.docker_containers
docker_host: "unix://Users/ME/.docker/run/docker-cli-api.sock"
Then I run ansible-inventory --graph -i ./hosts/hosts-docker-local.yaml.
But I'm getting the following error:
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with auto plugin: inventory source '/Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml' could not be
verified by inventory plugin 'community.docker.docker_containers'
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with yaml plugin: Plugin configuration YAML file, not YAML inventory
[WARNING]: * Failed to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml with ini plugin: Invalid host pattern 'plugin:' supplied, ending in ':' is not allowed, this character is reserved to
provide a port.
[WARNING]: Unable to parse /Users/ME/Projects/ansible-test/hosts/hosts-docker-local.yaml as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
#all:
|--#ungrouped:
I tried
ansible-doc -t inventory -l | grep docker
community.docker.docker_containers Ansible dynamic inv...
community.docker.docker_machine Docker Machine inve...
community.docker.docker_swarm Ansible dynamic inv...
but somehow if I do this
ansible localhost -i ./hosts/hosts-docker-local.yaml -m community.docker.docker_containers
It complains
localhost | FAILED! => {
"msg": "The module community.docker.docker_containers was not found in configured module paths"
}
maybe something wrong with my module path, something wierd with OSX? (I installed Ansible with brew)
The inventory file must end in docker.yaml, as pointed out by #Zeitounator.
Uses a YAML configuration file that ends with docker.[yml|yaml].
https://docs.ansible.com/ansible/latest/collections/community/docker/docker_containers_inventory.html#synopsis
I'm currently using Neovim 6.0. And I also use the following neovim-config : https://github.com/rafi/vim-config.
After installation, I created a python program to test and a problem encountered which are as follows:
treesitter/highlighter: Error executing lua: ...im/0.6.0/share/nvim/runtime/lua/vim/treesitter/query.lua:161: query: invalid node type at position 5622
~ pdb~ ⮡ Snippet [VSnip] st
I had a similar issue. I ran :TSUpdate in Neovim to update Treesitter plugin and the error message disapear after relaunching.
I just solved it using :TSInstall vim.
Actually, run :checkhealth and the error in there would help in figuring out what is missing.
Remember, in treesitter 'c', 'help', 'lua', and 'vim' are part of the core functionality of Neovim. But that means if you are seeing this error, a sure fire way to make sure they are all installed is to run:
:TSInstall c help lua vim
For me helped adding cmake to ensure_installed in the treesitter config section of .config/nvim/init.lua:
-- [[ Configure Treesitter ]]
-- See `:help nvim-treesitter`
require('nvim-treesitter.configs').setup {
-- Add languages to be installed here that you want installed for treesitter
ensure_installed = { 'c', 'cpp', 'go', 'lua', 'python', 'rust', 'typescript', 'help', 'cmake' },
Configuration was based on https://github.com/nvim-lua/kickstart.nvim
i installed docker follow this post
https://blog.ssdnodes.com/blog/getting-started-docker-vps/
sudo curl -sS https://get.docker.com/ | sh
this leak seem unsafe, i wanted to remove everything with docker and reinstall again in other method.
after remove all and check with
find / -name '*docker*'
the log
/proc/sys/net/ipv4/conf/docker0
/proc/sys/net/ipv4/neigh/docker0
/proc/sys/net/ipv6/conf/docker0
/proc/sys/net/ipv6/neigh/docker0
/proc/1/task/1/net/dev_snmp6/docker0
/proc/1/net/dev_snmp6/docker0
/proc/2/task/2/net/dev_snmp6/docker0
/proc/2/net/dev_snmp6/docker0
/proc/3/task/3/net/dev_snmp6/docker0
/proc/3/net/dev_snmp6/docker0
/proc/84/task/84/net/dev_snmp6/docker0
/proc/84/net/dev_snmp6/docker0
/proc/92/task/92/net/dev_snmp6/docker0
/proc/92/net/dev_snmp6/docker0
/proc/96/task/96/net/dev_snmp6/docker0
/proc/96/net/dev_snmp6/docker0
/proc/114/task/114/net/dev_snmp6/docker0
/proc/114/net/dev_snmp6/docker0
/proc/127/task/127/net/dev_snmp6/docker0
/proc/127/net/dev_snmp6/docker0
/proc/133/task/133/net/dev_snmp6/docker0
/proc/133/net/dev_snmp6/docker0
/proc/134/task/134/net/dev_snmp6/docker0
/proc/134/net/dev_snmp6/docker0
/proc/151/task/151/net/dev_snmp6/docker0
/proc/151/net/dev_snmp6/docker0
/proc/368/task/368/net/dev_snmp6/docker0
/proc/368/net/dev_snmp6/docker0
/proc/371/task/371/net/dev_snmp6/docker0
/proc/371/net/dev_snmp6/docker0
/proc/372/task/372/net/dev_snmp6/docker0
/proc/372/net/dev_snmp6/docker0
/proc/373/task/373/net/dev_snmp6/docker0
/proc/373/task/376/net/dev_snmp6/docker0
/proc/373/task/390/net/dev_snmp6/docker0
/proc/373/net/dev_snmp6/docker0
/proc/386/task/386/net/dev_snmp6/docker0
/proc/386/net/dev_snmp6/docker0
/proc/393/task/393/net/dev_snmp6/docker0
/proc/393/net/dev_snmp6/docker0
/proc/404/task/404/net/dev_snmp6/docker0
/proc/404/net/dev_snmp6/docker0
/proc/407/task/407/net/dev_snmp6/docker0
/proc/407/net/dev_snmp6/docker0
/proc/408/task/408/net/dev_snmp6/docker0
/proc/408/net/dev_snmp6/docker0
/proc/416/task/416/net/dev_snmp6/docker0
/proc/416/net/dev_snmp6/docker0
/proc/448/task/448/net/dev_snmp6/docker0
/proc/448/net/dev_snmp6/docker0
/proc/572/task/572/net/dev_snmp6/docker0
/proc/572/net/dev_snmp6/docker0
/proc/574/task/574/net/dev_snmp6/docker0
/proc/574/net/dev_snmp6/docker0
/proc/2523/task/2523/net/dev_snmp6/docker0
/proc/2523/net/dev_snmp6/docker0
/proc/2526/task/2526/net/dev_snmp6/docker0
/proc/2526/net/dev_snmp6/docker0
/proc/3110/task/3110/net/dev_snmp6/docker0
/proc/3110/net/dev_snmp6/docker0
/proc/3111/task/3111/net/dev_snmp6/docker0
/proc/3111/net/dev_snmp6/docker0
/proc/3114/task/3114/net/dev_snmp6/docker0
/proc/3114/net/dev_snmp6/docker0
/usr/bin/pm2-docker
/usr/libexec/docker
/usr/lib/node_modules/pm2/bin/pm2-docker
/usr/lib/node_modules/pm2/node_modules/systeminformation/lib/dockerSocket.js
/usr/lib/node_modules/pm2/node_modules/systeminformation/lib/docker.js
/usr/lib/node_modules/pm2/node_modules/#pm2/io/docker-compose.yml
/usr/lib/firewalld/services/docker-swarm.xml
/usr/lib/firewalld/services/docker-registry.xml
/sys/devices/virtual/net/docker0
/sys/class/net/docker0
/var/cache/yum/x86_64/7/docker-ce-stable
/var/lib/docker-engine
/var/lib/yum/repos/x86_64/7/docker-ce-stable
/etc/yum.repos.d/docker-ce.repo
/etc/systemd/system/docker.service.d
how do i remove docker completely ? is this file inside my host are safe ?
Quick summary of my comments so far, so you can accept it as an answer:
You downloaded the script from a trustworthy source (docker.com) and via HTTPS so there is extremely little risk of your system being compromised.
If your system was compromised, uninstalling docker would likely not solve the problem.
With those two caveats out of the way: The script you ran does a lot of magic to determine your operating system, and then delegates the actual installation to the appropriate package manager, meaning you can simply uninstall it through the usual package management tools of your Linux distribution.
I am trying to invoke commands in Rust (1.0 beta 3) on Windows 7 in an MSYS2 environment, but I cannot understand how to do it.
Suppose that you have this very simple script called myls in your home folder:
#!/bin/bash
ls
And now create a simple program in Rust that calls the script:
use std::process::Command;
use std::path::Path;
fn main()
{
let path_linux_style = Path::new("~/myls").to_str().unwrap();
let path_win_style = Path::new("C:\\msys64\\home\\yourname\\myls").to_str().unwrap();
let out_linux = Command::new(path_linux_style).output();
let out_win = Command::new(path_win_style).output();
match out_linux
{
Ok(_) => println!("Linux path is working!"),
Err(e) => println!("Linux path is not working: {}", e)
}
match out_win
{
Ok(_) => println!("Win path is working!"),
Err(e) => println!("Win path is not working: {}", e)
}
}
Now, if you try to execute it, you will get the following output:
Linux path is not working: The system cannot find the file specified.
(os error 2)
Win path is not working: %1 is not a valid Win32 application.
(os error 193)
So I am not able to invoke any command in MSYS environment.
How can I solve it?
EDIT:
I noticed that if I invoke an executable, the problem doesn't happen, so it seems to be related to invocation of bash script. Anyway, it's quite annoying since it makes compiling projects depending on external C/C++ code (that need to launch configure script) tricky to get to work.
The Windows example doesn't work because Windows isn't a Unix. On Unix-like systems, the #! at the beginning of a script is recognized, and it invokes the executable at the given path as the interpreter. Windows doesn't have this behavior; and even if it did, it wouldn't recognize the path name to the /bin/bash, as that path name is one that msys2 emulates, it is not a native path name.
Instead, you can explicitly execute the script you want using the msys2 shell, by doing something like the following (alter the path as appropriate, I have msys32 installed since it's a 32 bit VM)
let out_win = Command::new("C:\\msys32\\usr\\bin\\sh.exe")
.arg("-c")
.arg(path_win_style)
.output();
When i start yaws (yaws -i --conf config/yaws.conf) i get this line in the output:
Running with debug checks turned on (slower server)
It depends on the "-i" option? Or where did i turned on debug checks? No mention of debug in the config file...
thx
edoardo
In recent versions of yaws (1.85 and later) you can simply pass the --nodebug option on the command line:
yaws -i --nodebug
This will be because your flags setting in the global config has the debug bit (2) set. If GC_DEBUG is set in the global configuration this feature will be enabled.
These are the flags:
-define(GC_TTY_TRACE, 1).
-define(GC_DEBUG, 2).
-define(GC_AUTH_LOG, 4).
-define(GC_COPY_ERRLOG, 8).
-define(GC_BACKWARDS_COMPAT_PARSE, 16).
-define(GC_LOG_RESOLVE_HOSTNAME, 32).
-define(GC_FAIL_ON_BIND_ERR, 64).
-define(GC_PICK_FIRST_VIRTHOST_ON_NOMATCH, 128).
-define(GC_USE_FDSRV, 256).
-define(GC_USE_OLD_SSL, 512).
I think that in the yaws.config file this is actually un-set by setting the debug = false flag in the global part.
Updated - the debug parameter is part of the env settings of the app in the yaws.app file, so adding something like
-yaws debug false
to the real command line should work
After using command: "sudo yaws -i --nodebug", my website become a bit faster.