I know about cd -
and pushd commands.
what i am looking for is something could be described as the following:
1- save what pwd command return to you in some kind of variable (say X)
2- go to whatever other directories you want to visit
3- once done , cd X (go back to the original working directory)
Thanks Community for your help and for the amazing tips i find here :)
Cheers,
Udai
You can do it easily exactly as you say, with variables. Bonus, you can access your files from elsewhere:
GOLDMINE=`pwd`
cd /tmp/casino
play
echo "oops, forgot my wallet"
cat $GOLDMINE/wallet
cd /tmp/bedroom
play harder
echo "gotta go back to work"
cd $GOLDMINE
(well, actually I'd probably use something short like $D, but you get the gist)
Amadan is correct, however if you're really dead-set on it, you can do
alias back='cd '`pwd`
Then do your browsing, then type back to come back to the directory you ran alias in.
Edit: Slightly more sophisticated idea: add
alias save=`alias back="cd $PWD"`
to your ~/.bashrc. Then, you can type save in a directory, browse, then back will bring you back to the original directory.
Related
I feel like I'm missing something very basic so apologies if this question is obtuse. I've been struggling with this problem for as long as I've been using the bash shell.
Say I have a structure like this:
├──bin
├──command (executable)
This will execute:
$ bin/command
then I symlink bin/command to the project root
$ ln -s bin/command c
like so
├──c (symlink to bin/command)
├──bin
├──command (executable)
I can't do the following (errors with -bash: c: command not found)
$ c
I must do?
$ ./c
What's going on here? — is it possible to execute a command from the current directory without preceding it with ./ and also without using a system wide alias? It would be very convenient for distributed executables and utility scripts to give them one letter folder specific shortcuts on a per project basis.
It's not a matter of bash not allowing execution from the current directory, but rather, you haven't added the current directory to your list of directories to execute from.
export PATH=".:$PATH"
$ c
$
This can be a security risk, however, because if the directory contains files which you don't trust or know where they came from, a file existing in the currently directory could be confused with a system command.
For example, say the current directory is called "foo" and your colleague asks you to go into "foo" and set the permissions of "bar" to 755. As root, you run "chmod foo 755"
You assume chmod really is chmod, but if there is a file named chmod in the current directory and your colleague put it there, chmod is really a program he wrote and you are running it as root. Perhaps "chmod" resets the root password on the box or something else dangerous.
Therefore, the standard is to limit command executions which don't specify a directory to a set of explicitly trusted directories.
Beware that the accepted answer introduces a serious vulnerability!
You might add the current directory to your PATH but not at the beginning of it. That would be a very risky setting.
There are still possible vulnerabilities when the current directory is at the end but far less so this is what I would suggest:
PATH="$PATH":.
Here, the current directory is only searched after every directory already present in the PATH is explored so the risk to have an existing command overloaded by an hostile one is no more present. There is still a risk for an uninstalled command or a typo to be exploited, but it is much lower. Just make sure the dot is always at the end of the PATH when you add new directories in it.
You could add . to your PATH. (See kamituel's answer for details)
Also there is ~/.local/bin for user specific binaries on many distros.
What you can do is add the current dir (.) to the $PATH:
export PATH=.:$PATH
But this can pose a security issue, so be aware of that. See this ServerFault answer on why it's not so good idea, especially for the root account.
So,
cd .. moves back into the parent directory.
I'd like to add functionality so that I could type...
cd ...
... and move into the parent directory's parent directory.
and consequently move up an additional tier for each extra .
The idea came from an SO answer about a script called 'up' which should do essentially the same thing. But I'm curious if it'd be possible to just add to the cd command.
After a quick search I've noticed that cd is a bash builtin so I don't think it'll be possible to edit any original code. Would it be possible to create a new cd(.sh) script that executes in place of the builtin cd command when valid arguments are provided? What other ways might this be accomplished by?
Note: this is more for learning than practical application, I just think it'd be a cool thing to do.
Thanks!
You can define an alias in your .bashrc file:
alias ...='cd ../..'
and after that you can issue ... to go up two directories. If you only want that alias for cd it will work.
You can add the following lines to the file ~/.bashrc
alias cd..='cd ..'
alias cd...='cd ../..'
and so on.
After adding this lines close the terminal and open an new one. There you can us cd.. to go one directory up, cd... to go two directories up ...
Is there a way in unix/linux to execute a command when you cd to it?
I am thinking of something like
create a file 'autcd.cmd' inside /a/b/c with a set of commands
the moment someone does 'cd /a/b/c' , autocd.cmd should be executed.
Is there a simple way to do this other than hacking the filesystem?
You could globally alias cd, and have that alias check the path being cd'd to. But otherwise, there's no standard method for triggering something when someone enters into a directory. There's never been a standard "autorun" type thing in Unix as there is on Windows (which is a good thing).
I am writing my own shell program. I am currently implementing the cd command using chdir.
I want to implement the chdir with the below options :
-P Do not follow symbolic links
-L Follow symbolic links (default)
I posted a question here previously asking to know if a path is a symbolic link or actual path. But with that info I am unable to get any ideas on how to proceed with the above problem.
Thanks
Maybe I'm misunderstanding, but you just want (pseudocode):
is_symlink = method_from_other_question();
if(is_symlink and arg(-P))
fail("Can't switch directory -- is a symlink");
If you've already tried something like this and it doesn't work, include the code in your question and we can help debug it
Shells generally do a lot of trickery to find the real dir name. And they also fake a lot of stuff for our user's convenience. E.g.:
$ pwd
/home/auser
$ ls -l
adir -> some/place/
some/
$ cd adir
$ pwd
/home/auser/adir
$ cd ..
$ pwd
/home/auser
Looks logical? Then look again: the .. in /home/auser/some/place points to /home/auser/some, not /home/auser yet cd .. took you to the later.
IOW, there is no other way but to always keep in memory the absolute path of the current directory and parse it fully (and check every element of it) when doing cd.
And yes, it is not reliable. In past on one occasion I have managed to fool bash and it was showing totally wrong absolute path for my current directory.
In my bash script I need to change current dir to user's home directory.
if I want to change to user's foo home dir, from the command line I can do:
cd ~foo
Which works fine, however when I do the same from the script it tells me:
./bar.sh: line 4: cd: ~foo: No such file or directory
Seams like it would be such a trivial thing, but it's not working. What's the problem here? Do I need to escape the "~" or perhaps missing quotes or something else?
Edit
when I say user I don't mean current user that runs the script, but in general any other user on the system
Edit
Here is the script:
#!/bin/bash
user="foo"
cd ~$user
if username is hardcoded like
cd ~foo
it works, but if it is in the user variable then it doesn't. What am I missing here?
What about
cd $(getent passwd foo | cut -d: -f6)
and
USER=foo
eval cd ~$USER
works, too (foo is the username)
Change it to:
cd $HOME
Actually, I'm not sure why cd ~whatever wouldn't work. I've just tested with a small script and it worked fine:
#!/bin/bash
cd ~sbright
I actually get the same error message that you do when the specified user does not exist on the system. Are you sure (and yes, I know this is one of those is-it-plugged-in questions) that the user exists and has a valid home directory specified?
Edit:
Now that I see what you are actually doing... tilde expansion happens before variable interpolation, which is why you are getting this error.
Is the script going to be run by the user? If it is you can just do:
cd ~
Is there some reason you can't do:
#!/bin/bash
cd /home/$USER
Of course directories aren't in /home on all *nixes, but assuming you know what OS/distro your script is targeted for, you should be able to come up with something that works well enough.