My system is Manjaro Linux based on Arch Linux, I use bash and bash-completion.
It works perfectly when I type something as regular user (no sudo)
$ rfkill <TAB><TAB>
block event help list unblock
but when I type it with sudo
$ sudo rfkill <TAB><TAB>
Display all 3811 possibilities? (y or n)
Obviously, it tries to complete sudo command but I want it to complete rfkill.
I know I can change this behavior by editing /usr/share/bash-completion/completions/sudo file, but I have no idea how to say if second word is not a flag for sudo then use completion for next word.
Do you have?
UPD: I'm testing Ubuntu 16.04 in virtual machine and I see it works as expected. I'll check the difference between ubuntu's /usr/share/bash-completion/completions/sudo file and mine, if any.
UPD2: There is some mirror (meaningless) difference between these files, anyway that didn't help. I have more ideas to test...
I had exactly the same problem (running Manjaro) and found a solution in the Manjaro Forum (Source):
Make sure bash-completion is actually installed by checking whether /usr/share/bash-completion/bash_completion exists. If not install it with pacman -S bash-completion
In your ~/.bashrc file make sure that complete -cf sudo is commented out. Otherwise, this will make sudo only auto-complete filenames and commands but not use bash-completion.
I hope this helps you solving the problem
use double tab:
sudo rfkill <TAB><TAB>
UPD
if there is not that line, add this to your .bashrc
complete -cf sudo
Related
I realise this might be a stupid question, but I've been trying to follow the advice on the following post https://stackoverflow.com/questions/16928004/how-to-enter-ssh-password-using-bash
However, I've come up to a problem. I installed expect with sudo apt-get install expect but now embarrassingly I can't figure out where the script interpreter is. It doesn't seem to be in the normal paths where people look to (i.e /bin/ or /usr/bin/ ).
It does seem to have installed, since $ expect seems to work, but I just can't use the interpreter (i.e I try to shebang it like everyone else with #!/bin/sh/expect and it gives an error).
You can find the location by listing all the files the package expect provides by dpkg -L:
dpkg -L expect
or narrow it down to only the filenames ending in expect:
dpkg -L expect | grep '/expect$'
or if resides in typical binary directories:
dpkg -L expect | grep -E '/s?bin/'
Also the typical way to go through the $PATH for an executable is to use:
which expect
or better (considering shell internals), not strictly needed in this case though:
type -a expect
whereis expect
... (you could have guessed it ;)
in the picture below you can see that it says chmod command is not found yet it has chmod installed. I am installing metasploit directly from the terminal(I did not install any desktop environment and don't want to run msf from there). Is there any way to solve this? I would gladly appreciate any replies.
Instead of using that command, use this instead
curl https://raw.githubusercontent.com/rapid7/metasploit-omnibus/master/config/templates/metasploit-framework-wrappers/msfupdate.erb > msfinstall && chmod 755 msfinstall && ./msfinstall
Remove the backslashes from the composite Bash command, they're used in Linux to escape the space character. For example, ỳou would have to type:
cd ~/Documents/My\ Folder
to access
~/Documents/My Folder
By writing the command the way you did you were looking for the ' chmod' command instead of 'chmod', you've basically inserted a space before the command name.
I'd suggest studying Linux Bash scripting before venturing into Metasploit.
You would otherwise continually stumble against this kind of issues, also if you'd like to work with Metasploit from its command console it's pretty much mandatory to study Linux Bash scripting (and the Linux OS as a whole).
bash: __vte_prompt_command: command not found
Whenever I open a terminal, I am greeted with this line. Also, this is printed each time I enter a command in the terminal.
I am a linux-noob, and would be happy to read up, if someone can point me to some resource, or hint at a possible solution. I tried google-ing, but was unable to turn up with any useful results.
I did not do anything specific just before this started popping up.
Thanks in advance :)
Additional Info:
The terminal I used is the default gnome-terminal
Fedora 20
It sounds like a program named VTE has set your bash environment variable PROMPT_COMMAND to invoke a function called __vte_prompt_command.
The PROMPT_COMMAND environment variable defines a command that is executed before every new prompt is displayed to the screen. It can be very annoying when this command produces unexpected output.
You can temporarily get rid of the annoying messages by entering this command in the terminal:
__vte_prompt_command() { true; }
This creates a dummy function that does nothing - you can confirm by looking at the output of this command:
type __vte_prompt_command
After applying the hack to my system I see this:
__vte_prompt_command is a function
__vte_prompt_command ()
{
true
}
However, this is an indication that VTE may not be installed properly and/or may be broken. You might want to try to reinstall VTE, if possible. I would not recommend putting this permanently into your ~/.bashrc file.
I am running Ubuntu 18.04 with the default gnome-terminal and ran into the same problem but wanted a definitive solution.
After trying the solutions suggested previously, I still had the message:
__vte_prompt_command: command not found
comming up after starting a new terminal and after each command terminated.
I searched for a file in for instance .bashrc, .profile that would be doing a source /etc/profile.d/vte-2.91.sh with no luck.
Than I remembered that a long time ago I added the following line in my ~/.bashrc:
export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND$'\n'}history -a; history -c; history -r"
in order to append command line histories to all opened terminals. I figured out that commenting it solved the problem.
#export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND$'\n'}history -a; history -c; history -r"
than
$ source ~/.bashrc
Thought I would share this for anyone having the same problem.
You can disable the corresponding code by editing your ~/.bashrc by using sudo gedit ~/.bashrc, searching for the string "vte" with STRG+F and outcommenting the line with a #.
On my system, the line looked like this, I guess an old installation of Ubuntu Budgie put it there:
if [ $TILIX_ID ] || [ $VTE_VERSION ] ; then source /etc/profile.d/vte.sh; fi # Ubuntu Budgie END
And if it looks like this, the line in your terminal will not appear anymore:
#if [ $TILIX_ID ] || [ $VTE_VERSION ] ; then source /etc/profile.d/vte.sh; fi # Ubuntu Budgie END
For CentOS7 (64 bit):
Try installing using yum command.
sudo yum update -y
sudo yum install -y terminator
sudo yum install -y epel-release
sudo yum install -y terminator #again
Resart the command prompt terminal, This worked for me (:
Reference: http://bytefreaks.net/gnulinux/install-terminator-in-centos-7-64bit
set +v
I think you may somehow made: set -v (Prints shell input lines as they are read.)
so set i
This might be a noob question, but I need help. I screwed up my terminal by trying to alter my path variable using the following command:
$ sudo nano .profile
Before I did that, if I were to type:
$ echo $PATH
I would get: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
When I opened .profile in nano it told me that the file didn't exist. I figured that made sense, since I had never edited this file before. I proceeded to enter a path to a directory I was using for a php framework and saved the file.
After I saved the file, I noticed that none of my bash commands are working. Now I can't do anything from the terminal. I can't even edit .profile in nano because it says -bash: nano: command not found
I'm clearly new to working with the terminal. I feel completely lost. Please provide some guidance on how to restore the terminal to working condition.
Use absolute paths.
$ /usr/bin/sudo /usr/bin/nano .profile
If you add something to a path, never just do
PATH=/path/to/something
instead do
PATH=$PATH:/path/to/something
By the way, you shouldn't/don't have to use sudo to edit your own file, such as .profile. Use sudo only when you need to edit the file which doesn't to belong to your account.
I had the same problem!
The way I solved was writing the follow command in the terminal:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/local/bin:/usr/local/git/bin:/usr/X11/bin
Hope it can be useful for you
This is about me being stressed by playing the game "type a command and remember to prepend sudo or your fingers will get slapped".
I am wondering if it is possible somehow to configure my Linux system or shell such that when I forget to type e.g. "sudo apt-get install emacs", instead of just telling me that I did something wrong, gksudo would get launched, allowing me to acknowledge my credentials and get on moving. Just like UAC does on windows.
Googling hasn't helped me yet..
So is this possible? Did I miss something? Or am I asking for a square circle?
Edit 2010 July 25th: Thanks everyone for your interrest. Unfortunately, Daenyth and bmargulies answers and explanations are what I anticipated/feared since it was impossible for me to google-up a solution prior to submitting this question. I hope that some nice person will someday provide an effective solution for this.
BR,
Christian
Linux doesn't allow for this. Unlike Windows, where any program can launch a dialog box, and UAC is in the kernel, Linux programs aren't necessarily GUI-capable, and sudo is not, in this sense, in the kernel. A program cannot make a call to elevate privilege (unless it was launched with privilege to begin with and intentionally setuid'd down). sudo is a separate executable with setuid privilege, which checks for permission. If it likes what it sees, it forks the shell to execute the command line. This can't be turned inside out.
As suggested in other posts, you may be able to come up with some 'shell game' to arrange to run sudo for you for some enumerated list of commands, but that's all you are going to get.
You can do what you want with a preexec hook function, similar to the command-not-found package.
There's no way to do this given the current linux software stack. Additionally, MS has a patent on this behavior -- present a user interface identifying an account having a right to permit a task in response to the task being prohibited based on a user's current account not having that right.
I don't think this really works in a general way (automatically deciding which application needs admin rights). However you could make aliases like this for every application:
alias alias apt-get='gksudo apt-get'
If you now enter apt-get install firefox the gnome asks for the admin password. You can store the commands in ~./bashrc
You could use a shell script like the following:
#!/bin/bash
$#
if [ $? -ne 0 ]; then
sudo $# # or "gksudo $#"
fi
This will run a command given in the arguments with a sudo prefix if the command came back with a non-zero return code (i.e. if it failed).
Use it as in "SCRIPT_NAME apt-get install emacs" for example. You may save it somewhere in your $PATH and set it as an alias like this (if you saved it as do_sudo):
alias apt-get='do_sudo apt-get'
Edit: That does not work for programs like synaptic which do work for non-root users but will give them less privileges. However, if the application fails when invoked without root privileges (like apt-get does) this works fine.
In the case where you want to always run a command as root but might already be root, you can solve this by wrapping a little bash script around it:
#!/bin/bash
if [ $EUID = 0 ]; then
"$#"
else
gksudo "$#"
fi
If you call this something like alwaysroot.bash and place it in the right spot on your PATH, then you can call your other program like this:
alwaysroot.bash otherprogram -arguments...
It even handles arguments with spaces in correctly.