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
