I knew that there is a variable PWD which is changed when I type the command cd. But when I try to change it manually the current directory isn't changed. How to manipulate PWD directly?
POSIX describes PWD:
Assignments to this variable may be ignored.
Assignments are not special in bash, dash, ash, zsh or ksh, and the value will simply be overwritten next time the shell changes directory.
While other shells might support such a variable as well, the $PWD variable is generally specific to the bash shell.
The bash manual says:
PWD
The current working directory as set by the cd builtin.
Meaning it will be set when you use the cd builtin to change a directory but bash will not change the current directory when you set $PWD.
At least on my Mac and Linux machines running bash you can just overwrite the variable, so running PWD=/ will change your current directory (in the prompt) to /.
The variable PWD in bash is in control of the shell's working directory (again only the prompt) and you will see that the directory after the PWD= command has been changed but the pwd command isn't impacted by the change.
<0>xxxx#dhcp89-089-034:~$ PWD=/
<0>xxxx#dhcp89-089-034:/$ pwd
/Users/xxxx
Now the environment variable PWD is a bash prompt thing and is not the real working directory, nor is modifying it a useful thing to do unless you actually use the 'cd' command.
Related
I was assigned an account for log in to a remote server, and I want to change my default shell.
I tried chsh command but it says: chsh: "/public/home/{my_id}/bin/zsh" is not listed in /etc/shells.
If you don't have permission to install zsh system wide, a quick fix is to append exec ~/bin/zsh -l to ~/.bash_profile (if bash is the current shell), or an equivalent rc file for the current login shell.
zsh -l starts zsh as a login shell.
exec COMMAND replaces the current process with COMMAND, so you'll only have to type exit (or press ctrl+d) once.
~/.bash_profile is executed when bash starts as a login shell, you can still run command bash normally.
Depending what is in ~/.bash_profile (or equivalent), you may wish to avoid executing its other contents, by putting exec ~/bin/zsh -l at the start of the file (not the end), and copy/port anything important over to the zsh equivalent, $ZDOTDIR/.zprofile.
I might also do export SHELL="$HOME/bin/zsh", although I'm unsure of the full effects of setting SHELL differently to that specified for your user in /etc/passwd, to a shell not in /etc/shells, and to a shell binary in your home path.
First check all the shells available on your linux system
cat /etc/shells
Use chsh command line utility for changing a login shell with the -s or –shell option like this.
# chsh --shell /bin/sh tecmint
Question: Is the environment variable PWD always defined under Linux independent of the command shell (neglecting non-command shells)? In other words, will a command like "ls $PWD" always run?
Posix compliant shells will set this environment variable. Look for PWD in http://pubs.opengroup.org/onlinepubs/009604599/utilities/cd.html
PWD
This variable shall be set as specified in the DESCRIPTION. If an application sets or unsets the value of PWD , the behavior of cd is
unspecified.
or section 2.5.3 "Shell variables" in http://pubs.opengroup.org/onlinepubs/009604599/utilities/xcu_chap02.html
Variables shall be initialized from the environment... If a variable
is initialized from the environment, it shall be marked for export
immediately
PWD
Set by the shell to be an absolute pathname of the current working directory,
Is the environment variable PWD always defined under Linux independent of the command shell?
No, and I don't see why this could be the case, because the PWD variable is automatically updated (at shell initialization and) after using the cd command, which is precisely a shell builtin.
Relevant documentation about PWD can be found e.g. in:
the list of Bash variables detailed in the Bash reference manual,
the "Pwd" article in Wikipedia,
or the documentation of cd in the POSIX Standard
Below is a sample Bash session to exemplify the link between PWD and cd:
/$ echo "$SHELL"
/bin/bash
/$ echo "$PWD"
/
/$ cd usr/bin/
/usr/bin$ echo "$PWD"
/usr/bin
In other words, will a command like ls $PWD always run?
Actually, the $PWD syntax corresponds to a shell parameter expansion, so ls $PWD couldn't be properly evaluated without a shell.
A remark in passing: it is strongly recommended to double-quote your shell variables, writing thereby ls "$PWD" in this case, to avoid troubles if the variable contains spaces or other special characters.
I have a Red Hat Linux machine where I am not root.
In my home folder, I added this to my .bash_profile and .bashrc:
export PATH=/path/to/my/directory:$PATH
Then, I ran ./.bash_profile and ./.bashrc.
However, $PATH is not updated.
Any idea why this happens?
When you run these files -- like when you conventionally execute any script -- they're executed in a separate shell, and changes to that shell's state (working directory, variables, etc) are lost when that shell exits. If the goal is to change the state of the interactive shell that you're operating in, you need to source them instead.
Syntax is as follows:
source .bashrc # on extended shells such as bash only
. .bashrc # or on any POSIX-compliant shell
The space is critical; ./.bashrc would instead be trying to run .bashrc as an executable, with its own interpreter, whereas . .bashrc is using the . command documented at http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_18 to execute the contents of the file in your current interpreter.
You need to source your .bash_profile to get the changes in your current shell.
I've incurred a worrisome issue with my bash shell. I was editing my bash_profile and accidentally exported an incomplete command (export PATH=/usr/local/bin). After I had reloaded my terminal, nearly all of my bash commands fail to work properly. When I try to run any one of them, the errors state: command not found.
How do I fix this? Is there an alternate way to open or find my bash_profile?
I would appreciate any immediate input I can get on this issue. Thank you in advance.
You can execute commands if you can give the directory name. Almost all the basic Unix commands are under the /bin or /usr/bin directory. For example, /bin/mv.
Fortunately, builtin commands are still recognizable.
Move your .bash_profile and .bashrc file out of the way for now, and see what the system default is.
You can manually edit your PATH on the command line to:
$ PATH="/bin:/usr/bin"
$ cd
$ mv .bash_profile .bash_profile.bak
$ mv .bashrc .bashrc.bak
$ mv .profile .profile.bak
$ mv .bash_login .bash_login.bak
NOTE: Some of these mv command may fail simply because that particular file may not exist.
which will give you access to most of the basic Unix commands. Or you can specify the commands with their full directory names:
$ PATH="/bin:/usr/bin"
$ cd
$ /bin/mv .bash_profile .bash_profile.bak
$ /bin/mv .bashrc .bashrc.bak
$ /bin/mv .profile .profile.bak
$ /bin/mv .bash_login .bash_login.bak
Now, log in again and see what your default $PATH is set to. This is set by the /etc/profile. You might find that's just fine, and remove setting PATH in your startup script.
The standard for PATH is something like this:
/usr/share/bin or /usr/local/bin - These contain non-standard Unix/Linux commands. For example, if you install Maven on your system, the mvn command will usually be located in one of these directories (maybe as a symbolic link). This directory is a place where commands not found in the /bin and /usr/bin directory are stored. This directory is first, so you can replace the version which came with your system with more recent versions. For example, I might have VIM 6.4 installed, but I want to use version 7.3 instead.
/bin:/usr/bin - The standard directories where 99% of the Unix commands live.
$HOME/bin - These are executables you wrote -- either scripts or binaries. This is at the end of the PATH list because it makes sure that you don't accidentally execute the wrong version of the command. Imagine if some joker wrote a shell script called cp that executed /bin/rm instead and placed it in your $HOME/bin directory.
Other directories you'll see may include /sbin/ and /usr/sbin which are administrator commands (ping and ifconfig are sometimes in one of these directories.) /opt/bin/X11 (or wherever the X11 binaries are stored). Sometimes other commands will futz around with your PATH, for example Perlbrew.
#fedorqui's comment provides a quick fix.
The OP could also have used the following to quickly get to a shell with default values for $PATH:
To create a bash shell with a pristine default environment:
without running profile/initialization scripts
without inheriting any environment variables from the current shell
run:
/usr/bin/env -i bash --norc
Note:
Due to use of env's -i option, many environment variables that are normally set will NOT be set in the resulting shell , such as USER, HOME and LANG.
Similarly, the $PATH value you'll get is presumably one hard-coded into bash itself, but it should provide access to at least the standard utilities.
--norc suppresses loading of ~/.bashrc, which normally happens by default for interactive non-login bash shells (bash also supports the --noprofile option to suppress loading of /etc/profile and ~/.bash_profile, but it doesn't apply here, since the shell created is a non-login shell).
If env is in the current shell's $PATH, env -i bash --norc will do.
env is in /usr/bin/ on at least Linux and on FreeBSD/OSX, probably also on other platforms.
I would like to create (and execute) a shell script in my home directory (/home/user).
Have tried the following:
printf "cd /mypath\n" > myShortcut.sh
chmod +x myShortcut.sh
sh myShortcut.sh
where am I going wrong?
(am trying to set up a shortcut to navigate to a different directory)
What is exactly wrong here? That you are still in /home/user after the script executes? Well thats because executing the script creates a child shell that returns to the parent shell once the script ends. Therefore your cd has NO EFFECT in your current shell.
If you want to execute the script in the current shell (as opposed to in a subshell), use the source (or .) command:
source myShortcut.sh
This should then change the directory as expected.
In addition, sourcing also allows you to set and change environment variables in the current shell--a very frequent question in its own right :-)
That won't work because of what the other answer says. The script operates in a child shell.
For a shortcut like that, you could set up an alias, edit the .bashrc file in your home directory and add a line like
alias shortcut='cd /mypath'
Substitute "shortcut" for whatever you want to name it, and mypath to the path you want.
Restart the shell (close terminal and reopen or w/e) and that should work just as you want.
Then you can use "shortcut" anywhere you want in the shell.