I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
Related
When I start neovide from my applications and run :checkhealth I get errors that node and other commands are not available. But when I start it from my terminal there is no error for those commands. I tried to copy and modify the neovide desktop file to start just nvim and see if there if something wrong with my my neovide installation. But also starting just nvim as application prints the same errors.
I'm using linux with plasma desktop
TL:DR; add a path variable
Depending on your configuration, nvim will need to know the environment to run some executables (like it is with node in your example). An easy solution is to add the path variable to the exec command in the according .desktop file. I remember that I had the same issue with node not being recognized in a configuration using my plasma installation. On gnome node was recognized and healthchecks were good, so I thought I didn't need the extra path. Later on I realized that I had trouble with other commands. E.g. when using fdfind to complete path commands. Again I had to search what the reason was and it also was the missing path.
To give an example, let's say you are using zsh and want to start neovide with multigrid enabled, the Exec line in your desktop file could look like:
Exec=zsh -c "source ~/.config/zsh/.zshrc && neovide --multigrid %F"
I haven't been able to find a similar question, but I can't imagine this is an issue that comes up too much.
At my workplace I've decided to switch over to a full Linux experience by using Cygwin, over what I was previously using, Git Bash.
The only slight drawback is that we have a script written in Ruby that deploys changes to our site. I can run this from my Git Bash terminal no problem, but not Cygwin as there doesn't seem to be a Ruby installation on here. I've learned about sending standard output to other terminal windows, but I've only been successful when both terminals have been the same shell.
What I'd like to do is the following:
1. Type a command into Cygwin that opens a Git Bash terminal and automatically runs ./deploy.sh on that Git Bash terminal upon opening.
2. If possible, also pass in an argument in the same command, that the script expects upon running. (In this case it's whether we want to deploy to our staging or production server).
Is this possible? So far I can get what looks to be a Git Bash terminal to open and prompt me for the server, but when I enter it, it does not work. I get an error with regards to a command within the script not being found. Thing is, running this same ./deploy.sh script in a Git Bash terminal that I open myself works perfectly as it always has. The Git Bash terminal that is being opened by Cygwin does not appear to have all of the capabilities of a Git Bash terminal I open 'the normal way'.
The command I am running so far from Cygwin is as follows:
/cygdrive/c/'Program Files'/Git/git-bash.exe "./deploy.sh"
I understand there is probably a way of getting this to work by installing Ruby via Cygwin but I'd like to mess around with my work environment as little as possible in case I somehow affect my ability to deploy my work... and besides, Git Bash definitely runs this script without an issue so I can't see why I would need a duplicate installation.
Many thanks!
cygwin64 had been running great on my Windows 7 system for several months. After rebooting this morning, it appeared to be inexplicably broken. When I started a new mintty session, rather than presenting a window with my familiar bash prompt, I got a blank window entitled -sh.exe. Sure enough, despite the lack of any sort of prompt, it was a shell window. ls, pwd, cd, and other commands worked, but my environment was a mess. Aside from the lack of a prompt, my home directory, path, and other things were messed up.
I tried the normal things. I reran cygwin setup to no avail. I completely uninstalled and reinstalled cygwin, again with no discernible effect. I rebooted a number of times during all these tries. What could cause cygwin to suddenly begin behaving so badly?
I had similar issues after installing IBM InfoSphere DataStage, which causes Cygwin to misbehave because it is setting several Windows environment that are inherited by Cygwin, and are crucial to Mintty and the shell. These variables are: SHELL, TERM, TERMCAP, and TERMINFO.
I modified my Mintty shortcut to contain the following target, and this fixed the issues:
C:\cygwin\bin\mintty.exe /bin/env -u SHELL -u TERMCAP -u TERMINFO - TERM=xterm-256color HOME=/home/username /bin/bash -i -l
The -u options are unsetting those variables, and then I'm explicitly setting TERM and HOME (make sure to use your home directory instead of /home/username).
I also had to copy my ~/.minttyrc file to /etc/minttyrc so that mintty would see it.
After digging around, I noticed that the sh.exe that was running was not in /cygwin64/bin, but was instead in \Program Files (x86)\MKS Toolkit. I did not recall installing MKS, but the date on this directory was from the previous day. The only thing I'd recently installed was the IBM InfoSphere DataStage client. It turns out, InfoSphere not only installs the MKS Toolkit, it prepends it to a number of environment variables, totally hosing cygwin.
I need to change somehow size of files (increase or decrease) on Windows machine using bash scripts. (Content of files doesnt matter) But i have to run this scripts from remote linux machine. I've selected truncate command for size changing, this is exactly that i need, cause i need to change size exactly of chosen file, without changing it's descriptor. It is very important.
But i DO NOT have truncate on my linux machine and i CANNOT install it there (So dont tell me to install it there plz :)). I cannot install nothing on my linux machine it has specific kernel - this is a main option of all my problems.
So i've decided to install cygwin on my Windows machine, cause it has truncate command. Also i know that there are fallocate command, but my linux machine also doesnt have it, and cygwin doesnt have it too. So if there is some another command i wanna know it :)
Then after this steps i tried to change file size from cygwin terminal via truncate and all works perfectly. And the last problem that i had to solve was just run cygwin's bash from my remote linux, i've chosen winexe for that.
Finally the way that i've chosen is:
I run winexe command on my linux machine that runs:
winexe myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
on my Win machine.
But it doesnt work and i dunno why. truncate command doesnt change size of files at all. When i type
truncate --help
all works, i can see result of help option on my linux terminal, but e.g.
truncate -s someSize myFile
doesnt work, size of file doesnt change. Also error code from truncate -s someSize myFile is 0
Any suggestions?
try giving the name of your script that is "myScriptWithTRUNCATE" directly in winexe command .
example:-
winexe myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
also check debug log of winexe by modifying winexe command as :-
winexe -d 5 myHost "c:\cygwin\bin\bash.exe myScriptWithTRUNCATE"
see in this log what actually is sent over to windows as command in place for your script.
specifically see in " CTRL: sending command : run xxxxx"
see what "xxxxx" is in that debug log.
winexe gives you the control of windows command line(cmd.exe).
Try running you script after it has got control of cmd.exe.
Based on some findings above , try this link for more help
http://blog.dotsmart.net/2011/01/27/executing-cygwin-bash-scripts-on-windows/
I have a Perl program that someone else created and I am calling on with CruiseControl. The program calls on Unix Commands using Cygwin. However, everytime that the Perl program calls on a Unix like command with a DOS like address, I get the well known error:
cygwin warning:
MS-DOS style path detected: E:\regression
Preferred POSIX equivalent is: /cygdrive/e/regression
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I have set both the User Variable AND System Variable CYGWIN to nodosfilewarning. This removes the error when I run the program from the command line, but the error still occurs in CruiseControl when called as an automated process from a batch file. I have called on both the batch file from the Desktop AND Command Line and ran as an administrator. Nothing changes.
Other Notes
For purposes of this problem, I don't have access to the Perl Program
I am trying to go back to Cygwin 1.5.*, but since I am using Server 2008, I am encountering compatibility issues
This is occurring on one of the distributed servers, not the main server running the Webdashboard.
I have read somewhere that this issue may stem from a different user calling on CruiseControl, but the issue should have been solved by setting this as an ENV System variable
Is it possible to modify the registery to set the ENV variables?
Thank you in advance
The way I do it is like this
printf 'export CYGWIN=nodosfilewarning' >> ~/.bash_profile
If CruiseControl is connecting to the server via ssh, reinstall sshd and explicitly include nodosfilewarning when prompted for the CYGWIN environment variable during the install.
Re-installing with modified environment will work but if you don't want to or cannot re-install, an alternative is to change the registry instead of re-installing the service.
See: CYGWIN windows cygrunsrv sshd server and MS-DOS style path detected