I am having an issue with tab-completion that I am unable to solve. Specifically, whenever I try to tab-complete a directory, the completed directory name appears with a space following it instead of a forward slash to complete the rest. for example
~$ python ~/sof
tab-completes to
~$ python ~/software<space>
Instead of
~$ python ~/software/
Interestingly this does not happen with cd but with everything else it does.
Apparently it is a known bug. Deleting /etc/bash_completion.d/acroread.sh solved the issue.
Related
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 have started learning groovy and I just came across the SDKMAN utility.
To give it a try I folllowed the installation guidelines at the official site of sdkman and tried to run the below command to install sdkman on Windows 10 :
set SDKMAN_DIR="E:/sdkman" && curl -s "https://get.sdkman.io" | bash
But I donot see any sdkman folder present in my E drive.
When I try to re-run the command it says :
Looking for a previous installation of SDKMAN...
SDKMAN found.
======================================================================================================
You already have SDKMAN installed.
SDKMAN was found at:
"E:/sdkman"
I am just confused as to why am I not able to see it with my eyes. I have even tried enabling view hidden items.
Tried to execute which sdk. but it clearly says which: no sdk in (..
...
has anyone else experienced similar issue. Any help is highly appreciated.
which bash implementation are you using under windows? cygwin? gitbash?
I believe at least in gitbash that the path syntax is /e/sdkman/, i.e. you would do:
export SDKMAN_DIR="/e/sdkman" && curl -s "https://get.sdkman.io" | bash
but it's been a long time since I was on windows and I suspect this is bash-implementation specific (i.e. it might differ between cygwin and gitbash for example).
If this assumption is correct, the syntax you were using might have created a directory called E:/sdkman under your user's home directory or whatever directory you happened to be in when you ran this. Just guessing here, but worth a look.
Firstly, I am new to Linux so excuse me if any terminology is wrong; I'll try to phrase the problem as competently as possible.
I have installed Ruby (2.4.0) via Linuxbrew. The ruby command works fine; it installed correctly. However, when I try to use the gem command (which Ruby should have installed) I receive this error:
bash: /usr/bin/gem: No such file or directory
Now, because I installed this with Linuxbrew I know that this directory isn't correct. For example:
result of which gem : /home/me/.linuxbrew/bin/gem
result of which ruby : /home/me/.linuxbrew/bin/ruby
Therefore, it seems gem is installed but the gem command isn't linked to the correct path. I assume I need to direct the gem command to the path of which gem as opposed to /usr/bin/gem that bash is saying doesn't exist. How would I go about changing this? I tried in vain to change the bash_profile but I'm not sure what to do.
Again, excuse me if ruby and gem are not referred to as commands and if the problem isn't the "default directory" as stated in the title. I wasn't sure how to label it.
EDIT/TL;DR:
Basically, how can I make gem execute this: /home/me/.linuxbrew/bin/gem instead of looking for the program in /usr/bin/gem?
Instead of running gem, run /home/me/.linuxbrew/bin/gem, i.e. type the full path name (followed by any arguments you may need).
If this becomes too tiresome, you could change your PATH. Prepend your bin directory with
PATH=$HOME/.linuxbrew/bin:$PATH
First, the reason you get the error /usr/bin/gem not found, is that earlier in the same shell session, the file used to be there. Bash will cache this to speed things up when running the same command many times. Running hash -r will clear this.
Editing PATH you seem to have managed, hence the which command gives the result it does.
To answer my own question-
As I had previously installed and uninstalled Ruby via apt-get instead of Linuxbrew in the same Terminal window, Bash was looking for gem in usr/bin as opposed to the path specified in my bash_profile to Linuxbrew.
Therefore, Stian's answer above with hash -r would also work, I am sure.
I'm using the Atom editor. Yesterday, if I typed:
sudo atom . it opened the current directory as root
sudo atom it opened Atom with whatever I last had open as root
Today if I run either of those commands nothing happens. The editor doesn't open and there are no error messages.
These terminal commands worked yesterday on these exact same files, today they do not.
How can I fix this?
Why is this happening?
If I have not provided enough information it's because I don't know what info one would need to have a fuller explanation of my circumstance. Let me know what I should add I'll happily edit this question to provide it.
Atom : 1.13.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0
Ubuntu 14.04 LTS
Elementary OS Freya (64-bit)
After updating Atom text editor it seems I require to run --no-sandbox flag but after a while it becomes boring so I wrote a simple BASH script to be doing this for me:
eval "atom --no-sandbox flag"
just save this in a common directory that you frequently use and type ./atom_text_editor.sh in the terminal to deploy(Depending on the name you choose for your script)
A recommendation, when working on linux avoid using sudo or su instrucctions, they are intended to execute privileged instructions like system configurations. It might be related to permissions, execute ls -al and verify that the owner/group of yor files is root, if not, then check if "others" have read permission, if not, then thats is the problem.
Be aware running atom with sudo is not recommended.
I've had this problem for a few days, I installed atom using snap (on ubuntu 18.04) a few weeks ago, back then it worked perfectly, but the last few days if i ran 'sudo atom' nothing would happen at all, reinstalled it using snap, still didn't work, removed settings, still didn't work.
I ended up installing atom using the apt packagage manager and now it works. I used this guide: https://codeforgeek.com/install-atom-editor-ubuntu-14-04/
Furthermore when running atom with sudo it should be ran with the --no-sandbox flag.
Conclusion: seems to be a problem with atom when installed using snap.
I am following this tutorial that is like the hello world for post-commit
I am using Ubuntu 10.04. I installed svnnotify and ran $ which svnnotify which output:
/usr/bin/svnnotify
so I changed the path in the turorial from /usr/local/bin/svnnotify to /usr/bin/svnnotify
I also tried changing the line: #!/bin/sh to #!/bin/bash since bash is the login shell in ubuntu 10.04.
I tried to run it the way the tutorial originally had it, with my changes, and combinations of the two.
Every time the commit is successful but I get
Warning: post-commit hook failed (exit code 1) with no output.
The original way had output not found
I am very new to linux and shell scripting and have exhausted everything I can think of. What am I doing wrong?
Get the script working and tested before trying to run as a commit hook. I expect that your problem is something to do with the script, maybe not being marked as executable, environment wrong, etc.. i.e. if you can't get it to run successfully from the command line, this is more of a unix/shell question and doesn't really have anything to do with SVN (yet).
I'm not sure whether this applies in the Linux world, but in the Windows versions of SVN I've used, the code which runs the hook scripts only captures STDERR. If your hook script is only writing messages to STDOUT, that would likely explain the "No Output" warning.