No commands work in linux

Why doesn’t my bash terminal recognize any command in the shell? [closed]

Upon the request of some users, I decided to add all the intermediate steps and results to my initial post so that users can better walk me through a solution. This is added under the headline Additions below the question. Below Additions, there is a section called, «resolution,» where I have added extra steps that I have taken in order to resolve this issue: Question: Today, as I was trying to continue running my codes in the command-line shell, I noticed that none of the commands are actually recognized by the shell in Fedora 21 (kernel 4.1.13-100.fc21.i686 on an i686 (tty2)). I thought if I restart and reboot the system, the issue should resolve. However, to my surprise I noticed that the system is not starting up after login. I tried to do diagnostics by pressing CTRL+ALT+F2 when the screen goes black to see where actually it stops working. The last line that I saw a complete stop was saying:

Would you mind letting me know how to fix such issue when actually no command is accepted in the diagnostic mode in the shell by saying the following?

The only thing I can think of is some possible automatic update that I was not aware of or messing my .bashrc (which I can no longer see inside it by using the following command:) sudo gedit ~/.bashrc Additions: I was able to login to my system only after entering the diagnostic mode by pressing Ctrl+Alt+F2 right after reboot and login into the main startup which fails under normal conditions.

It is here that none of the commands are recognized by the shell no matter what. And the error message is usually:

where <. >is basically any command. The only time I was successful in getting most commands get realized by the shell was when I ran the following code (as mentioned by in the answer):

After which at least I could look for and see my files and folders and programs (since most commands are getting realized.) However, I still need to logging normally so that I can make use of all the graphics and other features of Fedora which is impossible in the diagnostic mode. To make this possible in particular I need to open my .bashrc file and fix its issues permanently (assuming that I can have access to its original version somehow.) To do this, I need to run commands like

Unable to init server: Could not connect: Connection refused (gedit:1397): Gtk-WARNING **:cannot open display:

Now, learning from the answer, I am not supposed to run this latter command as it is not executable. And instead I should run it in the following format:

After which I don’t know how to proceed. However, I don’t know why the former command (sudo) gedit ~/.bashrc is not working either. I remember that I always used to make slight changes in the .bashrc file depending on my need. This time I don’t know how I made changes in it that it caused all the issues explained here. So now, my question is whether there is a command-line based method that I can open .bashrc and look inside it and make needed changes permanently so my system logins appropriately leads me into its normal graphical mode where I see and utilize all Fedora features. Resolution I learned that once I am in the diagnostic mode through the command Ctrl+Alt+F2 right after unsuccessful login, I can temporarily fix the messed up file .bashrc by running the command PATH=/usr/bin:/usr/sbin . Then I could take a look inside my .bahsrc file through running the command line cat .bashrc . It was only then that I saw the contents of the file in which I had several paths added to the file. Since I had kept a record of my added files at the bottom of previous paths in a chronological order, I knew that the problematic path was the very last one. Now, in order to fix the issue, I had to actually modify the file. This was achieved by the command line nano .bashrc after which a new page appeared in which I had the chance of commenting out the problematic line by adding # in front of it. At the end, I saved my changes and exited. The last step I had to make was to reboot the system with its new modified .bashrc file through the command line telinit 6 after which the logging proved to be successful.

Источник

How to fix a «Command not found» error in Linux

When you’re trying to run a command (with or without sudo ) and get an error message that reads «Command not found,» this means the script or file you’re trying to execute doesn’t exist in the location specified by your PATH variable. What is this variable, and how can you run commands that it can’t find?

Great Linux resources

Understanding environment variables

In computing, a variable is a placeholder for a value that can change. You use variables every day in normal speech, although you don’t think of them as such. When you say «my laptop,» you’re using «laptop» as a generic variable or placeholder for the computer you’re carrying, regardless of whether it happens to be a Lenovo, Mac, or a Raspberry Pi in a fancy case.

Environment variables are special variables that contain information about your login session. Many of these variables are set by default during installation or user creation. They’re stored for the system shell, applications, and scripts to use when executing commands.

There are global, or system-defined, variables and local, or user-defined, variables.

Global variables

Global variables come predefined in your login shell, but they aren’t immutable and can be modified or deleted according to your preferences. You can use the printenv or env commands to display the environment variables on your system:

$ env SHELL=/bin/bash SESSION_MANAGER=local/kiwi.homelinux.local:@/tmp/.ICE-unix/1906,unix/kiwi.homelinux.local:/tmp/.ICE-unix/19 06 WINDOWID=153092103 COLORTERM=truecolor XDG_CONFIG_DIRS=/home/tux/.config/kdedefaults:/etc/xdg:/etc/kde/xdg LESS=-XR XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1 HISTCONTROL=:ignorespace:ignoredups:ignorespace:ignoredups PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/local/share/pkgconfig:/usr/lib64/pkgconfig:/usr/share/pkgconfig [. ]

The env command prints out all global environment variables. Variables are case sensitive, and all Linux distributions use uppercase for environment variable names by default.

[ Keep your favorite Git commands, aliases, and tips close at hand. Download the Git cheat sheet. ]

Local variables

A local variable exists only within a specific shell. Therefore, when you define a local variable, it’s only available in your current shell. It doesn’t propagate or persist to a new shell session unless you export it as a global variable.

Local variables are often defined in lowercase to avoid overwriting a global variable with the same name.

The PATH environment variable

The PATH global environment variable lists the directories your system searches for valid, executable commands. By default, it contains standard directories that normally store executables like /usr/bin , /usr/local/bin , and so on.

When you type in a command, such as grep or vim , your system searches through all directories listed in your PATH variable, in the order that they’re listed, until it finds an executable file by the same name. Should it fail to find one, it issues the «Command not found» error.

$ printenv PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/tux/.local/bin:/home/tux/bin $ env $PATH env: /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/tux/.local/bin:/home/tux/bin

5 ways to fix «Command not found» errors

There are several ways to fix this problem. Here are five of them.

Источник

I screwed up my system no commands work at all

After I copied and paste it it automatically executed in the terminal after realizing my mistake I corrected like this below.

export PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1/bin:$PATH 

Command 'whoami' is available in '/usr/bin/whoami' The command could not be located because '/usr/bin' is not included in the PATH environment variable. whoami: command not found 

>root@ubuntu:~/Downloads/NOOKPROJECT/nook2kernelsrc/distro>/kernel# whoami Command ‘whoami’ is available in ‘/usr/bin/whoami’ The command could not be located because ‘/usr/bin’ is not included in the PATH environment variable. whoami: command not found

2 Answers 2

You need to include the folders where commands can be found in the PATH environment variable. So it sounds like your PATH environment variable is missing the /usr/bin entry. What is the output of echo $PATH for your system?

The default for Ubuntu 14.04 is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games and you can restore this by simply running

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Then you should be able run the command you tried in the first place to add the paths, or to add them all at once you can simply run.

export PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Источник

none of the commands work in linux terminal

Nothing works. A minute before everything was fine, I was watching a movie, didn’t run anything else. I can’t even reboot it properly as reboot fails as well. Hard reset is coming. Any idea? UPDATE: I tried to disconnect the ssh session but couldn’t connect again. Had to turn it off and back again. It’s OK now but this is not the first time this happened. I would really appreciate some tips.

Drive failure, can you give us the specs of the hardware you’re using? Sounds like either the drive failed or was disconnected.

Since bash is clearly running, you could try its internal commands, especially echo . First try echo $PATH (this should include /bin ); then echo * and echo /bin/* (this should include /bin/ls ); finally if [ -x /bin/ls ]; then echo ls can run; else echo ls cannot run; fi (this should tell you that ls can run).

1 Answer 1

This could be caused by clearing your PATH variable or a drive failure. One could try /bin/ls instead of just ls , if that works do export PATH=»/bin:/sbin:/usr/bin:/usr/sbin» , that should help.

As stated in comments you’re using Raspberry PI, so probably your SD card just got disconnected, unfortunately reconnecting it won’t help.

A permanent solution to such problems would be keeping all stuff necessary to (automatically) mount a SD card in a RAM disk, but personally I don’t think it’s worth it, cause you can always do a hard reset.

EDIT

In production devices based on Raspberry PI B+ (the one with micro SD cards) we just glued card in slot, that’s also a solution.

Источник