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.
I've encountered a problem that I can't seem to find a solution for. Running the man command anywhere that isn't in ~ or without using sudo returns:
"/usr/bin/man: can't execute less: Invalid argument
/usr/bin/man: command exited with status 255: ..."
I've tried running export MANPAGER=less
$PAGER and $MANPAGER are set to less. It still does not seem to work.
What do I do?
Edit:
After further review I've noticed that the command works everywhere except a mounted network directory that I use. I can use less and echoman ls`` just fine, but just using man as usual brings up the mentioned issue.
Try to change the permission and ownership of /usr/bin/man. Make it so that it is executable by everyone.
I just downloaded and installed Kali Linux on my MacBook Pro (dual boot) to mess around with penetration testing - I have experience with aircrack-ng, but it was a while ago (and I was at least unaware of the distributions geared towards penetration testing). Finally got everything up and running, and customized the way I want - I tried to run the basic injection test aireplay-ng -9 wlan0 in the terminal and I get command not found when I try it as admin. The weird thing is it seems to work as root (I didn't try running the test - I just typed in aireplay-ng to see if it recognized the command, and it does). I don't think it is a PATH problem, but I added /usr/sbin/aireplay-ng to /root/.bashrc like this (just incase):
PATH=~/usr/sbin/aireplay-ng:$PATH
I don't think it is the path, because - as you can see, aireplay-ng is located in /usr/sbin/ which is already part of my PATH variable (noticeable when I execute echo $PATH).
The odd part is - when I log in as root, it seems to work - I didn't actually run the test as root (probably not the best idea), but I did type in aireplay-ng to see if the command was recognized, and it was. Not sure if a symlink would help - but I'm not going to try anything until I get a response.
Just trying to get the aireplay-ng command recognized. Thanks in advance. (I posted this on superuser too - but it seems like people are more active on stack).
Turns out I think you need root access for aireplay-ng (probably for the whole aircrack-ng suite too).
I'm on a fresh Virtualbox install of CentOS 6.4.
After installing zsh 5.0.2 from source using ./configure --prefix=/usr && make && make install and setting it as the shell with chsh -s /usr/bin/zsh, everything is good.
Then some time after, after installing python it seems, it starts acting strange.
Happens with PuTTY and iTerm2 over SSH, does not happen on the raw terminal through Virtualbox.
typing something, then erasing it: rather than removing the char and moving the cursor back, the cursor moves forward.
Typing Ctrl+V then Backspace repeatedly prints out this repeating pattern '^#?'
Running cat from zsh works fine. Prints out '^H' if I type that, backspaces like normal if I type normal backspace.
Surely someone's seen this before and knows exactly what the hell it is.
I'm not positive yet, but it seems that installing oh-my-zsh can fix this. But I really want to know what the specific issue is here.
OK , I suggest you try
export TERM=xterm
in your .zshrc configuration
the Changing into Zsh caused the bug.
sigh I knew I solved this before.
It's too damn easy to forget things.
The solution is to compile and apply the proper terminfo data with tic, as I have a custom config with my terminal clients, xterm-256color-italic, that confuses zsh.
There appear to be other ways to configure this stuff too; I basically just need it to be properly set up so italics work everywhere (including in tmux) so hopefully I can figure out how to do this more portably than I am currently.
I encounter the same problem when I manually install ZSH without root, when the backspace turns to blankspace but still functions as Backspace. Finally, I find it is because "ncurses" is not installed well.
tic: error while loading shared libraries: libncurses.so.6: cannot open shared object file: No such file or directory
? tic could not build /home/user/ceph-data/soft/ncurses-6.1/share/terminfo
After I reinstall the "ncurses", the problem of ZSH backspace is solved. Just for your information.
my $TERM is xterm-256color, by the way.
I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.
(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall
I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.
To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output
I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.
I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.
Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.
In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).
I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.
Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).
This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...
I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.
I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.
Just reinstall cygwin and select TCL and activate EXPECT