I am on a RedHat csh.
I just modified ~/.cshrc with a wrong path and resulting in an syntax-error.
my shell just not recognize ls or gedit. So, when I again try to modify, it is not again opening with gedit ~/.cshrc.
When I boot the system it is not starting the profile.
I Have the root access and root profile is fine. Can I edit it from root.
Please help me to remove last two lines i have added to /.cshrc, using root-profile so that it works normal as previous.
thanks.
I'm guessing your PATH isn't getting set properly due to the syntax-error in your .cshrc (assumption since you mention ls isn't working). Try the following from your shell:
echo $PATH
echo is a built-in and should always work. If it returns nothing, is empty, or doesn't include a list of paths similar to /bin, /usr/bin, etc ... then your path is indeed incorrect. Use the full path to gedit on the command line like:
/usr/bin/gedit ~/.cshrc
Related
I did
brew install python3
when i run python --version it shows 2.7
Document says:
If you still see 2.7 ensure in PATH /usr/local/bin/ takes precedence over /usr/bin/
How do I go about this?
First, you'll want to verify the problem is as stated.
Try running e.g.
> echo $PATH
/usr/local/bin:/Users/jsh/code/go/bin:/usr/bin:/bin:/usr/local/sbin:/usr/texbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
You'll notice that the output is a series of paths separated by ':' characters. Your terminal looks in those locations, in order, until it finds something that matches your command (in this case 'python') and it runs that binary.
This means that earlier items take precedence over later items. You'll note that in my listing, /usr/local/bin/ is at the very beginning, and /usr/bin/ is somewhat later in the listing.
If your listing also has this ordering, you're getting a misleading message, and will need to dig deeper. Hopefully, however, you will find that either /usr/local/bin/ isn't in your list at all, or it is for some reason occurring after /usr/bin/. That's good -- you've now identified the problem -- and we're now at your nominal question, vis: how do you change the ordering?
The environment variable $PATH can be modified by any number of startup tools. There are probably ways to systematically observe all the things that are editing your $PATH, but what I would do is
1) Search in your home directory for things that might be messing with $PATH, something like:
> egrep -d skip -l PATH .*
.gvimrc
.zhistory
.zshrc
.zhistory, here, is a red herring -- it's a list of the stuff I've done in my shell, so I can ignore it.
.gvimrc is also misleading, because it's actually setting $GOPATH, not $PATH.
So the only configuration file I have messing with my $PATH, at least in my home directory, is .zshrc, the config file for my shell itself. This is typically true, and you can just start by assuming this, but it's always good to do a quick search...
2) Edit the responsible file until it is setting PATH so that /usr/bin/local/ precedes /usr/bin/. Open the file in your choice of editor and either modify the line that sets PATH, or add a line that prepends /usr/local/bin/ to PATH (if you go with the latter, make sure that prepend happens after all other modifications to the variable).
For example, my .zshrc has a block like this:
# PATH setup (Starting with hard reset)
export PATH=/sbin
export PATH=/usr/sbin:$PATH
export PATH=/usr/texbin:$PATH
export PATH=/usr/local/sbin:$PATH
export PATH=/bin:$PATH
export PATH=/usr/bin:$PATH
export PATH=/Users/jsh/code/go/bin:$PATH
export PATH=/usr/local/bin:$PATH
(Note that the FINAL LINE is the one prepending /usr/local/bin !)
Then restart your shell (or prompt it to reload the config file, but I'm betting if you knew how to do that, you wouldn't have needed this guidance!). Now re-run 'echo $PATH', and verify that the ordering is correct. If so, try running python again, and you should have an uncle named Bob.
Good luck!
At first I had
touch $NAME_OF_FILE$DATE.$FILE_EXT
then I changed it to
PATH="Logs/"
touch $PATH$NAME_OF_FILE$DATE.$FILE_EXT
The file is created correctly in the folder, however only echos are being printed in there because says commands are not found like grep, awk, and others.
EDIT: The folder is already created on my desktop
Thanks
Alan
PATH is an environment variable that specifies where executables are located and is used by your shell to look for commands executables (grep, awk, ...). You should not override it in your script.
Try:
MYPATH="Logs/"
touch $MYPATH$NAME_OF_FILE$DATE.$FILE_EXT
To understand what PATH is open a shell and type echo $PATH. You will see it contains the directories where your commands executables are.
How can I change the $PATH variable in Debian? I tried to change /etc/profile but this affected only normal users (and yes, I added path to BOTH user's and root's paths).
After that I tried to edit /root/.profile and then /root/.bashrc also ...
Neither worked. Do you know where could be problem?
This is set in the /etc/login.defs on debian 6.0 .
These are the lines you have to edit:
# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
EDIT:
I forgot to put where I found the solution: https://serverfault.com/questions/166383/how-set-path-for-all-users-in-debian
Modify /etc/environment to include a line like this:
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
If you are using a graphical display manager / GUI (a.k.a not just a shell or terminal) changing the /etc/profile, ~/.bashrc or other file will not change the PATH variable.
In this case you have to create the file: ~/.xsessionrc file and add something like this:
export PATH="$PATH:/sbin"
(depending on the path you want to add)
For more info: https://wiki.debian.org/EnvironmentVariables
NOTE for Debian 10, check out this solution first if you get command not found:
su - root instead of su root
https://unix.stackexchange.com/questions/482569/debian-10-buster-update-grub-command-not-found
Simple way for me was to create file /etc/default/su with content
ALWAYS_SET_PATH yes
so I do not have to meddle with system files directly.
I want to add a small script to the linux PATH so I don't have to actually run it where it's physically placed on disk.
The script is quite simple is about giving apt-get access through a proxy I made it like this:
#!/bin/bash
array=( $# )
len=${#array[#]}
_args=${array[#]:1:$len}
sudo http_proxy="http://user:password#server:port" apt-get $_args
Then I saved this as apt-proxy.sh, set it to +x (chmod) and everything is working fine when I am in the directory where this file is placed.
My question is : how to add this apt-proxy to PATH so I can actually call it as if it where the real apt-get ? [from anywhere]
Looking for command line only solutions, if you know how to do by GUI its nice, but not what I am looking for.
Try this:
Save the script as apt-proxy (without the .sh extension) in some directory, like ~/bin.
Add ~/bin to your PATH, typing export PATH=$PATH:~/bin
If you need it permanently, add that last line in your ~/.bashrc. If you're using zsh, then add it to ~/.zshrc instead.
Then you can just run apt-proxy with your arguments and it will run anywhere.
Note that if you export the PATH variable in a specific window it won't update in other bash instances.
You want to define that directory to the path variable, not the actual binary e.g.
PATH=$MYDIR:$PATH
where MYDIR is defined as the directory containing your binary e.g.
PATH=/Users/username/bin:$PATH
You should put this in your startup script e.g. .bashrc such that it runs each time a shell process is invoked.
Note that order is important, and the PATH is evaluated such that if a script matching your name is found in an earlier entry in the path variable, then that's the one you'll execute. So you could name your script as apt-get and put it earlier in the path. I wouldn't do that since it's confusing. You may want to investigate shell aliases instead.
I note also that you say it works fine from your current directory. If by that you mean you have the current directory in your path (.) then that's a potential security risk. Someone could put some trojan variant of a common utility (e.g. ls) in a directory, then get you to cd to that directory and run it inadvertently.
As a final step, after following the solution form proposed by #jlhonora (https://stackoverflow.com/a/20054809/6311511), change the permissions of the files in the folder "~/bin". You can use this:
chmod -R 755 ~/bin
make an alias to the executable into the ~/.bash_profile file and then use it from anywhere or you can source the directory containing the executables you need run from anywhere and that will do the trick for you.
adding to #jlhonora
your changes in ~./bashrc or ~./zshrc won't reflect until you do
source ~./zshrc or source ./bashrc , or restart your pc
I tried running a script file using bash but it showed an error
bash-3.2$ example.sh : command not found
I also tried
ls -l example.sh
I found that it was not executable, so I used
sudo chmod 777 example.sh
I again tried running it but same error was coming. I double checked that I am in the same folder as the file using ls. But still I am not able to execute the script file.
I finally tried making a dummy script file and running it , and found the same error
I think there is some problem with BASH. Can some one help me with what is the problem?
I am working on redhat, bash was already installed in my system
Since I am newbie on linux any help would be appreciated
bash search for commands in your $PATH. Apparently the current directory, ., is not in your $PATH. (This is a good thing; having . in your $PATH is insecure.)
You'll need to specify a directory name. Just type:
./example.sh
Incidentally, doing:
sudo chmod 777 example.sh
is two kinds of overkill. First, you don't need to use sudo; use sudo only when you actually need to. Presumably your personal account owns the file, so you can just use chmod directly.
Second, 777 is way too permissive. It allows anyone on the system to read, execute, or modify example.sh. (If you're the only person on the system it may not matter much, but it's still a bad habit.) Typically you should use 755 for directories and for files that need to be executable, and 644 for files that don't need to be executable.
Or just use
chmod +x example.sh
to set execute permission (your umask will prevent that from setting the permissions too loosely).
. (the current directory) is probably not on your path. Try ./example.sh or bash example.sh. You could also add . to your PATH environment variable, but that's generally frowned upon.
Your bash PATH probably doesn't include ., try running it by typing:
./example.sh
When you type a command, your shell searches your path to try to find the command, if the current directory (e.g. .) isn't part of the path, the script that you are trying to run won't be found. You'd have to explicitly give it the path to where this command is. And since it's in your current directory, you can just add ./ in front of the command.
first confirm the bash path
to check the path of bash use:
which bash
if you get "/bin/bash"
then add
#!/bin/bash
...
...
or whatever is the path on first line of your bash script