Radified Community Forums
http://radified.com/cgi-bin/yabb2/YaBB.pl
Rad Community Technical Discussion Boards (Computer Hardware + PC Software) >> PC Hardware + Software (except Cloning programs) >> Using the Unix/Linux Shell Command-line - Part 2
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1248820932

Message started by Rad.in.UbuntuVM on Jul 28th, 2009 at 5:42pm

Title: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 28th, 2009 at 5:42pm
Continued from (Using the Unix/Linux Shell Command-line):

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1247608529/63#63 (end of previous thread)

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1247608529 (beginning of previous thread)

Remaining modules:

08-04 - Basic editing
[ No 08-05 module ]
08-06 - Configuring vi

09-01 - The Unix File System
09-02 - How Files are Stored
09-03 - Understanding Links
09-04 - Linking Files
09-05 - Symbolic Links
09-06 - Unix File Types

10-01 - Communication
10-02 - Using mail

11-01 - Customizing the Shell environment
11-02 - Environmental Variables
11-03 - Your path
11-04 - Your prompt
11-05 - .profile
11-06 - Command-line editing
11-07 - Other Shell Customizations & Options
11-08 - The end.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Jul 28th, 2009 at 7:00pm

Rad.in.UbuntuVM wrote on Jul 28th, 2009 at 5:42pm:
09-01 - The Unix File System
09-02 - How Files are Stored
09-03 - Understanding Links
09-04 - Linking Files
09-05 - Symbolic Links
09-06 - Unix File Types

11-02 - Environmental Variables
11-03 - Your path

Out of the chapters you have left, these are the more important ones.  Pay attention to these.  Almost everything in Linux is treated as a file - network sockets, device nodes, open pipes - all can be read and written to just like files, so it's essential to understand how the kernel treats files.

Environment variables affect the way the system acts.  You can change the behavior of the entire shell by playing with Environment Variables.  You path is an environment variable that tells the shell where to look for commands, so it has a big effect on which version of a command the system runs and how it looks for them.

The rest of the chapters are useful but not pivotal.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 29th, 2009 at 1:44pm
The term 'terminal' .. as it is used in Linux, typically refers to a "terminal emulator' .. no? I mean, the 'terminal' I use in Ubuntu (Gnome terminal 2.26.0) says (in 'About') > "a terminal emulator for the Gnome desktop".

Just trying to get my terminology correct.

'Terminals' were originally hardware, not software .. yes?

When folks says, "launch a terminal," they really mean "launch a software program known as a terminal emulator that emulates a physical terminal" .. yes?

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 29th, 2009 at 2:21pm
I wanted to play with vim by editing and moving around in a file .. but I didn't want to open/edit any random file on the system, cuz that might break something. So I "Viewed source" on the site's home-page (a file I'm familiar with) and saved it (.. to the desktop, which was the default location). Then I looked around and discovered the 'Desktop' (with a capital-D) was located in /home/user .. so I opened it with:

"vi /home/user/Desktop/index.rad"

.. and it worked! I know that's simple, but I'm am actually pretty stoked, cuz it means I'm getting an understanding of how things work.

Was gonna ask you, but figured it out myself.  8-)

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Jul 29th, 2009 at 3:49pm

Rad.in.UbuntuVM wrote on Jul 29th, 2009 at 1:44pm:
The term 'terminal' .. as it is used in Linux, typically refers to a "terminal emulator' .. no? I mean, the 'terminal' I use in Ubuntu (Gnome terminal 2.26.0) says (in 'About') > "a terminal emulator for the Gnome desktop". 

Typically when an admin says 'terminal' they mean anything that acts like a terminal.  A terminal emulator is popularly used when you are logged onto the box in a graphical environment, like gnome.  It can also refer to a remote terminal, like the ssh session you use to admin your VPS.  Local terminal also exist.  Press ctrl+alt+F1 to get to a text based terminal on  your virtual machine.  There should be 7 terminal, accessed by using ctrl+alt+F1-F7.  If you are logged in to a graphical session, it is usually placed on terminal 7 (so pressing ctrl+alt+F7 should take you back to it.)

Remote terminals are definitely the most common type used since you very rarely are in the same room as your servers.


Rad.in.UbuntuVM wrote on Jul 29th, 2009 at 2:21pm:
I wanted to play with vim by editing and moving around in a file .. but I didn't want to open/edit any random file on the system, cuz that might break something.

Yup, best not to mess with files unless you know what they are.  Some simple looking text files are pretty important.

Remember, you can create a new file with Vi by opening one that doesn't exist yet:


Code:
vi newfile.txt


Also, the command 'touch' creates a new blank file (or updates the last modified time of an existing file):


Code:
touch newfile.txt
vi newfile.txt


If you wanted to be creative, you could echo nothing (or something)  into a new file:


Code:
echo "" > newfile.txt

or

Code:
echo "some junk" > newfilename.txt


Or, you could use dd (which I think is short for Data Dump) to put a few bytes of random data into a file:


Code:
dd bs=8 if=/dev/random of=newfile.txt


An even more creative way to do it might be to concatenate nothing with nothing and redirect the output to a file that doesn't exist:


Code:
cat /dev/null > newfile.txt


Not sure if that one actually works, but I'll try it as soon as I get to a Linux box (in a few hours.)

HeHe.  Lots of ways to get things done.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Jul 29th, 2009 at 7:33pm
Supposedly Unix does not handle file types the way Windows does. In other words the file extention in Unix is just part of a file's name and can be eliminated or changed. Yes?

So, say I have a file named mt43.tar.gz (i do). Can I rename it to "mt43" on the server before untarring it? Without affecting anything esle?

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Jul 29th, 2009 at 7:55pm

Rad wrote on Jul 29th, 2009 at 7:33pm:
Can I rename it to "mt43" on the server before untarring it? Without affecting anything esle?

Yes, you can.


Rad wrote on Jul 29th, 2009 at 7:33pm:
Supposedly Unix does not handle file types the way Windows does. In other words the file extention in Unix is just part of a file's name and can be eliminated or changed. Yes?

This is true, but following some sort of standard is still very helpful for humans.  It is still common practice to use file extension, even tho the OS will not look at them, so that the users of the system know how to deal with the file.

For example, if you asked WiredTree to take a look at something on your server and they see a file called 'mt43', they might not have any idea what it is.  But, mt43.tar.gz is easily discernable as a Gzip compress tar archive.  Given that much information, they might even make the connection to MoveableType ver4.3.

Some programs will even look at file extensions in order to try to guess what type of file you have, even though the OS does not.

So, file extensions are still useful even though they are optional.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 30th, 2009 at 12:37pm
for the 'cp' command, is the -r option the same as -R?

http://unixhelp.ed.ac.uk/CGI/man-cgi?cp

seems so.

normally in Linux r and R mean different things.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 30th, 2009 at 6:51pm
was surprised to see the terminal in ubuntu vm REMEMBERED my last command (to open file index.rad) .. by hitting the up arrow.

come to think about it, this course didn't (i don't think) address that command .. of hitting the up-arrow to reproduce the most-recently typed command. is that a standard shell feature?

also, i've noticed i can highlight sections of text (in ubuntu terminal vim) with my mouse, while there is STILL a single blinking cursor .. BUT the vi commands i'm learning only work on/at the blinking cursor.

so i don't understand what is the point of highlighting sections of text (via click-n-drag).

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 30th, 2009 at 7:37pm
08-04 - Basic Text-Editing Commands (Insert Mode)

a variety of commands take you into insert mode
[ Recall the ESC key returns you to Command mode ]

a ('append') = takes you into insert mode .. to Append text AFTER the cursor (a for Append After)
i ('insert') = takes you into insert mode .. to Insert text BEFORE the cursor (i for Insert Before)

A (capital A) = Append text at end of the line (useful command)
I (capital I) = Append text to the BEGINNING of the line.
Note: you don't have to actually GO TO the beginning/end of the line, as the command will take you there.

o (for "open") = start a new new AFTER the current line
O (capital O) = start a new line BEFORE the current line.
s (for "substitute") the current character (where cursor is) for text you type.
can type a number here before 's' to sunstitute any number of characters
e.g. "5s" substitues (replaces) the next 5 characters after cursor with whatever text you type.
cw (change word) = change word to new text. Can also specify a number before "cw" to change more than 1 word.
e.g. "2cw" or "5cw"
c command is very flexible and can be used with other characters, such as the $
$ takes you to the end of the line, so "c$" changes all the text between cursor and end of line .. to text typed.
also, since f = find (e.g. "fX") therefore .. "cf," changes everything up until the next comma.

Following commands edit text without taking you into Insert mode:
x = cuts the character at cursor. Can also be used with a number (goes to vi clipboard)
X (capital X) cuts the character before cursor. (goes to vi clipboard)
dd = delete current line. Can also be used with a number (e.g. "4dd" .. deletes 4 lines)
d is similar to c in the way it can be combined with other letters.
dw = delets a word at a time.
d$ = deletes everything to the end of the line.
df, = deletes everything up to next comma
whereas d deletes text, c leaves you in insert mode to enter new text.
p = put (paste) .. most recently cut thing. (Can also prepend a number before p)
yy = yank (copy) the current LINE
can combine y with other letters like c and d (to end of line, or to a given character)
rX = replace current character (good for spelling mistakes)

Special commands
u = undo (older versions of vi affect last change only, not multiple undo's)
Newer versions of vim support 50 undo's by default
U (capital U) = restore current line to how it was when you arrived (assuming you don't leave that line)
. (period) = repeat the last edit/change (very powerful, especially when used in conjunction) with /pattern search/find feature
. is useful for times when  you have to perform the same edit over & over many times.
shift+>> = tab-right
shift+<< = tab-left

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 30th, 2009 at 9:13pm
Regarding the utility programs .. such as cp and mv .. is there a formal name for them? Or is "utility programs" it?

Are these programs part of the shell itself, or does the shell simply call them?

Can they be used by prgms other than the shell?

Where are they stored? In which directory(s)?

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Jul 30th, 2009 at 9:56pm
What value, if any, would there be in learning shell scripting? .. particularly as it pertains to learning programming.

I see there are different flavors of shell scripting .. bash, perl, php & python.

That might be the next logical step after learning the shell.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 31st, 2009 at 12:56am
08-06 - Configuring vi

How to set up vi with special options.
Many special options available, but not all useful
:set = lists currently set options
:set all = lists every option
Two kinds of options > on/off options and value options

To set On/Off options (such as ai)
:set ai = turns option ON
:set noai = turns option OFF (by adding 'no' before option)

To set Value options:
syntax > ":set ts=4"

Useful options:
ai = auto-indent (on/off) .. causes new lines to inherit indentation of previous lines
ic = ignore case (on/off) .. searches will be case insensitive
nu = numbers (on/off) .. display line numbers (some people like, and some don't)
sw = shift-width (value) .. number of spaces the shift+>> and shift+<< moves text
:set sw=8
ts = tabstop (value) .. number of spaces to use when displaying tabs

vi loses all these settings upon quitting
To save settings, put settings in file named .exrc and put in home directory
every line should begin with the word set. e.g.
set ai
set sw=4
set ts=4

Good idea to print out a vi reference to common commands and post it near you PC.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 31st, 2009 at 3:27pm
09-01 - The Unix File System (Hard Disk)

This chapter contains both practical & conceptual info.
Practical info = how to create links, both hard-links & symbolic links. (Links are very useful.)
How to measure amount of disk space being used, and how much is available.
Regarding conceptual (technical) info, this is nice-to-know, but not necessary to use Unix.
It's possible to create links and check disk usage without any understanding of the underlying structures.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 31st, 2009 at 4:39pm
09-02 - How Files are Stored (in a File system on a hard disk)

Everything on a Unix file system (hard disk) is treated as a file.
Even directories are treated as a file, altho a special type of file.
Directories contain:
1. a list of filenames
2. i-node numbers (i-node = information node)
In other words, directories contain a mapping between file names and i=node numbers.
Each filename is paired with a single i-node number
An i-node number = a reference to an i-node in the i-node table
FAT (File Allocation Table) in Windows = i-node table in Unix
Each i-node contains a set of info about each file:
1. file size
2. File creation, access & modification times
3. File Owner & group
4. File permissions
5. File type (file, directory, device, etc.)
6. Link count (usually 1)
7. Starting block number
Notice file name NOT stored in i-node. (File name is stored in directory.)
Nor is any of the data contained in the file stored in the i-node. (Data is stored in a block.)
Each i-node is numbered.

To display each i-node number for every file in a given diectory:
ls -i

So .. directories contain lists of filenames, each of which are mapped to an i-node number (in the directory), which corresponds to an entry in the i=node table, which contains a set of info about the i-node that includes the block number, where the actual file data is stored.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 31st, 2009 at 6:49pm
09-03 - Understanding Links

Links are very useful
Not many operating systems support links
In Unix, a given file can have more than one name
These different filenames (for the same file) can be located in different directories
e.g. file1 in dir1 directory and file2 in dir2 directory (can be the same file)
Each filename is a reference to the same data.
So if you edit the data via file1, and then open file2, you'll find the data has been modified there as well.
Each filename is called a link.
Each link has the same i-node number
Therefore each link shares the same file permissions. Can't change permissions independantly of other links.
Regarding links, no such thing as original/copy/duplicate. All are considered equal.
You can create multiple links to the same file and delete the original link without affecting the data.
The original is not somehow more important than duplicates.
[ That IS the case with Symbolic links, which we will study later. ]
If a particular file has multiple links, the rm program (remove/delete) simply UNLINKs a file. The file itself is NOT deleted.
You simply remove one reference to the file.
So you gain no extra disk space.
The data in a file is only deleted after ALL the links have been removed.
The associated block is then marked as "available" (for other files to use).
ls -l will tell you how many links there are to a given file (the "link count")
Every directory will have a Link-Count greater than 1. Because every directory contains an alias called "." ('dot').
This dot-alias is really a link.
Dot-alias automatically created for every directory (for convenience).
The directory name and dot are two different names for the same entity
to find all files/links with same i-node:
find dir -inum 1234
probably best to use root directory when finding, unless you know where all links/files are stored.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Jul 31st, 2009 at 8:29pm
Aren't Windows "shortcuts" almost the same thing as a Unix link?

I make big use of shortcuts.

09-04 - Linking Files (Hard Links)

Use program called "ln" (link)
Used like the cp program
ln somefile.html linkedtosomefile.html
Links are all about convenience
Might wanna create a link to file you check frequently, that might be buried several directories deep.
Put a link in your home directory ( ~ ) .. for easy access .. so you don't have to keep typing long directory paths.
These types of links are known as "hard links".
Next module -> Symbolic links

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 12:41am

Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 6:51pm:
was surprised to see the terminal in ubuntu vm REMEMBERED my last command (to open file index.rad) .. by hitting the up arrow.

come to think about it, this course didn't (i don't think) address that command .. of hitting the up-arrow to reproduce the most-recently typed command. is that a standard shell feature?

Ya, its a standard feature of Bash.  Some other shells also implement it.  For bash, your history is stored in a file in your home directory called .bash_history.


Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 6:51pm:
so i don't understand what is the point of highlighting sections of text (via click-n-drag). 

You can copy (but not cut) and then paste things at the cursor.

You can also copy and paste through commands in vi.


Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 9:13pm:
Regarding the utility programs .. such as cp and mv .. is there a formal name for them? Or is "utility programs" it?

I just call them commands.


Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 9:13pm:
Are these programs part of the shell itself, or does the shell simply call them?

They are executable binary files that the shell executes.


Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 9:13pm:
Can they be used by prgms other than the shell?

Yes, but they are usually executed with a shell.


Rad.in.UbuntuVM wrote on Jul 30th, 2009 at 9:13pm:
Where are they stored? In which directory(s)?

Usually in /usr/bin or /usr/sbin.  Type 'echo $PATH' to see a list of all the places they might be.


Rad wrote on Jul 30th, 2009 at 9:56pm:
What value, if any, would there be in learning shell scripting? .. particularly as it pertains to learning programming.

Shell scripting allows you to exectute a series of shell commands automatically.  Basically, you create a text file that has one command on each line, then execute the text file.  The shell will execute each command in turn.  Shell scripting has a very different feel to it than most programing languages, but the principals are the same. 

The unique thing about shell scripting is it is easier to tie together many different types of other scripts by piping the output of one file to the input of another (i.e. you might pipe the output of a perl script to the input of a compiled C++ binary.)  There are ways to do similar things in other languages, but it tends to be clumsier.


Rad wrote on Jul 30th, 2009 at 9:56pm:
I see there are different flavors of shell scripting .. bash, perl, php & python.

Perl, PHP, and Python are all individual languages not tied to the shell.  They are often refered to as scripting languages because they are read, compiled, and exectued line by line (as opposed to C, which as to be compiled first.)

Shell scripting is using the shell language.  Bash, csh, ksh, etc all offer scripting methods.


Rad wrote on Jul 30th, 2009 at 9:56pm:
That might be the next logical step after learning the shell. 

I find shell scripting to be uncomfortable, but that's just me.  Much of what you learn in shell scripting (variables, flow control, etc) will carry over to almost any language.  I don't think shell scripting supports sub routines, but you could fake it by calling mini scripts.  I'm pretty sure that the shell doesn't support Object Orientation, but you can pick that up in Ruby or something later on.


Rad.in.UbuntuVM wrote on Jul 31st, 2009 at 3:27pm:
It's possible to create links and check disk usage without any understanding of the underlying structures.

True, but understanding the underlying structures is what it will take to move to the next level.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 12:45am

Rad.in.UbuntuVM wrote on Jul 31st, 2009 at 8:29pm:
Aren't Windows "shortcuts" almost the same thing as a Unix link?

Ya, same idea.  I think Windows shortcuts are more like a Symbolic Link than a hard (regular) link.


Rad.in.UbuntuVM wrote on Jul 31st, 2009 at 8:29pm:
Links are all about convenience

Mostly.  They do occasionally solve problems that would be tricky without links.  Sometimes you want to refer to the same file from 2 different programs but they only accept relative paths and won't look above the directory they are running in.  There are other examples where it is more than convenient to use a link.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 5:33am

Rad.in.UbuntuVM wrote on Jul 31st, 2009 at 6:49pm:
Because every directory contains an alias called "." ('dot').

I'm surprised they don't mention "..", which is an alias for the parent directory.  Every directory contains this alias to its parent.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Aug 1st, 2009 at 2:37pm

MrMagoo wrote on Aug 1st, 2009 at 12:41am:
They are often refered to as scripting languages because they are read, compiled, and exectued line by line (as opposed to C, which as to be compiled first.)

Nice. A little lightbulb went on.


Quote:
I'm surprised they don't mention "..", which is an alias for the parent directory.  Every directory contains this alias to its parent.

Oh yeah, they did. But in terms of the module on 'links', the parent directory ("..") is not a link to the current directory.


Quote:
I find shell scripting to be uncomfortable, but that's just me.  Much of what you learn in shell scripting (variables, flow control, etc) will carry over to almost any language.  I don't think shell scripting supports sub routines, but you could fake it by calling mini scripts.  I'm pretty sure that the shell doesn't support Object Orientation, but you can pick that up in Ruby or something later on.

This is kinda the info I was looking for.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 1st, 2009 at 3:15pm
09-05 - Symbolic Links

Probably more widely used than regular links (called "hard links")
Purpose > create new ways to access existing files more conveniently
A separate file that contains nothing but a reference to the original file (whether or not the original file exists)
A symbolic link is separate from the original file
If you create a symbolic link and delete the original file, the symbolic link becomes a link to nothing (invalid)
Windows' "shortcuts" support the concept of a symbolic link, but not hard links.

To create a symbolic link:
ln -s
syntax e.g. "ln -s original.file sym.lnk"
symbolic links are indicated by an "l" as very first character (in permissions) .. when viewed with an "ls -l"
[ whereas hard links are determined by a 'link-count' greater than 1 ]
all symbolic links have full permissions, because the actual permissions are determined by the original file

while a hard link is a link to the i-node number, a symbolic link is a link to the file name
so .. if the original file is deleted, and a NEW FILE with the SAME NAME is created in its place ..
.. the symbolic link will still be valid, but the hard link will not .. because the new file will get a NEW i-NODE number, even tho it has the same file name.
So, in this situation, a symbolic link would be better.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 4:14pm

Rad.in.UbuntuVM wrote on Aug 1st, 2009 at 3:15pm:
So, in this situation, a symbolic link would be better. 

Another situation comes up where a symbolic link works fine but a hard link doesn't work at all.  Say you have 2 hard drives.  One is mounted on /, and the other is mounted on /home/radified (you have your own hard drive just for your home dir.)  So, /home/magoo is on one hard drive and /home/radified is on the other.

Now, say there is a file in /home/magoo and you want to link to it in /home/radified.  You cannot use a hard link because the second drive has its own inodes.  So, a hard link, which points to an inode number, cannot work for files on different drives because the inode numbers are unique to each individual drive. 

In this case, a symbolic link works just fine.  The system will warn you if you try to create a hard link.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Aug 1st, 2009 at 4:36pm
09-06 - Unix File Types

Unix doesn't use a 3-letter extension to determine file-types like Windows does
when doing "ls -l"
regular files begin permissions with a dash ("-")
directories begin with a 'd'
symbolic links begin with an 'l'
c = character device (piece of hardware, such as a serial port)
can read-from/write-to a serial port just like to/from a file.
data is typically written-to/read-from a serial port > 1 character at a time .. hence term "character device"
most devices located in /dev directory
in /dev > ls - l tty* | more
tty = typically terminals (character devices)

b = block device (hardware) .. data is written-to and read-from the hard disk (or floppy disk) one BLOCK at a time.
a FILE exists on the disk that represents the entire hard disk
that file/device can be read-from and written-to .. but only by the operating system (in a complex way)
in /dev directory > "ls -l hd* | more"

p = pipe (communications file)
s = socket (another communications file)

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Aug 1st, 2009 at 4:44pm

MrMagoo wrote on Aug 1st, 2009 at 4:14pm:
You cannot use a hard link because the second drive has its own inodes.

He actually demonstrated this .. inadvertently, by trying to create a hard link to a file on another hard disk.

I think the system looks for the i-node number in its own i-node table (located on its own hard drive), and it will not find the i-node there that has been created and stored on another i-node table (on another hard drive).

But what if the two i-node tables both contain the same i-node number?

And what if the file is located on a different LOGICAL drive,  but on the same PHYSICAL drive? Go? No-go?

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 6:35pm

Rad wrote on Aug 1st, 2009 at 4:44pm:
But what if the two i-node tables both contain the same i-node number?

I think the system sees you are tying to link across devices and warns you.


Rad wrote on Aug 1st, 2009 at 4:44pm:
And what if the file is located on a different LOGICAL drive,but on the same PHYSICAL drive? Go? No-go? 

Logical and physical drives act the exact same way.  Logical drives get their own device and their own inode table, so you can't link across them (with a hard link - sym links work fine.)

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad on Aug 1st, 2009 at 7:48pm
do you ever use telnet?

still useful?

do you subscribe to any of the linux magazines?

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 1st, 2009 at 8:21pm
Hmmm. I tried to connect to the Rad VPS via telnet ("open radified.com" at telnet prompt).

It said I was connected, then (few secs later), it said "Connection closed by foreign host".

Uh?

i never got a login prompt.

no password entered.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 1st, 2009 at 10:48pm
wiredtree sppt basically told me to forget about telnet cuz it is not secure.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 1st, 2009 at 10:57pm
mail

command not found.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 1st, 2009 at 11:48pm

Rad wrote on Aug 1st, 2009 at 7:48pm:
do you ever use telnet?

Yes, but just to check to see if a port is reachable.


Rad wrote on Aug 1st, 2009 at 7:48pm:
still useful?

Barely.  It is not secure in any way, shape, or form and should not be used to do much of anything.

Interesting thing is that many protocols still implement telnet at a low level.  SMTP, for example, is basically a scripted telnet session.  Makes your skin kinda crawl to realize how insecure email is...


Rad.in.UbuntuVM wrote on Aug 1st, 2009 at 8:21pm:
Hmmm. I tried to connect to the Rad VPS via telnet ("open radified.com" at telnet prompt).

Ya, stick to SSH.  Tons of advantages.  Almost no disadvantage.


Rad.in.UbuntuVM wrote on Aug 1st, 2009 at 10:57pm:
mail

command not found. 

Was this on CentOS or Ubuntu?  I'm guessing CentOS from your output.  Mail is pretty basic, and many distros don't include it anymore.  They expect you to forward your mail to somewhere you can get to it from a decent mail client (Thunderbird etc..)

You can try 'yum install mail' if you really want it.


Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 5:40pm

MrMagoo wrote on Aug 1st, 2009 at 11:48pm:
Was this on CentOS or Ubuntu?

CentOS.

I've come to see both mail and telnet as ancient history. My telnet port (23) on Rad VPS was closed. Wiredtree sppt asked if I wanted them to open it. I said 'no'.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 6:35pm
11-02 - Environmental Variables

Many programs use Shell EV's as config options (including the shell)
name=value
name can have no spaces
if value has spaces, it must be enclosed in double quotes
can set new EV's or modify existing EV's
to find value of a given EV: > "echo $variable"
if a blank is returned, ether no such variable or value set to blank
"set" shows ALL EV's
e.g. "set | more"
EV's can usually be found at end of each man page
If you want an EV to be used by a program other than shell, usually have to EXPORT it:
e.g. "export variable" (notice no dollar sign)

Common EV's (Weird that these must be entered as > ALL CAPs)
LINES, COLUMNS, HOME, LOGNAME, PATH, PS1, SHELL, TERM

What's up with the ALL-CAPS? Thot there was something wrong with my system .. til I tried ALL-CAPs.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 3rd, 2009 at 6:36pm

Rad.in.UbuntuVM wrote on Aug 3rd, 2009 at 5:40pm:
I've come to see both mail and telnet as ancient history. My telnet port (23) on Rad VPS was closed. Wiredtree sppt asked if I wanted them to open it. I said 'no'.

Unfortunately, telnet is not ancient history.  Many people still use it for many different things, even though doing so is dangerous.  Good call leaving it closed; you open yourself up to too many potential security issues by using telnet.

Regarding mail, I don't know if your course covered it or not, but your mail is (most often) stored in a text file in /var/spool/mail.  In that directory, there is one file for each user, and all your mail is stored in that text file, each message appended after the other.  It's not pretty, but it is human readable.

Forwarding the mail to somewhere you can read it with a client would be good practice for you in configuring several system options, and seeing what kind of mail the system generates might interest you, but you can also just skim through this text file if you just want to get a general idea what is in there.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 7:17pm
11-03 - Your path

Where the shell looks to find executable utility programs
Typically, the PATH EV contains 5 or 6 directories .. 10 at most.
To add a directory on the end of current $PATH:
e.g. "PATH=$PATH:/home/rad/bin"
$PATH = contents of currently existing PATH variable.
Can also add a directory to the beginning
PATH=.:$PATH (looks in current directory first)
"echo" is part of the shell. It's not a separate execute program stored somewhere.
So echo will always work, even if PATH variable is trashed..
The PATH variable is about convenience. So you don't have to navigate to the directory. Ot type in the the full path name to the program.
Some experienced Unix users create a directory in their home directory, and put their own custom scripts in there, and then add that directory to the PATH variable, so they can run those scripts from anywhere.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 7:37pm
11-04 - Your prompt

PS1 = Environment variable that represents shell prompt
set/change prompt via
e.g. "PS1=Rad" (notice P+S are capital letters)
bash offers dynamic prompt that changes with time.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 3rd, 2009 at 8:38pm

Rad.in.UbuntuVM wrote on Aug 3rd, 2009 at 7:37pm:
bash offers dynamic prompt that changes with time.

Well, more than time, it is usually set to change based on the user you are logged in as, the working directory you're in, and other things to give you feedback about where you are and what the system expects from you.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 8:57pm
11-05 - .profile

Changes made to Environment shell variables (such as PATH & PS1 prompt) are lost upon logout. Changes not permanent.
To make changes permanent .. put changes in .profile (in home directory)
Works for any program at all.
If you can type it on the command line, you can put it in your .profile
.profile is NOT the system-wide profile.
System-wide profile = /etc/profile (runs automatically)
Have to logout and log back in before changes made to .profile will take effect.
Or .. you can run ". .profile" and changes will take effect (be applied) withOUT having to log out & log back in.
.profile for Unix is the same as autoexec.bat for booting into DOS (a set of commands you wish to execute every time something occurs).
.profile is an example of a shell script (a simple shell script) .. a series of commands that are executed by the shell

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 9:14pm
11-06 - Command-line history & editing

Command-line HISTORY = a shell feature .. allows you to re-enter a previous command without having to retype it.
The up-arrow key activates command-line history.
History normally includes last 50 commands.
Left-arrow key allows you to fix a mis-typed character without having to back-space and retype everything.
Regular Bourne shell has no command line history or editing features (at all).
Korn shell trickier to edit command line .. uses commands from vi (Press ESC first to acces )
k (instead of up-arrow key) to go up a line to access previous commands
enter to re-enter the command
Must first set "EDITOR=vi" as environmental variable

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by MrMagoo on Aug 3rd, 2009 at 9:35pm

Rad.in.UbuntuVM wrote on Aug 3rd, 2009 at 9:14pm:
The up-arrow key activates command-line history. 

Also, run the command 'history' to dump the entire history to stdout.  I often pipe it to grep to narrow down the command I'm looking for.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 9:44pm
11-07 - Other Shell Customizations & Options (umask)

Final module for course

umask = specifies shell permissions for all files created by the shell
We use the greater-than sign to create files with the shell.
e.g. "who > wholist.txt"
often "644"
to change:
umask permissions
NOTE: permissions which should be turned OFF (not on)
Regarding umask, 666 is considered full permissions.
So you SUBTRACT from 666 to get new permissions
In other words:
"umask 022" would yield new files with 644 permissions
umask does not consider the 'execute' permission (777)
"umask 606" would yield new files with 060 permissions
If you are frequently changing file permissions chmod, consider changing your umask and putting it in your .profile

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 9:45pm
Done. I did it. Finished.

Title: Re: Using the Unix/Linux Shell Command-line - Part 2
Post by Rad.in.UbuntuVM on Aug 3rd, 2009 at 10:32pm
Looking back, things I found most helpful.

* cd
* up-arrow
* pwd
* understanding absolute vs relative paths
* cp, rm & mv
* .. (parent directory)
* ctrl-d (to quit)

Radified Community Forums » Powered by YaBB 2.4!
YaBB © 2000-2009. All Rights Reserved.