An important point that should be made: a link is always a link, and never a copy! A hard link is not a copy. A hard link is a duplicate inode pointer, so both are "real" files. i.e.:
$ echo "foo" > fileA $ ln fileA fileB $ ln -s fileA fileC $ cat file B foo $ echo "bar" > fileA $ cat fileB bar $ cat fileC bar $ rm fileA $ cat fileB bar $ cat fileC *error* The difference between a hard link and a soft link is, the soft link points to a file by name. A hard link points by inode, so after you remove the original file, it still exists with the second filename. But they're not separate copies, they're the same file! On Wed, Mar 3, 2010 at 7:32 AM, Blues Renegade <[email protected]>wrote: > > I think you're making it much harder for yourself by mentally > cross-referencing everything in Linux back to your DOS/Windows knowledge. > You'll have a much easier time if you "forget" about DOS/Windows and > approach Linux like a kid learning about computers for the first time. > > When I first got into Linux, I decided to go back to where Linux came from > and picked up some old UNIX books where everything was done on the command > line, they didn't even have an X-server yet, and to this day, most UNIX > server admins run a console-system only, no GUI! Most would never dream of > using a GUI, seeing it as a headache; more programs and config files to > break and wreak havoc on the server's stability. > > As for links, they are fairly straightforward. There are 2 kinds: hard > links and soft links. > > A hard link is actually just a copy of a file. Personally, I have never > used hard links. I use cp -a (-a archives a file with its original date/time > and preserves ownership and permissions) if I want to duplicate files. > > A soft link is a shortcut to a file; under the covers it's nothing more > than a pointer that contains the path to where the file exists. > > IMPORTANT! The path it stores is the text you enter when you create the > link. The ln command does NOT try and validate your path. The UNIX/Linux > philosophy is that commands are small programs with a very specific purpose. > If you want/need more functionality, then you are expected to combine the > commands using piping and/or redirection to get the job done. Once you learn > enough commands and know how to combine them, the light bulb will go on and > you'll realize the true power of UNIX (in our case, Linux). > > CREATING LINKS: > > For example, you're in your home directory and you want a quick way to 'cd' > to a /home/dos-man/programming/c/linux/utilities. > > Here's a FLAWED WAY of creating a soft link... I'm showing you a pitfall > first: > > ln -s ./programming/c/linux/utilities/ c-utils > > ln = link command > > -s = soft link (shortcut, pointer, stored path, however you want to > remember it) > > ./programming/c/linux/utilities = a relative path (relative reference) to > the directory utilities > > The period at the beginning points to the current directory. (Not very > exact is it?!) > > c-utils = the filename of your link (shortcut) i.e. this is what you'll use > with cd to save typing that long path > > You're working away in /home/dos-man/programming/c/dos/ and you decide to > go work on a linux utility, so you run: > > cd c-utils > > and surprise, it fails! > > What it does is try to cd from your current directory to your link's path. > The cd command replaces the period in the link with your current directory > and tries to change to the new "fangled" (mangled is more like it) path: > > It's as though you entered: > > cd /home/dos-man/programming/c/dos/programming/c/linux/utilities/ > > No such path exists on your system (and if by chance it does, then you're > not where you expect to be!!). > > **** TIP: When creating softlinks, include the complete path (AKA absolute > reference). > > > To fix the problem above, rm c-utils to remove the link you created. > > Re-create it with the complete path this time (an absolute reference). > > ln -s /home/dos-man/programming/c/linux/utilities/ c-utils > > **** TIP: It's a good idea to include the trailing slash when creating > links to directories, so when you look at the link with 'ls -l', you'll know > it's pointing to a directory. > > > Hope that helps you to start using links right away. > > BEST TIP OF ALL: Forget registries, forget Windows, forget DOS, and you'll > have a much easier time learning Linux!! Start fresh; after all, UNIX came > first, then MS-DOS borrowed heavily from UNIX and ended up as a very watered > down proprietary sub-set with some subtle (proprietary?). > > Many of the commands in UNIX were never replicated in DOS, so they will be > completely new to you. New concepts and ways of thinking to grasp. While DOS > had piping and redirection, without a rich command set you were still very > limited in comparison to UNIX. > > John > > > Dos-Man 64 wrote: > >> On Mar 2, 12:07 pm, [email protected] wrote: >> >> >>> On Tue, Mar 02, 2010 at 08:56:12AM -0800, Dos-Man 64 wrote: >>> >>> >>>> My book is here. This looks like a good, little quick reference book. >>>> I can finally delete directories that aren't empty :) >>>> I still want to find a book that deals with the internals of X, so >>>> I >>>> can add programs to the start menu, add my own commands to the popup >>>> menu, change icons for applications, edit the registry (if there is >>>> one), etc. Most of the books deal only with shell commands, shell >>>> programming, using various X applications, installation, setting up >>>> networks, etc. >>>> >>>> >>> Those things you're talking about are handled by the window manager (or >>> desktop environment), not X. i.e. fluxbox has you edit ~/.fluxbox/menu, >>> gnome and KDE both have graphical editors for their menus, and so on. >>> There is no registry (programs maintain their own configuration files >>> instead). This is good, because it removes that single point of failure, >>> and makes security administration much easier. Gnome has something that >>> looks an awful lot like a registry editor, called gconf-editor, but it >>> only contains preferences for the desktop environment, and only for the >>> local user (no system settings).- Hide quoted text - >>> >>> >>> >> >> >> Surely there must be a book to explain these things? >> >> And I'm with you on the registry. Apparently Windows 7 has now uses >> two registries (as if one wasn't bad enough.) One is for 32-bit >> legacy apps and the other one is for 64-bit applications. >> >> On the surface the registry is a pretty good idea. But it quickly >> grows into a monster. And it was left up to software developers to >> manage or mismanage it as they see fit. It is most often mismanaged >> and it is really not practical for the end-user to do any kind of >> maintenance on it. In the end, it doesn't work (but don't tell MS >> that; let's wait to see how many decades it takes for them to figure >> it out.) >> >> >> > > -- > You received this message because you are subscribed to the Linux Users > Group. > To post a message, send email to [email protected] > To unsubscribe, send email to [email protected] > For more options, visit our group at > http://groups.google.com/group/linuxusersgroup > -- Daniel -- You received this message because you are subscribed to the Linux Users Group. To post a message, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit our group at http://groups.google.com/group/linuxusersgroup
