Welcome, Guest. Please Login
 
  HomeHelpSearchLogin FAQ Radified Ghost.Classic Ghost.New Bootable CD Blog  
 
Pages: 1 2 3 
Send Topic Print
Using the Unix/Linux Shell Command-line - Part 2 (Read 45972 times)
Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #15 - 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.
 
WWW  
IP Logged
 

Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #16 - 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
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #17 - 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.
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #18 - 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.
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #19 - 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.
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #20 - 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.
 
WWW  
IP Logged
 

Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #21 - 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.
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #22 - 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.
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #23 - 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)
 
WWW  
IP Logged
 
Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #24 - 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?
 
WWW  
IP Logged
 
MrMagoo
Übermensch
*****
Offline


Resident Linux Guru

Posts: 1026
Phoenix, AZ (USA)


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #25 - 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.)
 
WWW  
IP Logged
 

Rad
Radministrator
*****
Offline


Sufferin' succotash

Posts: 4090
Newport Beach, California


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #26 - Aug 1st, 2009 at 7:48pm
 
do you ever use telnet?

still useful?

do you subscribe to any of the linux magazines?
 
WWW  
IP Logged
 
Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #27 - 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.
 
WWW  
IP Logged
 
Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #28 - Aug 1st, 2009 at 10:48pm
 
wiredtree sppt basically told me to forget about telnet cuz it is not secure.
 
WWW  
IP Logged
 
Rad.in.UbuntuVM
Radmeister
**
Offline


Rad in Ubuntu 9.04 Jaunty
Virtual Machine

Posts: 92


Back to top
Re: Using the Unix/Linux Shell Command-line - Part 2
Reply #29 - Aug 1st, 2009 at 10:57pm
 
mail

command not found.
 
WWW  
IP Logged
 
Pages: 1 2 3 
Send Topic Print