• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

short cuts in Linux

ynotravid

Senior member
What is the best way to create a shortcut to a buried directory.

I ask because I hate having to type out:
cd /usr/local/games/hlds/hlds/cstrike/addons/adminmod/config/
every time I want to do something like make changes to my user.ini file.

I know this might will sound rediculous to people who know what they're doing but I tried to make a hard link to this directory and it didn't work. Is this not possible?

Thanks.
 
tab compleation is your friend, but to answer your question:

ln -sf /usr/local/games/hlds/hlds/cstrike/addons/adminmod/config/user.ini /home/ynotravid/user.ini

now you just have to do vim /home/ynotravid/user.ini
or you could
cd
vim user.ini

either works
 
You can make a symlink:

ln -s /path/to/existing/directory /path/to/new/link

You could also forego filesystem mucking and just make a shell alias that takes you there:

alias KungFu='cd /usr/local/games/hlds/hlds/cstrike/addons/adminmod/config/'

Then you can just type KungFu and it'll drop you into that directory. Of course you can name it whatever else. 🙂

The alias will need to be put in a shell init file to be permanent, try ~/.bashrc .
 
Thanks guys.

I was having a hard time finding it in the documentation. The sim link worked but why won't a hard link work? Isn't that directory just a file?
 
I also like to make variables, something like this:

export FOO=usr/local/games/hlds/hlds/cstrike/addons/adminmod/config/

Then all you have to do is:

cd $FOO

That way you can put the variable in your .bashrc or .profile files. That way if you do something speficic you can use that instead of putting symlinks everywere.

Or if there is some command I only use every once and a while and I don't want to deal with user variables, I'll put that command in a script.

Something like (use "which bash" to find exact location)

#!/usr/bin/bash

FOO=usr/local/games/hlds/hlds/cstrike/addons/adminmod/config/

cd $FOO

vi $FOO/config.file
#or whatever you like

# done

🙂



 
A hardlink would probably work but it's not a shortcut like a symmlink is. Hardlinks can't cross filesystem boundaries though, so if /home or /usr are seperate partitions you can't use one. With a symlink it's also easier to see what's going on, with a hardlink it's hard to tell where the file reall needs to be to work.
 
since unix FSes don't have real garbage collection, they can't allow hard linking to dirs. They are refcounted so a reference loop will cause a memory leak, just like in perl.
 
Any memory leak from a hardlinked directory would be in the application not the kernel or filesystem as the inodes ref counts would stay the same no matter how many times you chdir into it. I think it's more the fact that if you hardlinked a directory you couldn't tell it apart from it's other names so it would be real easy to get into an infinite loop in something as simple as 'ls -R' or 'find . ' and the only way around that would be to start comparing inode numbers and looking for matches which would slow things down a lot.
 
I know, but the ref count won't go up for a chdir, that would generate way too much filesystem activity. And also the file handle count would only get out of hand if the program doesn't close old directories properly and that would be triggerable on a large filesystem without any hard linked directories.
 
I'm talking about the link operation itself. nothing to do with traversing the FS. that's the same as if there were a symlink.
 
I still don't get how allowing more than one link to a directory name would cause a memory leak, the ref count is maintained for directories anyway so the difference between it being 2 and it being 1 isn't going to cause a problem any more than it would for any other type of file.
 
when you rmdir, the link count will then be 1 and the inode won't be returned to the free pool. (Not to mention that getting to the point where you CAN rmdir is quite a task.)
 
I understand that, and when you run ln to create a hardlink the ref count will be upped to 2, but where is the leak?
 
rmdir can't work on a dir with any contents. A dir which has a hard link to it within it will always have that looped path as a content of the dir.
 
Back
Top