Linux is easy to maintain!

[Ed Allen]

In article <3b852031$0$321$337ec7a9 at news.hockey.net>,
Midnight Writer  <emdoub at hockey.net> wrote:
>to the user).  Being based on CP/M had some advantages over being based on 
>Unix - comprehensible command structure and disk tree structure being the 
>two most obvious points.  (If the users use /home/whatever for thier files, 

    What you are familiar with does seem 'logical' but 'drive letters'
    are no more understandable to someone new to the concept.

    We have traditions to live with in the Unix world.  Some changes
    seem to take forever to become common.

    /etc		System config files

    /bin		basic binaries of commands which will be needed
			even in single-user and booting

    /dev		pointers (called device nodes) to the devices
    			you have drivers for.(Usually many more than
			you actually have connected)

    /lib		system libraries which must be available when
    			called by binaries in /bin

    /tmp		temporary file space

    /var		system log files and storage space for daemons

>                          (If the users use /home/whatever for thier files, 
>what the heck is the /usr tree called *that* for, anyway?)
>
    /usr		additional binaries, libraries, and system
    			config files

    /home		User home directories started being put here a
			few years back.  Before that they were put in
			/usr or /usr/home

    The use of /usr for additional system files in the early days stems
    from wanting the ones in /etc and /bin to be only the ones needed
    to boot the OS and risk during an upgrade.

    The machines and the disk drives of those days were both much slower
    so minimizing the amount needed to be checked on bootup was important.

    /usr was left untouched by an upgrade so it was convenient to have
    it be a separate partition or another disk entirely.(It was the
    'user' area, OS upgrades did not touch it)

    After more and more executables in /usr/bin were being thought of as
    required instead of optional they started being upgraded along with
    the OS so more systems moved to placing login directories in /home
    so it could be a separate partition, untouched by upgrades.

    A duplicate of a user's config files can be made with:

	cd /home/user;tar -cf user-conf.tar .[^.]?*

    It creates a tar archive file of all the 'dot-files' and
    'dot-directories' which contain the config settings this user
    prefers.

>MW |  Pity that it did what it claimed to do so well and so easily.
>
>TP > Experienced differ, I have found that MS DOS did *not* do what it 
>   > claimed regarding 4 floppy drives, much to my sorrow.
> 
>???  I don't ever recall *anyone* claiming that there was the possibility 
>(or need) for 4 floppy drives in DOS.  I can understand having 2, back when 
>hard drives were expensive or unavailable, or having 2 for use of 5.25" and 
>3.5" floppies (which I do) - but for what purpose did you want 4 floppy 
>drives?  How long ago was that?  Do you use 4 floppy drives on your current 
>system?  (I can't imagine giving up that many drive bays to such 
>small-capacity devices, myself.)
>
    If you are willing to wait for each command to finish or to do only
    trivial things in the background then you are behaving the way MS
    has always wanted you to.

    The multi-tasking of Unix/Linux can be stressed more without
    failing.

    With Linux you also have multiple virtual consoles.

    I often have foreground and background processes running on four
    virtual consoles at the same time.  I never thought that was in any
    way unusual for Linux people but a DOS person happened to comment
    that there was 'no way' I was actually 'using' the eleven sessions
    that the 'w' command showed.

    That was when I realized why DOS and Windows crash frequently for
    me but 'seldom do' for the Windows advocates.  They are restraining
    themselves without even being aware of it after years of
    conditioning.

    Have you even learned about what kind of aids are built into the
    shell history ?

    You know you can recall a previous command with up-arrow of course.
    Use ^R(Control-r) to search backwards for a string being present
    somewhere on the command line.  If you found the command:

	ls file-I-want

    But you wanted the 'pico file-I-want' a few commands before that,
    Another ^R will search back for it.  Then ESC will enable you to
    edit that command before execution. (^A goes to start-of-command,
    ^E goes to end, left and right arrow move across a single character,
    ^K kills the remainder of the line)

    When you have found the command you want to run again without
    changes you can hit RET instead of ESC.

    Alt-left and Alt-right arrow keys move left and right to alternate
    virtual consoles.  Alt-F1 through Alt-F6 select consoles one through
    six directly.

    'fc -l' will print out(numbered) your last 24 commands.  'fc -l -$LINES'
    will print enough history to fill your screen.

    '!100' will re-execute command number 100.  '!ping' will re-execute
    the last 'ping' you did.

    'ls -l !$' will show a long listing of the file you ended the
    previous command with.  '!117:s/txt/bak/' will change 'txt' to
    'bak' on command 117 and then execute the changed line.

    'fc 100 110' will pull commands 100 through 110 into an FCEDIT
    session so you will want to put 'export FCEDIT=pico' in your
    .bash_profile because it has been too long for me to remember
    what the default is.

    Finding a command you don't quite remember:

[eallen at allenhome eallen]$ pr
pr        printafm printmail prlong    procinfo protoize      
praliases printenv printtool probe     procmail proxymngr     
prev      printf   privatepw procbatch prompter prunehistory  
[eallen at allenhome eallen]$ pr

    I got that by typing 'prTABTAB' at a prompt.  TAB will complete
    filenames or commandnames as far as it can without further input
    and stop when additional input is needed to refine the match.  A
    second TAB will show all the potential matches, which is what I did
    above.

    I am still learning what bash can do.

-- 
>Censorship is bad.
Trolling is worse, because it makes otherwise reasonable people begin to
consider censorship might be good, in comparison.
   T. Max Devlin -- Thanks for your time.  Hope it helps.