Difference: TWikiBarTalk001 (1 vs. 18)

Revision 1825 Dec 2017 - Main.PauloSantana

Line: 1 to 1
 

Pub Talk Part I


Line: 486 to 486
 $ exit # Ask the check frown
Added:
>
>
next

-- PauloSantana - 25 Dec 2017

 
META FILEATTACHMENT attachment="CamadasDoLinux_ingles.svg" attr="" comment="Linux Layers" date="1364222738" name="CamadasDoLinux_ingles.svg" path="CamadasDoLinux_ingles.svg" size="8879" stream="IO::File=GLOB(0x110dfb0)" tmpFilename="/tmp/XS0mSkbq_9" user="JulioNeves" version="1"
META TOPICMOVED by="JarbasJunior" date="1157129196" from="TWikiBar.TWikiBarPapo012" to="TWikiBar.TWikiBarTalk001"

Revision 1717 Mar 2015 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 426 to 426
 Lets see again the gave example to the backquote in this new point of view:

Changed:
<
<
$ echo There is $(who | grep wc -l) connected users
>
>
$ echo There is $(who | wc -l) connected users
 There is 8 connected users
Line: 485 to 485
 
$ exit # Ask the check frown
Deleted:
<
<
 
META FILEATTACHMENT attachment="CamadasDoLinux_ingles.svg" attr="" comment="Linux Layers" date="1364222738" name="CamadasDoLinux_ingles.svg" path="CamadasDoLinux_ingles.svg" size="8879" stream="IO::File=GLOB(0x110dfb0)" tmpFilename="/tmp/XS0mSkbq_9" user="JulioNeves" version="1"
META TOPICMOVED by="JarbasJunior" date="1157129196" from="TWikiBar.TWikiBarPapo012" to="TWikiBar.TWikiBarTalk001"

Revision 1618 Mar 2014 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I



Added:
>
>
This is a very new translation from Portuguese to English. Please contribute to the development of this site indicating errors and and/or suggesting corrections and materials for this person.
 

Dialog overheard between a Linuxer and a "Mouseoholic"

     - Who's Bash?

Revision 1525 Mar 2013 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 19 to 19
      - To understand Shell and how it works, first of all I'll show you how the layers in the Linux Environment works. Take a look at the graph:

Changed:
<
<
Visão do shell em relação do Kernel do Linux
>
>
Visão do shell em relação do Kernel do Linux
 
Changed:
<
<
In this graph, we can see that the Hardware Layer is in the center and made of the physical components of your computer. Surrounding that we have the Linux Kernel Layer, that is your core. This layer communicates with the hardware, managing and controlling it. The kernel sends programs and commands to the central processing unit (CPU) for execution. Enclosing this, we have the Shell. This name is because it's a wrapper between the User and the Operating System (OS). All User interaction with the OS is managed by the Shell.
>
>
In this graph (design by Cadunico), we can see that the Hardware Layer is in the center and made of the physical components of your computer. Surrounding that we have the Linux Kernel Layer, that is your core. This layer communicates with the hardware, managing and controlling it. The kernel sends Programs and Utilities to the central processing unit (CPU) for execution. Enclosing this, we have the Shell. This name is because it's a wrapper between the User and the Operating System (OS). All User interaction with the OS is managed by the Shell.
 

The Shell Environment

Revision 1425 Mar 2013 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 485 to 485
 
Added:
>
>
META FILEATTACHMENT attachment="CamadasDoLinux_ingles.svg" attr="" comment="Linux Layers" date="1364222738" name="CamadasDoLinux_ingles.svg" path="CamadasDoLinux_ingles.svg" size="8879" stream="IO::File=GLOB(0x110dfb0)" tmpFilename="/tmp/XS0mSkbq_9" user="JulioNeves" version="1"
 
META TOPICMOVED by="JarbasJunior" date="1157129196" from="TWikiBar.TWikiBarPapo012" to="TWikiBar.TWikiBarTalk001"

Revision 1322 Mar 2013 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I



Changed:
<
<
Dialog overheard between a Linuxer and a "Mouseoholic"
>
>

Dialog overheard between a Linuxer and a "Mouseoholic"

       - Who's Bash?

Revision 1214 Feb 2012 - MarioSilva

Line: 1 to 1
 

Pub Talk Part I


Line: 483 to 483
 
$ exit # Ask the check frown
Added:
>
>
 
META TOPICMOVED by="JarbasJunior" date="1157129196" from="TWikiBar.TWikiBarPapo012" to="TWikiBar.TWikiBarTalk001"

Revision 1103 Oct 2007 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 8 to 8
       - Who's Bash?
Changed:
<
<
     - Bash is the newest son of Shell Family
>
>
     - Bash is the newest son of the Shell Family
       - Hey dude! You're gonna drive me crazy. I had one doubt... Now I have two!
Changed:
<
<
     - No, man. It's been a long time you are crazy. Since you decided to use that operating system you need to boot ten times a day and don't have any kind of idea about what's happening in your computer. But, never mind. I'm gonna explain to you what is a Shell and your Family are and, in the end, you'll exclaim: "Holy God of Shell ! Why didn't I choose linux before?"
>
>
     - No, man. It's been a long time you are crazy. Since you decided to use that operating system, you need to boot ten times a day and you don't have any idea what's happening in your computer. But, never mind. I'm gonna explain what a Shell is and what Shell Families are, and in the end, you'll exclaim: "Holy God of Shell ! Why didn't I choose linux before?"
 

The Linux Environment

Line: 22 to 22
 Visão do shell em relação do Kernel do Linux
Changed:
<
<
In this graph, we can see that the Hardware Layer is in the center and made of the physical components of your computer. Surrounding that we have the Linux Kernel Layer, that is your core. This layer makes the hardware work, manages and controls it. The programs and commands that involve the kernel use it to run the jobs they was developed. Enclosing this, we have the Shell, that has this name because it is between the User and the Operating System (OS), managing everything that needs to interact with the OS.
>
>
In this graph, we can see that the Hardware Layer is in the center and made of the physical components of your computer. Surrounding that we have the Linux Kernel Layer, that is your core. This layer communicates with the hardware, managing and controlling it. The kernel sends programs and commands to the central processing unit (CPU) for execution. Enclosing this, we have the Shell. This name is because it's a wrapper between the User and the Operating System (OS). All User interaction with the OS is managed by the Shell.
 

The Shell Environment

Changed:
<
<
Well... as to get the Linux Core, that's the ambition of all applications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us.
>
>
Well... to get to the Linux Core - the ambition of all applications - Shell filtering is needed, Let's understand how it works, to make the most of the numerous tools the Shell provides us.
 
Changed:
<
<
The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the Shell that the user will get at login.
>
>
Linux, by definition, is a multi-user operating system - we can't ever forget this - and to allow the access to specific users and deny others, there is a file called /etc/passwd. The /etc/passwd file holds data for the "host" function and contains information which controls the login of all users of the system. The last field of each user record in /etc/passwd tells the system which Shell the user will get at login.
 
Pinguim com placa de dica (em inglês)
Changed:
<
<
When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.
>
>
Remember, I said that the last field of /etc/passwd tells the system the default user Shell at login? This means, if in this field we have prog, when the user logs in he will have the prog program screen, and when execution of prog finishes, the system will logout the user. Imagine how much security we can implement with this simple tool.
 
Changed:
<
<
Did you remember I told the Shell, family, brother? That's it, lets understand this: the Shell is the concept of the Shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh (Bourne Shell), the ksh (Korn Shell), the Bash (Bourne Again Shell) and the csh (C Shell).
>
>
Do you remember I told the Shell, family, brother? That's it, lets understand this: the Shell is the concept of the Shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh (Bourne Shell), the ksh (Korn Shell), the Bash (Bourne Again Shell) and the csh (C Shell).
 

A Little Bang in the Main Shell Flavors

Line: 46 to 46
  Developed by David Korn, from Bell Labs, is a superset of sh, that means, it has all easinesses of sh and to them agregated many others. The total compatibility with sh brings many users and Shell programers to this environment.
Changed:
<
<

Boune Again Shell (Bash)

>
>

Bourne Again Shell (Bash)

  This is the most modern Shell (excepting on Bash 2) and whose number of adepts is growing more and more in whole world, or because it is the Linux default Shell, or because its big diversity of commands, that also incorporates many C-Shell commands.
Line: 67 to 67
 

Examination of the Command Line

Changed:
<
<
In this examination, the Shell identifies the special (reserved) characters that have meaning for interpretation of the line, and checks if the passed line is an atribuition or a command.
>
>
In this examination, the Shell identifies the special (reserved) characters that have meaning for interpretation of the line, and checks if the passed line is an assignment or a command.
 
Changed:
<
<
Atribuition
>
>
Assignment
 
Changed:
<
<
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
>
>
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an assignment.
 
$ ls linux
Line: 84 to 84
 $ value=1000
Changed:
<
<
In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.
>
>
In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an assignment and put 1000 on variable value.
 
Pinguim com placa de atenção (em inglês) Never do:
Line: 101 to 101
  When a line is typed at linux prompt, she is divided in pieces separeted by blank spaces: the first piece is the name of the program and will have your existence searched; next identifies, in this order, options/parameters, redirects and variables.
When the identified program exists, the Shell verifies the permissions of involved files (including the own program), generating an error if you don't have permissions to run this job.
Changed:
<
<
Redirections Resolution
>
>
Redirection Resolution
 
Changed:
<
<
After identifies the components at command line you typed, the Shell goes to redirections resolution. The Shell has in your advantage issues something we call redirections, that can be input ( stdin ), output ( stdout ) or error ( stderr ), as I´ll explain soon.
>
>
After identifies the components at command line you typed, the Shell goes to redirection resolution. The Shell has in your advantage issues something we call redirection, that can be input (stdin), output (stdout) or error (stderr), as I'll explain soon.
 
Variable Substitutions
Line: 125 to 125
  Completed the previous jobs, the Shell mounts the command line, now with all changes done, call the kernel to execute it in a new Shell (Son Shell), wining a process number called PID (Process IDentification ) and stays inactive, taking a little nap, during the program execution. Once finished this process (together the son Shell), it takes the control again and, showing the prompt, tells it is ready to execute new commands.
Changed:
<
<

Decrypting the Roseta's Stone

>
>

Decrypting the Rosetta Stone

  To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion (make a little research at Google to find out who's this man) decrypting the Roseta's Stone.
Changed:
<
<

Scape Characters

>
>

Escape Characters

  That's it. When we desire Shell to interpret a special character, we must "hide" it from him. This can be done in many ways:
Changed:
<
<
Apostrophe (')
>
>
Single Quotes (')
 
Changed:
<
<
When the Shell see a character chain between apostrophes, he takes of the apostrophes and doesn't interprets its content.
>
>
When the Shell see a character chain between single quotes, he takes of the single quotes and doesn't interprets its content.
 
$ ls linux*
Line: 144 to 144
 bash: linux* no such file or directory
Changed:
<
<
In the first case, Shell "expanded" the asterisk (*) and discovered the file linuxmagazine to list.In the second case, the apostrophes inhibited the Shell interpretation and we got the answer that there is no file linux*. That means, the asterisk (*) was expanded in the first case, but was interpreted as a literal asterisk (*) character in the second case.
>
>
In the first case, Shell "expanded" the asterisk (*) and discovered the file linuxmagazine to list.In the second case, the single quotes inhibited the Shell interpretation and we got the answer that there is no file linux*. That means, the asterisk (*) was expanded in the first case, but was interpreted as a literal asterisk (*) character in the second case.
 
Backslash (\)
Changed:
<
<
At the same way that apostrophes work, backslash (\) inhibities the interpretation only of the character that follows her.
>
>
At the same way that single quotes work, backslash (\) inhibities the interpretation only of the character that follows her.
  Imagine you acidentally had created a file named * (asterisk) - some Unix flavors allow it - and wants to remove it. If you do:
Line: 175 to 175
  Did you see the diferences? So, I don't need to explain nothing more.
Changed:
<
<
Quotation Marks (")
>
>
Double Quotes (")
 
Changed:
<
<
Likelly at apostrophes, excepting if the chain between quotation marks has a dolar ($), a crasis (`) or a backslash (\). You don't need to get stressed, but I didn't give samples of quotation marks use because you don't know the dolar ($) nor the crasis (`). From here, we'll see the use of these special characters too many times. The most important is to understand what any one means.
>
>
Likelly at single quotes, excepting if the chain between double quotes has a dolar ($), a backquote (`) or a backslash (\). You don't need to get stressed, but I didn't give samples of double quotes use because you don't know the dolar ($) nor the backquote (`). From here, we'll see the use of these special characters too many times. The most important is to understand what any one means.
 
Changed:
<
<

Redirect Characters

>
>

Redirection Characters

  The most of commands have an input, an output and can generate errors. This input is called Standard Input or stdin and its default is the terminal keyboard. The output of a command is called Standard Output or stdout and its default is the terminal screen. To the terminal screen also is send by default the error messages that command can generate, called Standard Error or stderr. Let's see now how to change this state of things. Let's do a "parrot program". Do as following:
Line: 219 to 219
  With this, we can notice that >> is used to insert data at the end of file.
Changed:
<
<
Standard Error Output Redirections
>
>
Redirecting Standard Error Output
  As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign (>) there is no blank space.
Line: 275 to 275
  the error message from ls will inserted at the end of errorfile.
Changed:
<
<
Standard Input Redirections
>
>
Redirecting Standard Input
  To do the Standard Input Redirection we use the < (less than).
Line: 317 to 317
       - All right... all right... I know I was babling and walked by ftp commands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...
Changed:
<
<
Command Redirection
>
>
Redirecting Commands (pipes)
  The redirections we told until now always refered to files, that means, they sent things to a file, they got things from a file, they simulated local files. What we'll see from now redirects the output of a command to the input of another.
Line: 338 to 338
 

Environment Characters

Changed:
<
<
When you want to priorize one expression, you put it between parentesis, right? So, because of arithmetic, this is a normal think. But in Shell what really priorizes expressions are the grave (`) and not the parentesis. I'll give you examples of grave uses, to get better understanding.
>
>
When you want to priorize one expression, you put it between parentesis, right? So, because of arithmetic, this is a normal think. But in Shell what really priorizes expressions are the backquote (`) and not the parentesis. I'll give you examples of backquote uses, to get better understanding.
  I want to know how many users are logged in my computer. I can do:
Line: 355 to 355
 There is who | wc -l connected users
Changed:
<
<
What? Look that! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this:
>
>
What? Look that! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of backquote, doing this:
 
$ echo "There is `who | wc -l ` connected users"
Line: 413 to 413
 > END
Changed:
<
<
Finally now we have knowledge to show what we had talk about here document. The commands between grave (`)are priorized and then the Shell will execute then before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment.
>
>
Finally now we have knowledge to show what we had talk about here document. The commands between backquote (`)are priorized and then the Shell will execute then before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment.
  The default Shell primary prompt, as we saw, is the dolar ($), but Shell uses a concept of secondary prompt, or command continue, that is sent to the screen when we have a line feed and the instruction didn't end yet. This prompt is represented as a greather than signal (>), that we see at the beggining of the second line and above.
Changed:
<
<
To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the graves. They are the constructions like $(cmd), where cmd are one or many commands that will be executed with priority in its context.
>
>
To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the backquotes. They are the constructions like $(cmd), where cmd are one or many commands that will be executed with priority in its context.
 
Changed:
<
<
In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all Shell flavoes. Here in the pub, I'll use both ways, with no distiction.
>
>
In this way, the use of backquotes or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of backquotes, as the $(cmd) wasn't ported to all Shell flavoes. Here in the pub, I'll use both ways, with no distiction.
 
Changed:
<
<
Lets see again the gave example to the grave in this new point of view:
>
>
Lets see again the gave example to the backquote in this new point of view:
 
$ echo There is $(who | grep wc -l) connected users
Line: 436 to 436
 ls
Changed:
<
<
In this example, I did an atribuition (=) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the atribuition was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of atribuition and this can be done in any of the following ways:
>
>
In this example, I did an assignment (=) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the assignment was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of assignment and this can be done in any of the following ways:
 
$ Arqs=`ls`

Revision 1026 Sep 2006 - VirenderDogra

Line: 1 to 1
 

Pub Talk Part I



Changed:
<
<
Dialog listened between a Linuxer and a "Mouseoholic"
>
>
Dialog overheard between a Linuxer and a "Mouseoholic"
       - Who's Bash?
Line: 12 to 12
       - Hey dude! You're gonna drive me crazy. I had one doubt... Now I have two!
Changed:
<
<
     - No, man. It's been a long time you are crazy. Since you decided to use that operational system you need to boot ten times a day and don't have any kind of domain about what's happening in your computer. But, never mind. I'm gonna to explain what Shell and your Family are and, in the end, you'll tell: "Holy God of Shell ! Why didn't I choose linux before?"
>
>
     - No, man. It's been a long time you are crazy. Since you decided to use that operating system you need to boot ten times a day and don't have any kind of idea about what's happening in your computer. But, never mind. I'm gonna explain to you what is a Shell and your Family are and, in the end, you'll exclaim: "Holy God of Shell ! Why didn't I choose linux before?"
 

The Linux Environment

Changed:
<
<
     - To understand what is Shell and how it works, first of all I'll show you how the Linux Layers Environment works. Take a look at the graph:
>
>
     - To understand Shell and how it works, first of all I'll show you how the layers in the Linux Environment works. Take a look at the graph:
 
Visão do shell em relação do Kernel do Linux
Changed:
<
<
In this graph, we can see that Hardware Layer is the most deep and made for the phisical components of your computer. Involving that we have the Linux Kernel Layer, that is your core. This layer is responsible to make the hardware work, managing and controlling it. The programs and commands that involve the kernel use it to run the jobs they was developed. Closing this, we have the Shell, that has this name because it is between the User and the Operational System, managing everything that needs to interact with the Operational System.
>
>
In this graph, we can see that the Hardware Layer is in the center and made of the physical components of your computer. Surrounding that we have the Linux Kernel Layer, that is your core. This layer makes the hardware work, manages and controls it. The programs and commands that involve the kernel use it to run the jobs they was developed. Enclosing this, we have the Shell, that has this name because it is between the User and the Operating System (OS), managing everything that needs to interact with the OS.
 

The Shell Environment

Changed:
<
<
Well... as to get the Linux Core, that's the ambition of all aplications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us.
>
>
Well... as to get the Linux Core, that's the ambition of all applications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us.
  The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the Shell that the user will get at login.

Revision 901 Sep 2006 - JarbasJunior

Line: 1 to 1
 

Pub Talk Part I


Line: 483 to 483
 
$ exit # Ask the check frown
Added:
>
>
META TOPICMOVED by="JarbasJunior" date="1157129196" from="TWikiBar.TWikiBarPapo012" to="TWikiBar.TWikiBarTalk001"

Revision 814 Dec 2005 - AurelioAHeckert

Line: 1 to 1
 

Pub Talk Part I


Line: 30 to 30
  The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the Shell that the user will get at login.
Changed:
<
<
%TIPon%
>
>
Pinguim com placa de dica (em inglês)
 When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.
Changed:
<
<
%TIPoff%
>
>
  Did you remember I told the Shell, family, brother? That's it, lets understand this: the Shell is the concept of the Shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh (Bourne Shell), the ksh (Korn Shell), the Bash (Bourne Again Shell) and the csh (C Shell).
Line: 73 to 73
  If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
Changed:
<
<
%TERMINALon% $ ls linux%OUTon% linux%OUToff% %TERMINALoff%
>
>
$ ls linux linux
  In this example, the Shell identified the ls as a program and linux as a parameter passed to ls program.
Changed:
<
<
%TERMINALon%
>
>
 $ value=1000
Changed:
<
<
%TERMINALoff%
>
>
  In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.
Changed:
<
<
%ATTENTIONon%
>
>
Pinguim com placa de atenção (em inglês)
 Never do:
Changed:
<
<
%TERMINALon% $ value = 10000%OUTon% bash: value: not found%OUToff% %TERMINALoff%
>
>
$ value = 10000 bash: value: not found
  Bash found the word value between blanks spaces and "guess" that you were trying to execute a program called value, passing two parameters: != and 1000.
Changed:
<
<
%ATTENTIONoff%
>
>
 
Command
Line: 115 to 115
  Supose that the only file in your actual directory started by T be a directory named ThisIsAVeryHugeNameForADirectoryButIsMyDirectoryName, you can do:
Changed:
<
<
%TERMINALon%
>
>
 $ cd T*
Changed:
<
<
%TERMINALoff%
>
>
  As until here who's working your command line is the Shell and the command (program) cd isn't executed yet, the Shell changes the T* in ThisIsAVeryHugeNameForADirectoryButIsMyDirectoryName and the command cd will be successfully executed.
Line: 137 to 137
  When the Shell see a character chain between apostrophes, he takes of the apostrophes and doesn't interprets its content.
Changed:
<
<
%TERMINALon% $ ls linux*%OUTon% linuxmagazine%OUToff% $ ls 'linux*'%OUTon% bash: linux* no such file or directory%OUToff% %TERMINALoff%
>
>
$ ls linux* linuxmagazine $ ls 'linux*' bash: linux* no such file or directory
  In the first case, Shell "expanded" the asterisk (*) and discovered the file linuxmagazine to list.In the second case, the apostrophes inhibited the Shell interpretation and we got the answer that there is no file linux*. That means, the asterisk (*) was expanded in the first case, but was interpreted as a literal asterisk (*) character in the second case.
Line: 152 to 152
  Imagine you acidentally had created a file named * (asterisk) - some Unix flavors allow it - and wants to remove it. If you do:
Changed:
<
<
%TERMINALon%
>
>
 $ rm *
Changed:
<
<
%TERMINALoff%
>
>
  You will doing a big mess, because the rm would erase all files in the current directory. The best way to do this is:
Changed:
<
<
%TERMINALon%
>
>
 $ rm \*
Changed:
<
<
%TERMINALoff%
>
>
  In this way, Shell didn't interpretate the asteristiks, doing its expansion.

Do the following cientific experience:

Changed:
<
<
%TERMINALon%
>
>
 $ cd /etc $ echo '*' $ echo \* $ echo *
Changed:
<
<
%TERMINALoff%
>
>
  Did you see the diferences? So, I don't need to explain nothing more.
Line: 183 to 183
  The most of commands have an input, an output and can generate errors. This input is called Standard Input or stdin and its default is the terminal keyboard. The output of a command is called Standard Output or stdout and its default is the terminal screen. To the terminal screen also is send by default the error messages that command can generate, called Standard Error or stderr. Let's see now how to change this state of things. Let's do a "parrot program". Do as following:
Changed:
<
<
%TERMINALon%
>
>
 $ cat
Changed:
<
<
%TERMINALoff%
>
>
  The cat is an instruction that lists the contents of a specific file to the standard output (stdout). If this input aren't defined, he waits the data from standard input (stdin). As I didn't specify the input, he's waiting it from keyboard (standard input) and, as I also didn't tell the output, what I type will go to the screen (standard output), doing this way, as I was proposed, a "parrot program". Try it !
Line: 195 to 195
  Lets change the "parrot program" onto a "text editor" (how pretensious, hu ?).
Changed:
<
<
%TERMINALon%
>
>
 $ cat > Arq
Changed:
<
<
%TERMINALoff%
>
>
  The cat continues without the specified input, so is waiting for data typed, but your output is redirected to the file Arq. In this way, everything typed is going to inside the Arq file, that means we did the shorter and whorst text editor of entire planet.

If I do again:

Changed:
<
<
%TERMINALon%
>
>
 $ cat > Arq
Changed:
<
<
%TERMINALoff%
>
>
  The data in Arq will be lost, as before the redirecting the Shell will create an empty Arq file. To put information at the end of file, it should be done:
Changed:
<
<
%TERMINALon%
>
>
 $ cat >> Arq
Changed:
<
<
%TERMINALoff%
>
>
 
Changed:
<
<
%ATTENTIONon%
>
>
Pinguim com placa de atenção (em inglês)
 As I already told you, the Shell resolves the line and after send the command to execution. Thus, if you redirect the output of a file to itself, first the Shell empty the file and after send the command to execution. In this way, you just lost your dear file.
Changed:
<
<
%ATTENTIONoff%
>
>
  With this, we can notice that >> is used to insert data at the end of file.
Line: 223 to 223
  As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign (>) there is no blank space.
Changed:
<
<
%ATTENTIONon%
>
>
Pinguim com placa de atenção (em inglês)
 Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt (stderr) to the specified file. This is important!
Changed:
<
<
%ATTENTIONoff%
>
>
  Supose that, during a script execution you can, or not (it depends of the way the program execution takes), created a file named /tmp/IsThisExisting$$. To erase trash from your disc, at the end of the script you could put a line like:
Changed:
<
<
%TERMINALon%
>
>
 rm /tmp/IsThisExisting$$
Changed:
<
<
%TERMINALoff%
>
>
  If the file doesn't exist, an error message will be send to the screen. To not allow this, you should do:
Changed:
<
<
%TERMINALon%
>
>
 rm /tmp/IsThisExisting$$ 2> /dev/null
Changed:
<
<
%TERMINALoff%
>
>
  About the example we just saw, I have two tips:
Changed:
<
<
%TIPon%
>
>
Pinguim com placa de dica (em inglês)
 TIP # 1

The $$ has the PID, this means, the Process IDentification. As Linux is a multi-user system, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as IsThisExist, the first user (the creator, then) will be your owner and all others will have a permission error when tried to write something in the file.

Changed:
<
<
%TIPoff%
>
>
  To test you Standard Error Output at Shell prompt, I'll give one example. Do:
Changed:
<
<
%TERMINALon% $ ls donotexist%OUTon% bash: donotexist no such file or directory%OUToff%
>
>
$ ls donotexist bash: donotexist no such file or directory
 $ ls donotexist 2> errorfile
Changed:
<
<
$ cat errofile%OUTon% bash: donotexist no such file or directory%OUToff% %TERMINALoff%
>
>
$ cat errofile bash: donotexist no such file or directory
  In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the Shell prompt back. When listing the errorfile, we saw the error message was stored in it. Do the same test.
Changed:
<
<
%TIPon%
>
>
Pinguim com placa de dica (em inglês)
 TIP # 2

     - Who's the hell of /dev/null?

     - In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file disapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file.

Changed:
<
<
%TIPoff%
>
>
  It is good to notice that those redirecting characters are cumulatives, this means, if in the previous example we did:
Changed:
<
<
%TERMINALon%
>
>
 $ ls donotexist 2>> errorfile
Changed:
<
<
%TERMINALoff%
>
>
  the error message from ls will inserted at the end of errorfile.
Line: 285 to 285
  Supose taht you want to send an e-mail to your boss. To the Boss, we always whim, right? So, instead of start typing the e-mail at the prompt that makes the correction of a previous phrase impossible, you write a file with the message and after ten checks without see any error, you decide to send it, and do:
Changed:
<
<
%TERMINALon%
>
>
 $ mail boss < filewithmailtotheboss
Changed:
<
<
%TERMINALoff%
>
>
  Your boss will receive the text in the filewithmailtotheboss.
Line: 311 to 311
 
  1. The binary is another ftp instruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc;
  2. The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.
Changed:
<
<
%ATTENTIONon%
>
>
Pinguim com placa de atenção (em inglês)
 A very frequent error in the labels use (as the endftp in our previous example) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her.
Changed:
<
<
%ATTENTIONoff%
>
>
       - All right... all right... I know I was babling and walked by ftp commands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...
Line: 323 to 323
  This is very usefull and make lots of things easy. You name is pipe and acts as a pipe between two commands, or in other words, acts pipeing information from one command to another. Your representation is a vertical bar (|).
Changed:
<
<
%TERMINALon% $ ls | wc -l%OUTon% 21%OUToff% %TERMINALoff%
>
>
$ ls | wc -l 21
  The ls command passed the file list to the wc command, that when it has the option -l counts the lines received. Using this, we can say how many files we have in our directory (21 in this case).
Changed:
<
<
%TERMINALon%
>
>
 $ cat /etc/passwd | sort | lp
Changed:
<
<
%TERMINALoff%
>
>
  This command line sends contents of /etc/passwd file to the sort command input. This command classifies it and sends to lp, that is our printer spool manager.
Line: 342 to 342
  I want to know how many users are logged in my computer. I can do:
Changed:
<
<
%TERMINALon%
>
>
 $ who | wc -l
Changed:
<
<
%TERMINALoff%
>
>
  The who command sends the connected users list to the command wc -l that counts how many lines it received and shows the answer in the terminal. So, if we want to have more than a number alone in the screen, what I want is that is stays in the middle of a phrase.

To send phrases to the screen I use the echo command. So let see how it works:

Changed:
<
<
%TERMINALon% $ echo "There is who | wc -l connected users"%OUTon% There is who | wc -l connected users%OUToff% %TERMINALoff%
>
>
$ echo "There is who | wc -l connected users" There is who | wc -l connected users
  What? Look that! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this:

Changed:
<
<
%TERMINALon% $ echo "There is `who | wc -l ` connected users"%OUTon% There is 8 connected users%OUToff% %TERMINALoff%
>
>
$ echo "There is `who | wc -l ` connected users" There is 8 connected users
  To remove those blank spaces before 8 that wc -l produced, we just need to remove quotations. Like this:

Changed:
<
<
%TERMINALon% $ echo There is `who | wc -l ` connected users%OUTon% There is 8 connected users%OUToff% %TERMINALoff%
>
>
$ echo There is `who | wc -l ` connected users There is 8 connected users
  As I said, the quotation marks protect everything that is inside your limits from Shell interpretation. As to the Shell a single blank space as separator is enought, the extra spaces will be changed by an only one after we remove the quotation marks.

Before tell about parentesis use, let me give a little bang about the semi-collon (;) use. When you are in the Shell, you must always give only one command in each line. To group commands at the same line, we need to separate ir by semi-collon (;). So:

Changed:
<
<
%TERMINALon% $ pwd ; cd /etc; pwd; cd -; pwd%OUTon%
>
>
$ pwd ; cd /etc; pwd; cd -; pwd
 /home/mydir /etc/
Changed:
<
<
/home/mydir%OUToff% %TERMINALoff%
>
>
/home/mydir
  At this example, I listed the name of current directory with pwd command, changed to the /etc directory, again listed the directory name and finally back to the previous directory (cd -), listing its name. Note that I put the semi-collon (;) in all possible ways, to show that don't mind if there is blank spaces before or after this character.

Finally, lets see the parentesis case. Take a look at the following case, likelly the previous example:

Changed:
<
<
%TERMINALon% $ (pwd ; cd /etc ; pwd;)%OUTon%
>
>
$ (pwd ; cd /etc ; pwd;)
 /home/mydir
Changed:
<
<
/etc/%OUToff% $ pwd%OUTon% /home/mydir%OUToff% %TERMINALoff%
>
>
/etc/ $ pwd /home/mydir
       - What the heck? I was in /home/mydir, changed to /etc, check that I really was in this directory with the pwd and, when the command group finished, I saw I was at the /etc/mydir, as if I never had out of there!
Line: 400 to 400
  Now we already know these concepts, take a lookt at the following example:
Changed:
<
<
%TERMINALon% $ mail support << END%OUTon% >%OUToff% Hi support, today at `date"+%hh:mm"`%OUTon% >%OUToff% we had that problem again%OUTon% >%OUToff% that I was reported by%OUTon% >%OUToff% phone. As you ask%OUTon% >%OUToff% here it goes a file list from %OUTon% >%OUToff% the directory:%OUTon% >%OUToff% `ls -l`%OUTon% >%OUToff% Best Reggards.%OUTon% >%OUToff% END %TERMINALoff%
>
>
$ mail support << END > Hi support, today at `date"+%hh:mm"` > we had that problem again > that I was reported by > phone. As you ask > here it goes a file list from > the directory: > `ls -l` > Best Reggards. > END
  Finally now we have knowledge to show what we had talk about here document. The commands between grave (`)are priorized and then the Shell will execute then before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment.
Line: 423 to 423
  Lets see again the gave example to the grave in this new point of view:
Changed:
<
<
%TERMINALon% $ echo There is $(who | grep wc -l) connected users%OUTon% There is 8 connected users%OUToff% %TERMINALoff%
>
>
$ echo There is $(who | grep wc -l) connected users There is 8 connected users
  Take a look at this case:
Changed:
<
<
%TERMINALon%
>
>
 $ Arqs=ls
Changed:
<
<
$ echo $Arqs%OUTon% ls%OUToff% %TERMINALoff%
>
>
$ echo $Arqs ls
  In this example, I did an atribuition (=) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the atribuition was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of atribuition and this can be done in any of the following ways:
Changed:
<
<
%TERMINALon%
>
>
 $ Arqs=`ls`
Changed:
<
<
%TERMINALoff%
>
>
  or:
Changed:
<
<
%TERMINALon%
>
>
 $ Arqs=$(ls)
Changed:
<
<
%TERMINALoff%
>
>
  To finish this topic, let see only one example. Say I'd want to put into the variable $Arqs the long list (ls -l) of all files started by arq and followed by a single character (?). I should do:
Changed:
<
<
%TERMINALon%
>
>
 $ Arqs=$(ls -l arq?)
Changed:
<
<
%TERMINALoff%
>
>
  or:
Changed:
<
<
%TERMINALon%
>
>
 $ Arqs=`ls -l arq?`
Changed:
<
<
%TERMINALoff%
>
>
  But, look at this:
Changed:
<
<
%TERMINALon% $ echo $Arqs%OUTon% -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql%OUToff% %TERMINALoff%
>
>
$ echo $Arqs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql
       - Wow! Everything messed!

     - As I told you man, if you let the Shell "see" the blank spaces, always we have many blank spaces together, they will be changed by only one. To see a cute list, we need to protect the variable from Shell interpretation, like this:

Changed:
<
<
%TERMINALon% $ echo "$Arqs"%OUTon%
>
>
$ echo "$Arqs"
 -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2
Changed:
<
<
-rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql%OUToff% %TERMINALoff%
>
>
-rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql
       - Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting: in Shell, the hash (#) is used to do a comment.
Changed:
<
<
%TERMINALon%
>
>
 $ exit # Ask the check frown
Changed:
<
<
%TERMINALoff%
>
>

Revision 714 Nov 2005 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 30 to 30
  The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the Shell that the user will get at login.
Added:
>
>
%TIPon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %TIPoff%
 Did you remember I told the Shell, family, brother? That's it, lets understand this: the Shell is the concept of the Shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh (Bourne Shell), the ksh (Korn Shell), the Bash (Bourne Again Shell) and the csh (C Shell).

A Little Bang in the Main Shell Flavors

Line: 52 to 56
  There are some other Shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.
Deleted:
<
<
%DICASon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %DICASoff%
 

Explaining Shell Work

The Shell is the first program you have when you make login at Linux. He will solve lots of things in order to not burden Kernel with repetitive tasks, alliviating him to take care about more noble tasks. As each user has your own Shell interposed between him and Linux, is the Shell that will interpret the commands that are typed and checks its syntax, passing it clean to execution.

Line: 86 to 86
  In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.
Changed:
<
<
%ATENCAOon%
>
>
%ATTENTIONon%
 Never do:

%TERMINALon%

Line: 95 to 95
 %TERMINALoff%

Bash found the word value between blanks spaces and "guess" that you were trying to execute a program called value, passing two parameters: != and 1000.

Changed:
<
<
%ATENCAOoff%
>
>
%ATTENTIONoff%
 
Command
Line: 213 to 213
 $ cat >> Arq %TERMINALoff%
Changed:
<
<
%ATENCAOon%
>
>
%ATTENTIONon%
 As I already told you, the Shell resolves the line and after send the command to execution. Thus, if you redirect the output of a file to itself, first the Shell empty the file and after send the command to execution. In this way, you just lost your dear file.
Changed:
<
<
%ATENCAOoff%
>
>
%ATTENTIONoff%
  With this, we can notice that >> is used to insert data at the end of file.
Line: 223 to 223
  As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign (>) there is no blank space.
Changed:
<
<
%ATENCAOon%
>
>
%ATTENTIONon%
 Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt (stderr) to the specified file. This is important!
Changed:
<
<
%ATENCAOoff%
>
>
%ATTENTIONoff%
  Supose that, during a script execution you can, or not (it depends of the way the program execution takes), created a file named /tmp/IsThisExisting$$. To erase trash from your disc, at the end of the script you could put a line like:
Line: 241 to 241
  About the example we just saw, I have two tips:
Changed:
<
<
%DICAon%
>
>
%TIPon%
 TIP # 1

The $$ has the PID, this means, the Process IDentification. As Linux is a multi-user system, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as IsThisExist, the first user (the creator, then) will be your owner and all others will have a permission error when tried to write something in the file.

Changed:
<
<
%DICAoff%
>
>
%TIPoff%
  To test you Standard Error Output at Shell prompt, I'll give one example. Do:
Line: 259 to 259
  In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the Shell prompt back. When listing the errorfile, we saw the error message was stored in it. Do the same test.
Changed:
<
<
%DICAon%
>
>
%TIPon%
 TIP # 2

     - Who's the hell of /dev/null?

     - In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file disapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file.

Changed:
<
<
%DICAoff%
>
>
%TIPoff%
  It is good to notice that those redirecting characters are cumulatives, this means, if in the previous example we did:
Line: 311 to 311
 
  1. The binary is another ftp instruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc;
  2. The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.
Changed:
<
<
%ATENCAOon%
>
>
%ATTENTIONon%
 A very frequent error in the labels use (as the endftp in our previous example) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her.
Changed:
<
<
%ATENCAOoff%
>
>
%ATTENTIONoff%
       - All right... all right... I know I was babling and walked by ftp commands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...
Line: 478 to 478
 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql%OUToff% %TERMINALoff%
Changed:
<
<
     - Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting: in Shell, the Hash (#) is used to do a comment.
>
>
     - Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting: in Shell, the hash (#) is used to do a comment.
  %TERMINALon% $ exit # Ask the check frown

Revision 613 Nov 2005 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 53 to 53
 There are some other Shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.

%DICASon%

Changed:
<
<
When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.
>
>
When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.
 %DICASoff%

Explaining Shell Work

Line: 71 to 71
 
Atribuition
Changed:
<
<
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
>
>
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
  %TERMINALon% $ ls linux%OUTon%
Line: 84 to 84
 $ value=1000 %TERMINALoff%
Changed:
<
<
In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.
>
>
In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.
  %ATENCAOon% Never do:

Revision 512 Nov 2005 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 19 to 19
      - To understand what is Shell and how it works, first of all I'll show you how the Linux Layers Environment works. Take a look at the graph:

Changed:
<
<
Visão do shell em relação do Kernel do Linux
>
>
Visão do shell em relação do Kernel do Linux
 

In this graph, we can see that Hardware Layer is the most deep and made for the phisical components of your computer. Involving that we have the Linux Kernel Layer, that is your core. This layer is responsible to make the hardware work, managing and controlling it. The programs and commands that involve the kernel use it to run the jobs they was developed. Closing this, we have the Shell, that has this name because it is between the User and the Operational System, managing everything that needs to interact with the Operational System.

Line: 52 to 52
  There are some other Shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.
Changed:
<
<
%ATENCAOon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %ATENCAOoff%
>
>
%DICASon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %DICASoff%
 

Explaining Shell Work

Line: 71 to 71
 
Atribuition
Changed:
<
<
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
>
>
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
  %TERMINALon% $ ls linux%OUTon%
Line: 127 to 127
 

Decrypting the Roseta's Stone

Changed:
<
<
To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion (why don't you google him?) decrypting the Roseta's Stone.
>
>
To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion (make a little research at Google to find out who's this man) decrypting the Roseta's Stone.
 

Scape Characters

Revision 412 Nov 2005 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 52 to 52
  There are some other Shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.
Changed:
<
<
%DICASon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %DICASoff%
>
>
%ATENCAOon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %ATENCAOoff%
 

Explaining Shell Work

Line: 71 to 71
 
Atribuition
Changed:
<
<
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
>
>
If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
  %TERMINALon% $ ls linux%OUTon%
Line: 127 to 127
 

Decrypting the Roseta's Stone

Changed:
<
<
To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion (make a little research at Google to find out who's this man) decrypting the Roseta's Stone.
>
>
To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion (why don't you google him?) decrypting the Roseta's Stone.
 

Scape Characters

Revision 312 Nov 2005 - JulioNeves

Line: 1 to 1
 

Pub Talk Part I


Line: 213 to 213
 $ cat >> Arq %TERMINALoff%
Changed:
<
<
%ATENTIONon%
>
>
%ATENCAOon%
 As I already told you, the Shell resolves the line and after send the command to execution. Thus, if you redirect the output of a file to itself, first the Shell empty the file and after send the command to execution. In this way, you just lost your dear file.
Changed:
<
<
%ATENTIONoff%
>
>
%ATENCAOoff%
  With this, we can notice that >> is used to insert data at the end of file.
Line: 223 to 223
  As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign (>) there is no blank space.
Changed:
<
<
%ATENTIONon%
>
>
%ATENCAOon%
 Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt (stderr) to the specified file. This is important!
Changed:
<
<
%ATENTIONoff%
>
>
%ATENCAOoff%
  Supose that, during a script execution you can, or not (it depends of the way the program execution takes), created a file named /tmp/IsThisExisting$$. To erase trash from your disc, at the end of the script you could put a line like:
Line: 241 to 241
  About the example we just saw, I have two tips:
Changed:
<
<
CTIP # 1 - The $$ has the PID, this means, the Process IDentification. As Linux is a multi-user system, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as IsThisExist?, the first user (the creator, then) will be your owner and all others will have a permission error when tried to write something in the file. %ATENTIONon%
>
>
%DICAon% TIP # 1

The $$ has the PID, this means, the Process IDentification. As Linux is a multi-user system, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as IsThisExist, the first user (the creator, then) will be your owner and all others will have a permission error when tried to write something in the file. %DICAoff%

  To test you Standard Error Output at Shell prompt, I'll give one example. Do:
Changed:
<
<
$ ls donotexist bash: donotexist no such file or directory
>
>
%TERMINALon% $ ls donotexist%OUTon% bash: donotexist no such file or directory%OUToff%
 $ ls donotexist 2> errorfile
Changed:
<
<
$ cat errofile bash: donotexist no such file or directory In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the Shell prompt back. When listing the erro messagem file, we saw the error message was stored in it. Do the same test. TIP # 2 - Who's the hell of/dev/null? In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file desapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file.
>
>
$ cat errofile%OUTon% bash: donotexist no such file or directory%OUToff% %TERMINALoff%

In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the Shell prompt back. When listing the errorfile, we saw the error message was stored in it. Do the same test.

%DICAon% TIP # 2

     - Who's the hell of /dev/null?

     - In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file disapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file. %DICAoff%

 It is good to notice that those redirecting characters are cumulatives, this means, if in the previous example we did:
Added:
>
>
%TERMINALon%
 $ ls donotexist 2>> errorfile
Changed:
<
<
the error message from ls will inserted at the end of errorfile. Standard Input Redirections To do the Standard Input Redirection we use the < ( less than ). And this is used for what, you'll ask me. You'll understand too fast. Let me show you an example.
>
>
%TERMINALoff%

the error message from ls will inserted at the end of errorfile.

Standard Input Redirections

To do the Standard Input Redirection we use the < (less than).

     - And this is used for what, you'll ask me.

     - You'll understand too fast. Let me show you an example.

 Supose taht you want to send an e-mail to your boss. To the Boss, we always whim, right ? So, instead of start typing the e-mail at the prompt that makes the correction of a previous phrase impossible, you write a file with the message and after ten checks without see any error, you decide to send it, and do:
Added:
>
>
%TERMINALon%
 $ mail boss < filewithmailtotheboss
Added:
>
>
%TERMINALoff%
 Your boss will receive the text in the filewithmailtotheboss.
Changed:
<
<
Another type of very crazy redirection Shell allows is called here document. He's represented by << (less than, less than) and indicates to the Shell that the command escope begins at the next line and ends when found a line that contains only the label that follow the sign <<. See the following script, with a ftp routine:
>
>
Another type of very crazy redirection Shell allows is called here document. He's represented by << (less than, less than) and indicates to the Shell that the command escope begins at the next line and ends when found a line that contains only the label that follow the sign <<.

See the following script, with a ftp routine:

 ftp -ivn remotehost <<endftp user $USER $PASSWD binary get remotefile endftp
Added:
>
>
 This little portion of code we have lots of interesting details:
Changed:
<
<
1.The options I used to ftp ( -ivn ) are used to it list everything is happening ( -v from verbose ), to not ask if you really want to get the file ( -i from interactive ) and, last but not least, to doesn't require user and password, ( -n ), because these parameters will be informed by the specified instruction user; 2.When I used the << endftp, I was telling the following: "Listen to me, Shell. Do not mess with nothing from here until find the label endftp. You didn't understand anything, as they are ftp specific instructions". If this was the end, it would be simple, but following the example, we can see that there are two variables ( $USER and $PASSWD ), that the Shell will interpret before the redirection. But the great advantage of this kind of construction is that it allows to commands be interpreted inside the here document escope, that opposes what I just said. Soon I'll explain how this thing works. Now we can't, because you don't know all the tools; 3.The command user is a ftp command and is used to pass user and password that were read in a previous routine and inserted in our two variables: $USER and $PASSWD; 4.The binary is another ftpinstruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc; 5.The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put. A very frequent error in the labels use ( as the endftp in our previous example ) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her. All right... all right... I know I was babling and walked by ftpcommands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach... Command Redirection The redirections we told until now always refered to files, that means, they sent things to a file, they got things from a file, they simulated local files. What we'll see from now redirects the output of a command to the input of another. This is very usefull and make lots of things easy. You name is pipe and acts as a pipe between two commands, or in other words, acts pipeing information from one command to another. Your representation is a vertical bar ( | ). $ ls | wc -l The lscommand passed the file list to the wccommand, that when it has the option -l counts the lines received. Using this, we can say how many files we have in our directory.
>
>
  1. The options I used to ftp (-ivn) are used to it list everything is happening (-v from verbose), to not ask if you really want to get the file (-i from interactive) and, last but not least, to doesn't require user and password, (-n), because these parameters will be informed by the specified instruction user;
  2. When I used the << endftp, I was telling the following:
    "Listen to me, Shell. Do not mess with nothing from here until find the label endftp. You didn't understand anything, as they are ftp specific instructions".
    If this was the end, it would be simple, but following the example, we can see that there are two variables ($USER and $PASSWD), that the Shell will interpret before the redirection. But the great advantage of this kind of construction is that it allows to commands be interpreted inside the here document escope, that opposes what I just said. Soon I'll explain how this thing works. Now we can't, because you don't know all the tools;
  3. The command user is a ftp command and is used to pass user and password that were read in a previous routine and inserted in our two variables: $USER and $PASSWD;
  4. The binary is another ftp instruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc;
  5. The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.

%ATENCAOon% A very frequent error in the labels use (as the endftp in our previous example) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her. %ATENCAOoff%

     - All right... all right... I know I was babling and walked by ftp commands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...

Command Redirection

The redirections we told until now always refered to files, that means, they sent things to a file, they got things from a file, they simulated local files. What we'll see from now redirects the output of a command to the input of another.

This is very usefull and make lots of things easy. You name is pipe and acts as a pipe between two commands, or in other words, acts pipeing information from one command to another. Your representation is a vertical bar (|).

%TERMINALon% $ ls | wc -l%OUTon% 21%OUToff% %TERMINALoff%

The ls command passed the file list to the wc command, that when it has the option -l counts the lines received. Using this, we can say how many files we have in our directory (21 in this case).

%TERMINALon%

 $ cat /etc/passwd |sort | lp
Changed:
<
<
This command line sends contents of /etc/passwd file to the sort command input. This command classifies it and sends to lp, that is our printer spool manager. Environment Characters When you want to priorize one expression, you put it between parentesis, right ? So, because of arithmetic, this is a normal think. But in Shell what really priorizes expressions are the grave ( ` ) and not the parentesis. I'll give you examples of grave uses, to get better understanding.
>
>
%TERMINALoff%

This command line sends contents of /etc/passwd file to the sort command input. This command classifies it and sends to lp, that is our printer spool manager.

Environment Characters

When you want to priorize one expression, you put it between parentesis, right? So, because of arithmetic, this is a normal think. But in Shell what really priorizes expressions are the grave (`) and not the parentesis. I'll give you examples of grave uses, to get better understanding.

 I want to know how many users are logged in my computer. I can do:
Added:
>
>
%TERMINALon%
 $ who | wc -l
Changed:
<
<
The who command sends the connected users list to the command wc -l that counts how many lines it received and shows the answer in the termina. So, if we want to have more than a number alone in the screen, what I want is that is stays in the middle of a phrase. To send phrases to the screen I use the echo command. So let see how it works: $ echo "There is who | wc -l connected users" There is who | wc -l connected users What ? Look that ! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this: $ echo "There is `who | wc -l ` connected users"

There is 8 connected users

To remove those blank spaces before 8 that wc -l produced, we just need to remove quotations. Like this: $ echo There is `who | wc -l ` connected users There is 8 connected users As I said, the quotation marks protect everything that is inside your limits from Shell interpretation. As to the Shell a single blank space as separator is enought, the extra spcaes will be changed by an only one after we remove the quotation marks. Before tell about parentesis use, let me give a little bang about the semi-collon ( ; ) use. When you are in the Shell, you must always give only one command in each line. To group commands at the same line, we need to separate ir by semi-collon. So: $ pwd ; cd /etc; pwd; cd -; pwd

>
>
%TERMINALoff%

The who command sends the connected users list to the command wc -l that counts how many lines it received and shows the answer in the terminal. So, if we want to have more than a number alone in the screen, what I want is that is stays in the middle of a phrase.

To send phrases to the screen I use the echo command. So let see how it works:

%TERMINALon% $ echo "There is who | wc -l connected users"%OUTon% There is who | wc -l connected users%OUToff% %TERMINALoff%

What? Look that! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this:

%TERMINALon% $ echo "There is `who | wc -l ` connected users"%OUTon% There is 8 connected users%OUToff% %TERMINALoff%

To remove those blank spaces before 8 that wc -l produced, we just need to remove quotations. Like this:

%TERMINALon% $ echo There is `who | wc -l ` connected users%OUTon% There is 8 connected users%OUToff% %TERMINALoff%

As I said, the quotation marks protect everything that is inside your limits from Shell interpretation. As to the Shell a single blank space as separator is enought, the extra spaces will be changed by an only one after we remove the quotation marks.

Before tell about parentesis use, let me give a little bang about the semi-collon (;) use. When you are in the Shell, you must always give only one command in each line. To group commands at the same line, we need to separate ir by semi-collon (;). So:

%TERMINALon% $ pwd ; cd /etc; pwd; cd -; pwd%OUTon%

 /home/mydir /etc/
Changed:
<
<
/home/mydir At this example, I listed the name of current directory with pwdcommand, changed to the /etc directory, again listed the directory name and finally back to the previous directory ( cd - ), listing its name. Note that I put the semi-collon ( ; ) in all possible ways, to show that don't mind if there is blank spaces before or after this character.
>
>
/home/mydir%OUToff% %TERMINALoff%

At this example, I listed the name of current directory with pwd command, changed to the /etc directory, again listed the directory name and finally back to the previous directory (cd -), listing its name. Note that I put the semi-collon (;) in all possible ways, to show that don't mind if there is blank spaces before or after this character.

 Finally, lets see the parentesis case. Take a look at the following case, likelly the previous example:
Changed:
<
<
$ (pwd ; cd /etc ; pwd;) /home/mydir /etc/ $ pwd
>
>
%TERMINALon% $ (pwd ; cd /etc ; pwd;)%OUTon%
 /home/mydir
Changed:
<
<
What the heck ? I was in /home/mydir, changed to /etc, check that I really was in this directory with the pwd and, when the command group finished, I saw I was at the /etc/mydir, as if I never had out of there ! - Oh crap. It's a kind of magic ! - Are you crazy, man ? Of course not ! The interesting in the parentesis use is that it calls a new Shell to execute the commands inside them. In this way, we really gone to /etc directory, but when all parentesis commands were executed, the new Shell that was at /etc directory died and we came back to the previous Shell which our current directory as /home/mydir. Do other tests using cd and ls to fix the concepts.
>
>
/etc/%OUToff% $ pwd%OUTon% /home/mydir%OUToff% %TERMINALoff%

     - What the heck? I was in /home/mydir, changed to /etc, check that I really was in this directory with the pwd and, when the command group finished, I saw I was at the /etc/mydir, as if I never had out of there!

     - Oh crap. It's a kind of magic !

     - Are you crazy, man? Of course not! The interesting in the parentesis use is that it calls a new Shell to execute the commands inside them. In this way, we really gone to /etc directory, but when all parentesis commands were executed, the new Shell that was at /etc directory died and we came back to the previous Shell which our current directory as /home/mydir. Do other tests using cd and ls to fix the concepts.

 Now we already know these concepts, take a lookt at the following example:
Changed:
<
<
$ mail support << END >Hi support, today at `date"+%hh:mm"`
>we had that problem again
>that I was reported by
>phone. As you ask
>here it goes a file list from
>the directory:
>`ls -l`
>Best Reggards.
>END
Finally now we have knowledge to show what we had talk about here document. The commands between grave are priorized and then the Shell will execute them before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment. The default Shell primary prompt, as we saw, is the dolar ( $ ), but Shell uses a concept of secondary prompt, or command continue, that is sent to the screen when we have a line feed and the instruction didn't end yet. This prompt is represented as a greather than signal ( > ), that we see at the beggining of the second line and above. To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the graves. They are the constructions like $(cmd>), where cmd are one or many commands that will be executed with priority in its context. In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all Shell flavoes. Here in the pub, I'll use both ways, with no distiction.
>
>
%TERMINALon% $ mail support << END%OUTon% >%OUToff% Hi support, today at `date"+%hh:mm"`%OUTon% >%OUToff% we had that problem again%OUTon% >%OUToff% that I was reported by%OUTon% >%OUToff% phone. As you ask%OUTon% >%OUToff% here it goes a file list from %OUTon% >%OUToff% the directory:%OUTon% >%OUToff% `ls -l`%OUTon% >%OUToff% Best Reggards.%OUTon% >%OUToff% END %TERMINALoff%

Finally now we have knowledge to show what we had talk about here document. The commands between grave (`)are priorized and then the Shell will execute then before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment.

The default Shell primary prompt, as we saw, is the dolar ($), but Shell uses a concept of secondary prompt, or command continue, that is sent to the screen when we have a line feed and the instruction didn't end yet. This prompt is represented as a greather than signal (>), that we see at the beggining of the second line and above.

To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the graves. They are the constructions like $(cmd), where cmd are one or many commands that will be executed with priority in its context.

In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all Shell flavoes. Here in the pub, I'll use both ways, with no distiction.

 Lets see again the gave example to the grave in this new point of view:
Changed:
<
<
$ echo There is $(who | grep wc -l) connected users There is 8 connected users
>
>
%TERMINALon% $ echo There is $(who | grep wc -l) connected users%OUTon% There is 8 connected users%OUToff% %TERMINALoff%
 Take a look at this case:
Added:
>
>
%TERMINALon%
 $ Arqs=ls
Changed:
<
<
$ echo $Arqs ls In this example, I did an atribuition ( = ) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the atribuition was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of atribuition and this can be done in any of the following ways:
>
>
$ echo $Arqs%OUTon% ls%OUToff% %TERMINALoff%

In this example, I did an atribuition (=) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the atribuition was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of atribuition and this can be done in any of the following ways:

%TERMINALon%

 $ Arqs=`ls`
Added:
>
>
%TERMINALoff%
 or:
Added:
>
>
%TERMINALon%
 $ Arqs=$(ls)
Changed:
<
<
To finish this topic, let see only one example. Say I'd want to put into the variable $Arqs the long list (ls -l) of all files started by arq and followed by a single character (?). I should do:
>
>
%TERMINALoff%

To finish this topic, let see only one example. Say I'd want to put into the variable $Arqs the long list (ls -l) of all files started by arq and followed by a single character (?). I should do:

%TERMINALon%

 $ Arqs=$(ls -l arq?)
Added:
>
>
%TERMINALoff%
 or:
Added:
>
>
%TERMINALon%
 $ Arqs=`ls -l arq?`
Added:
>
>
%TERMINALoff%
 But, look at this:
Changed:
<
<
echo $Arqs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql Wow! Everything messed ! As I told you man, if you let the Shell "see" the blank spaces, always we have many blank spaces together, they will be changed by only one. To see a cute list, we need to protect the variable from Shell interpretation, like this: $ echo "$Arqs"
>
>
%TERMINALon% $ echo $Arqs%OUTon% -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql%OUToff% %TERMINALoff%

     - Wow! Everything messed!

     - As I told you man, if you let the Shell "see" the blank spaces, always we have many blank spaces together, they will be changed by only one. To see a cute list, we need to protect the variable from Shell interpretation, like this:

%TERMINALon% $ echo "$Arqs"%OUTon%

 -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2
Changed:
<
<
-rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql - Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting. In Shell, the Hash ( # ) is used to do a comment.
>
>
-rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql%OUToff% %TERMINALoff%

     - Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting: in Shell, the Hash (#) is used to do a comment.

%TERMINALon%

 $ exit # Ask the check frown
Added:
>
>
%TERMINALoff%
 

Revision 211 Nov 2005 - JulioNeves

Line: 1 to 1
Changed:
<
<

Pub Talk Parte I

>
>

Pub Talk Part I

 


Changed:
<
<

Dialog listened between a Linuxer and a "Mouse Pusher:"

>
>
Dialog listened between a Linuxer and a "Mouseoholic"
 
Changed:
<
<
Who's Bash?
>
>
     - Who's Bash?
 
Changed:
<
<
Bash is the newest son of Shell Family
>
>
     - Bash is the newest son of Shell Family
 
Changed:
<
<
Hey dude ! You're gonna drive me crazy. I had one doubt... Now I have two !
>
>
     - Hey dude! You're gonna drive me crazy. I had one doubt... Now I have two!
 
Changed:
<
<
No, man. It's been a long time you are crazy. Since you decided to use that operational system you need to boot ten times a day and don't have any kind of domain about what's happening in your computer. But, never mind. I'm gonna to explain what Shell and your Family are and, in the end, you'll tell: "Holy God of Shell ! Why didn't I choose linux before ?"
>
>
     - No, man. It's been a long time you are crazy. Since you decided to use that operational system you need to boot ten times a day and don't have any kind of domain about what's happening in your computer. But, never mind. I'm gonna to explain what Shell and your Family are and, in the end, you'll tell: "Holy God of Shell ! Why didn't I choose linux before?"
 
Changed:
<
<
The Linux Environment To understand what is Shell and how it works, first of all I'll show you how the Linux Layers Environment works. Take a look at the graph:
>
>

The Linux Environment

 
Added:
>
>
     - To understand what is Shell and how it works, first of all I'll show you how the Linux Layers Environment works. Take a look at the graph:
 
Changed:
<
<
In this graph, we can see that Hardware Layer is the most deep and made for the phisical components of your computer. Involving that we have the Linux Kernel Layer, that is your core. This layer is responsible to make the hardware work, managing and controlling it. The programs and commands that involve the kernel use it to run the jobs they was developed. Closing this, we have the Shell, that has this name because it is between the User and the Operational System, managing everything that needs to interact with the Operational System.
>
>
Visão do shell em relação do Kernel do Linux
 
Changed:
<
<
The Shell Environment Well... as to get the Linux Core, that's the ambition of all aplications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us. The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the shell that the user will get at login. Did you remember I told the Shell Family, brother ? That's it, lets understand this: the Shell is the concept of the shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh ( Bourne Shell ), the ksh ( Korn Shell ), the bash ( Bourne Again Shell ) and the csh ( C Shell ).
>
>
In this graph, we can see that Hardware Layer is the most deep and made for the phisical components of your computer. Involving that we have the Linux Kernel Layer, that is your core. This layer is responsible to make the hardware work, managing and controlling it. The programs and commands that involve the kernel use it to run the jobs they was developed. Closing this, we have the Shell, that has this name because it is between the User and the Operational System, managing everything that needs to interact with the Operational System.
 
Changed:
<
<
A Little Bang in the Main Shell Flavors Bourne Shell (sh) Developed by Stephen Bourne, at AT&T Bell Labs ( where Unix was developed too ), this was during many years the default Shell of Unix Operational System. Is also called Standard Shell, because it was for years the only one shell and is the most used today, because it was ported to all Unix environments and Linux distros.
>
>

The Shell Environment

Well... as to get the Linux Core, that's the ambition of all aplications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us.

The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the Shell that the user will get at login.

Did you remember I told the Shell, family, brother? That's it, lets understand this: the Shell is the concept of the Shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh ( Bourne Shell ), the ksh ( Korn Shell ), the Bash ( Bourne Again Shell ) and the csh ( C Shell ).

A Little Bang in the Main Shell Flavors

Bourne Shell (sh)

Developed by Stephen Bourne, at AT&T Bell Labs ( where Unix was developed too ), this was during many years the default Shell of Unix Operational System. Is also called Standard Shell, because it was for years the only one Shell and is the most used today, because it was ported to all Unix environments and Linux distros.

Korn Shell (ksh)

 
Deleted:
<
<
Korn Shell (ksh)
 Developed by David Korn, from Bell Labs, is a superset of sh, that means, it has all easinesses of sh and to them agregated many others. The total compatibility with sh brings many users and Shell programers to this environment.
Changed:
<
<
Boune Again Shell (bash) This is the most modern shell ( excepting on bash 2 ) and whose number of adepts is growing more and more in whole world, or because it is the Linux default shell, or because its big diversity of commands, that also incorporates many C-Shell commands.
>
>

Boune Again Shell (Bash)

This is the most modern Shell ( excepting on Bash 2 ) and whose number of adepts is growing more and more in whole world, or because it is the Linux default Shell, or because its big diversity of commands, that also incorporates many C-Shell commands.

C Shell (csh)

 
Deleted:
<
<
C Shell (csh)
 Developed by Bill Joy from Berkley University, is the most used BSD and Xenix Shell. Its command structure is very similar to C language structure. Your biggest sin was to ignore the SH compatibility, walking its own way.
Deleted:
<
<
There are some other shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.
 
Changed:
<
<
When I said that the last field of /etc/passwd tells to the system wich is the default user shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.
>
>
There are some other Shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.

%DICASon% When I said that the last field of /etc/passwd tells to the system wich is the default user Shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool. %DICASoff%

Explaining Shell Work

The Shell is the first program you have when you make login at Linux. He will solve lots of things in order to not burden Kernel with repetitive tasks, alliviating him to take care about more noble tasks. As each user has your own Shell interposed between him and Linux, is the Shell that will interpret the commands that are typed and checks its syntax, passing it clean to execution.

 
Changed:
<
<
Explaining Shell Work The shell is the first program you have when you make login at Linux. He will solve lots of things in order to not burden Kernel with repetitive tasks, alliviating him to take care about more noble tasks. As each user has your own shell interposed between him and Linux, is the Shell that will interpret the commands that are typed and checks its syntax, passing it clean to execution.
>
>
     - YO ! This kind of interpret command doesn't have anything with an interpreter ?
 
Changed:
<
<
YO ! This kind of interpret command doesn't have anything with an interpreter ? Yes, it has. In the truth, the Shell is an interpeter that brings with him a powerfull language with high-level commands, that allows loop construction, decision structures and values storage in variables, as I'll show you.
>
>
     - Yes, it has. In the truth, the Shell is an interpeter that brings with him a powerfull language with high-level commands, that allows loop construction, decision structures and values storage in variables, as I'll show you.
 Let's me explain the main tasks that Shell do, in its execution order. Pay attencion in this order, because she's fundamental to the rest of our speech understanding.
Changed:
<
<
Examination of the Command Line In this examination, the shell identifies the special ( reserved ) characters that have meaning for interpretation of the line, and checks if the passed line is a command or an atribuition.
>
>

Examination of the Command Line

 
Changed:
<
<
Command When a line is typed at linux prompt, she is divided in pieces separeted by blank spaces: the first piece is the name of the program and will have your existence searched; next identifies, in this order, options/parameters, redirects and variables. When the identified program exists, the Shell verifies the permissions of involved files ( including the own program ), generating an error if you don't have permissions to run this job.
>
>
In this examination, the Shell identifies the special (reserved) characters that have meaning for interpretation of the line, and checks if the passed line is an atribuition or a command.

Atribuition
 
Deleted:
<
<
Attribuition
 If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.
Changed:
<
<
$ ls linux linux
>
>
%TERMINALon% $ ls linux%OUTon% linux%OUToff% %TERMINALoff%
 
Changed:
<
<
In this example, the Shell identified the ls as a program and linux as a parameter passed to ls program.
>
>
In this example, the Shell identified the ls as a program and linux as a parameter passed to ls program.
 
Added:
>
>
%TERMINALon%
 $ value=1000
Added:
>
>
%TERMINALoff%

In this case, because we don't have blank spaces (and we can notice that the blank space is one of those reservated characters), the Shell identified an atribuition and put 1000 on variable value.

%ATENCAOon% Never do:

%TERMINALon% $ value = 10000%OUTon% bash: value: not found%OUToff% %TERMINALoff%

Bash found the word value between blanks spaces and "guess" that you were trying to execute a program called value, passing two parameters: != and 1000. %ATENCAOoff%

Command
 
Changed:
<
<
In this case, because we don't have blank spaces ( and we can notice that the blank space is one of those reservated characters ), the shell identified an atribuition and put 1000 on variable value.
>
>
When a line is typed at linux prompt, she is divided in pieces separeted by blank spaces: the first piece is the name of the program and will have your existence searched; next identifies, in this order, options/parameters, redirects and variables.
When the identified program exists, the Shell verifies the permissions of involved files (including the own program), generating an error if you don't have permissions to run this job.
 
Changed:
<
<
$ value = 10000 bash: value: not found
>
>
Redirections Resolution
 
Deleted:
<
<
Redirections Resolution
 After identifies the components at command line you typed, the Shell goes to redirections resolution. The Shell has in your advantage issues something we call redirections, that can be input ( stdin ), output ( stdout ) or error ( stderr ), as I´ll explain soon.
Changed:
<
<
Variable Substitutions
>
>
Variable Substitutions
 At this point, Shell verifies if the variables ( parameters started by $ ), found at command scope, are defined and change them to its present values.
Changed:
<
<
Metacharacters Substitutions If any metacharacter ( *, ? ou [] ) was found at command line, it will be changed by its possible values, at this point. Supose that the only file in your actual directory started by "t" be a directory named "thisisaveryhugenameforadirectorybutismydirectoryname", you can do:
>
>
Metacharacters Substitutions

If any metacharacter ( *, ? ou [] ) was found at command line, it will be changed by its possible values, at this point.

Supose that the only file in your actual directory started by T be a directory named ThisIsAVeryHugeNameForADirectoryButIsMyDirectoryName, you can do:

 
Changed:
<
<
$ cd t*
>
>
%TERMINALon% $ cd T* %TERMINALoff%
 
Changed:
<
<
As until here who's working your command line is the Shell and the command ( program ) cd isn't executed yet, the Shell changes the t* in thisisaveryhugenameforadirectorybutismydirectoryname and the command cdwill be successfully executed.
>
>
As until here who's working your command line is the Shell and the command (program) cd isn't executed yet, the Shell changes the T* in ThisIsAVeryHugeNameForADirectoryButIsMyDirectoryName and the command cd will be successfully executed.
 
Changed:
<
<
Sending Command Line to the Kernel Completed the previous jbos, the Shell mounts the command line, now with all changes done, call the kernel to execute it in a new Shell ( Son Shell ), wining a process number called PID ( Process Identification ) and stays inactive, taking a little nap, during the program execution. Once finished this process ( together the son shell ), it takes the control again and, showing the prompt, tells it is ready to execute new commands.
>
>
Sending Command Line to the Kernel

Completed the previous jobs, the Shell mounts the command line, now with all changes done, call the kernel to execute it in a new Shell (Son Shell), wining a process number called PID (Process IDentification ) and stays inactive, taking a little nap, during the program execution. Once finished this process (together the son Shell), it takes the control again and, showing the prompt, tells it is ready to execute new commands.

Decrypting the Roseta's Stone

 
Deleted:
<
<
Decrypting the Roseta's Stone
 To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion ( make a little research at Google to find out who's this man ) decrypting the Roseta's Stone.
Changed:
<
<
Scape Characters
>
>

Scape Characters

 That's it. When we desire Shell to interpret a special character, we must "hide" it from him. This can be done in many ways:
Changed:
<
<
Apostrophe (') When the Shell see a character chain behing apostrophes, he takes of the apostrophes and doesn't interprets its content.
>
>
Apostrophe (')
 
Added:
>
>
When the Shell see a character chain between apostrophes, he takes of the apostrophes and doesn't interprets its content.
 
Changed:
<
<
$ ls linux* linuxmagazine $ ls 'linux*' bash: linux* no such file or directory
>
>
%TERMINALon% $ ls linux*%OUTon% linuxmagazine%OUToff% $ ls 'linux*'%OUTon% bash: linux* no such file or directory%OUToff% %TERMINALoff%
 
Changed:
<
<
In the first case, Shell "expanded" the * and discovered the file linuxmagazine to list.In the second case, the apostrophes inhibited the shell interpretation and we got the answer that there is no file "linux*". That means, the * was expanded in the first case, but was interpreted as a literal * character in the second case.
>
>
In the first case, Shell "expanded" the asterisk (*) and discovered the file linuxmagazine to list.In the second case, the apostrophes inhibited the Shell interpretation and we got the answer that there is no file linux*. That means, the asterisk (*) was expanded in the first case, but was interpreted as a literal asterisk (*) character in the second case.
 
Changed:
<
<
Backslash (\) At the same way that apostrophes work, backslash inhibities the interpretation only of the character that follows her.
>
>
Backslash (\)
 
Changed:
<
<
Imagine you acidentally had created a file named * (asterisks ) - some Unix flavors allow it - and wants to remove it. If you do:
>
>
At the same way that apostrophes work, backslash (\) inhibities the interpretation only of the character that follows her.
 
Added:
>
>
Imagine you acidentally had created a file named * (asterisk) - some Unix flavors allow it - and wants to remove it. If you do:

%TERMINALon%

 $ rm *
Added:
>
>
%TERMINALoff%
 
Changed:
<
<
You will doing a big mess, because the rm would erase ALL files in the current directory. The best way to do this is: In this way, Shell didn't interpretate the asteristiks, doing its expansion.
>
>
You will doing a big mess, because the rm would erase all files in the current directory. The best way to do this is:
 
Added:
>
>
%TERMINALon%
 $ rm \*
Added:
>
>
%TERMINALoff%
 
Changed:
<
<
Do the following cientific experiences:
>
>
In this way, Shell didn't interpretate the asteristiks, doing its expansion.
 
Changed:
<
<
$ cd /etc
>
>
Do the following cientific experience:
 
Added:
>
>
%TERMINALon% $ cd /etc
 $ echo '*'
Deleted:
<
<
 $ echo \*
Deleted:
<
<
 $ echo *
Added:
>
>
%TERMINALoff%
  Did you see the diferences ? So, I don't need to explain nothing more.
Changed:
<
<
Quotation Marks (") Likelly at apostrophes, excepting if the chain between quotation marks has a dolar ( $ ), a crasis ( ` ) or a backslash ( \ ). You don't need to get stressed, but I didn't give samples of quotation marks use because you don't know the dolar ( $ ) nor the crasis ( ` ). From here, we'll see the use of these special characters too many times. The most important is to understand what any one means.
>
>
Quotation Marks (")

Likelly at apostrophes, excepting if the chain between quotation marks has a dolar ($), a crasis (`) or a backslash (\). You don't need to get stressed, but I didn't give samples of quotation marks use because you don't know the dolar ($) nor the crasis (`). From here, we'll see the use of these special characters too many times. The most important is to understand what any one means.

Redirect Characters

 
Deleted:
<
<
Redirect Characters
 The most of commands have an input, an output and can generate errors. This input is called Standard Input or stdin and its default is the terminal keyboard. The output of a command is called Standard Output or stdout and its default is the terminal screen. To the terminal screen also is send by default the error messages that command can generate, called Standard Error or stderr. Let's see now how to change this state of things. Let's do a "parrot program". Do as following:
Added:
>
>
%TERMINALon%
 $ cat
Added:
>
>
%TERMINALoff%

The cat is an instruction that lists the contents of a specific file to the standard output (stdout). If this input aren't defined, he waits the data from standard input (stdin). As I didn't specify the input, he's waiting it from keyboard (standard input) and, as I also didn't tell the output, what I type will go to the screen (standard output), doing this way, as I was proposed, a "parrot program". Try it !

Redirecting Standard Output
 
Changed:
<
<
The cat is an instruction that lists the contents of a specific file to the standard output ( stdout ). If this input aren't defined, he waits the data from stdin. As I didn't specify the input, he's waiting it from keyboard ( Standard Input ) and, as I also didn't tell the output, what I type will go to the screen ( standard output ), doing this way, as I was proposed, a "parrot program". Try it !
>
>
To specify the output of a program we can use the > (greather than) or the >> (greather than, greather than) followed by the name of a file to wich we want to send the output.
 
Deleted:
<
<
Redirecting Standard Output To specify the output of a program we can use the > ( greather than ) or the >> ( greather than, greather than ) followed by the name of a file to wich we want to send the output.
 Lets change the "parrot program" onto a "text editor" ( how pretensious, hu ? ).
Added:
>
>
%TERMINALon%
 $ cat > Arq
Added:
>
>
%TERMINALoff%

The cat continues without the specified input, so is waiting for data typed, but your output is redirected to the file Arq. In this way, everything typed is going to inside the Arq file, that means we did the shorter and whorst text editor of entire planet.

 
Deleted:
<
<
The cat continues without the specified input, so is waiting for data typed, but your output is redirected to the file Arq. In this way, everything typed is going to inside the Arq file, that means we did the shorter and whorst text editor of entire planet.
 If I do again:
Added:
>
>
%TERMINALon%
 $ cat > Arq
Added:
>
>
%TERMINALoff%
 
Changed:
<
<
The data in Arq will be lost, as before the redirecting the Shell will create an empty Arq file. To put information at the end of file, it should be done:
>
>
The data in Arq will be lost, as before the redirecting the Shell will create an empty Arq file. To put information at the end of file, it should be done:
 
Added:
>
>
%TERMINALon%
 $ cat >> Arq
Added:
>
>
%TERMINALoff%
 
Changed:
<
<
>
>
%ATENTIONon%
 As I already told you, the Shell resolves the line and after send the command to execution. Thus, if you redirect the output of a file to itself, first the Shell empty the file and after send the command to execution. In this way, you just lost your dear file.
Added:
>
>
%ATENTIONoff%

With this, we can notice that >> is used to insert data at the end of file.

 
Changed:
<
<
With this, we can notice that >> is used to insert data at the end of file.
>
>
Standard Error Output Redirections
 
Changed:
<
<
Standard Error Output Redirections As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign ( > ) there is no blank space.
>
>
As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign (>) there is no blank space.
 
Changed:
<
<
ATENTION ! Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt ( stderr ) to the specified file. This is important !
>
>
%ATENTIONon% Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt (stderr) to the specified file. This is important! %ATENTIONoff%
 
Changed:
<
<
Supose that, during a script execution you can, or not ( it depends of the way the program execution takes ), created a file named /tmp/isthisexisting$$. To erase trash from your disc, at the end of the script you could put a line like:
>
>
Supose that, during a script execution you can, or not (it depends of the way the program execution takes), created a file named /tmp/IsThisExisting$$. To erase trash from your disc, at the end of the script you could put a line like:

%TERMINALon% rm /tmp/IsThisExisting$$ %TERMINALoff%

 
Deleted:
<
<
rm /tmp/isthisexisting$$
 If the file doesn't exist, an error message will be send to the screen. To not allow this, you should do:
Changed:
<
<
rm /tmp/isthisexisting$$ 2> /dev/null About the example we just saw, I have two tips:
>
>
%TERMINALon% rm /tmp/IsThisExisting$$ 2> /dev/null %TERMINALoff%
 
Changed:
<
<
TIP # 1 - The $$ has the PID, this means, the process number. As Linux is a multi-user systme, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as isthisexist, the first user ( the creator, then ) will be your owner and all others will have a permission error when tried to write something in the file.
>
>
About the example we just saw, I have two tips:
 
Changed:
<
<
To test you Standard Error Output at shell prompt, I'll give one example. Do:
>
>
CTIP # 1 - The $$ has the PID, this means, the Process IDentification. As Linux is a multi-user system, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as IsThisExist?, the first user (the creator, then) will be your owner and all others will have a permission error when tried to write something in the file. %ATENTIONon%
 
Added:
>
>
To test you Standard Error Output at Shell prompt, I'll give one example. Do:
 $ ls donotexist bash: donotexist no such file or directory $ ls donotexist 2> errorfile $ cat errofile bash: donotexist no such file or directory
Changed:
<
<
In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the shell prompt back. When listing the erro messagem file, we saw the error message was stored in it. Do the same test.
>
>
In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the Shell prompt back. When listing the erro messagem file, we saw the error message was stored in it. Do the same test.
 TIP # 2 - Who's the hell of/dev/null? In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file desapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file.
Deleted:
<
<
 It is good to notice that those redirecting characters are cumulatives, this means, if in the previous example we did:
Deleted:
<
<
 $ ls donotexist 2>> errorfile
Deleted:
<
<
 the error message from ls will inserted at the end of errorfile.
Deleted:
<
<
 Standard Input Redirections To do the Standard Input Redirection we use the < ( less than ). And this is used for what, you'll ask me.
Line: 208 to 269
 binary get remotefile endftp
Deleted:
<
<
 This little portion of code we have lots of interesting details:
Changed:
<
<
The options I used to ftp ( -ivn ) are used to it list everything is happening ( -v from verbose ), to not ask if you really want to get the file ( -i from interactive ) and, last but not least, to doesn't require user and password, ( -n ), because these parameters will be informed by the specified instruction user; When I used the << endftp, I was telling the following: "Listen to me, Shell. Do not mess with nothing from here until find the label endftp. You didn't understand anything, as they are ftp specific instructions". If this was the end, it would be simple, but following the example, we can see that there are two variables ( $USER and $PASSWD ), that the shell will interpret before the redirection. But the great advantage of this kind of construction is that it allows to commands be interpreted inside the here document escope, that opposes what I just said. Soon I'll explain how this thing works. Now we can't, because you don't know all the tools; The command user is a ftp command and is used to pass user and password that were read in a previous routine and inserted in our two variables: $USER and $PASSWD; The binary is another ftpinstruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc; The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.
>
>
1.The options I used to ftp ( -ivn ) are used to it list everything is happening ( -v from verbose ), to not ask if you really want to get the file ( -i from interactive ) and, last but not least, to doesn't require user and password, ( -n ), because these parameters will be informed by the specified instruction user; 2.When I used the << endftp, I was telling the following: "Listen to me, Shell. Do not mess with nothing from here until find the label endftp. You didn't understand anything, as they are ftp specific instructions". If this was the end, it would be simple, but following the example, we can see that there are two variables ( $USER and $PASSWD ), that the Shell will interpret before the redirection. But the great advantage of this kind of construction is that it allows to commands be interpreted inside the here document escope, that opposes what I just said. Soon I'll explain how this thing works. Now we can't, because you don't know all the tools; 3.The command user is a ftp command and is used to pass user and password that were read in a previous routine and inserted in our two variables: $USER and $PASSWD; 4.The binary is another ftpinstruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc; 5.The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.
 A very frequent error in the labels use ( as the endftp in our previous example ) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her.
Deleted:
<
<
 All right... all right... I know I was babling and walked by ftpcommands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...
Deleted:
<
<
 Command Redirection The redirections we told until now always refered to files, that means, they sent things to a file, they got things from a file, they simulated local files. What we'll see from now redirects the output of a command to the input of another. This is very usefull and make lots of things easy. You name is pipe and acts as a pipe between two commands, or in other words, acts pipeing information from one command to another. Your representation is a vertical bar ( | ).
Deleted:
<
<
 $ ls | wc -l
Deleted:
<
<
 The lscommand passed the file list to the wccommand, that when it has the option -l counts the lines received. Using this, we can say how many files we have in our directory.
Deleted:
<
<
 $ cat /etc/passwd |sort | lp
Deleted:
<
<
 This command line sends contents of /etc/passwd file to the sort command input. This command classifies it and sends to lp, that is our printer spool manager.
Deleted:
<
<
 Environment Characters
Changed:
<
<
When you want to priorize one expression, you put it between parentesis, right ? So, because of arithmetic, this is a normal think. But in shell what really priorizes expressions are the grave ( ` ) and not the parentesis. I'll give you examples of grave uses, to get better understanding.
>
>
When you want to priorize one expression, you put it between parentesis, right ? So, because of arithmetic, this is a normal think. But in Shell what really priorizes expressions are the grave ( ` ) and not the parentesis. I'll give you examples of grave uses, to get better understanding.
 I want to know how many users are logged in my computer. I can do:
Deleted:
<
<
 $ who | wc -l
Deleted:
<
<
 The who command sends the connected users list to the command wc -l that counts how many lines it received and shows the answer in the termina. So, if we want to have more than a number alone in the screen, what I want is that is stays in the middle of a phrase. To send phrases to the screen I use the echo command. So let see how it works:
Deleted:
<
<
 $ echo "There is who | wc -l connected users" There is who | wc -l connected users
Deleted:
<
<
 What ? Look that ! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this:
Deleted:
<
<
 $ echo "There is `who | wc -l ` connected users"

There is 8 connected users

Line: 272 to 312
 /etc/ $ pwd /home/mydir
Deleted:
<
<
 What the heck ? I was in /home/mydir, changed to /etc, check that I really was in this directory with the pwd and, when the command group finished, I saw I was at the /etc/mydir, as if I never had out of there !
Deleted:
<
<
 - Oh crap. It's a kind of magic !
Changed:
<
<
- Are you crazy, man ? Of course not ! The interesting in the parentesis use is that it calls a new shell to execute the commands inside them. In this way, we really gone to /etc directory, but when all parentesis commands were executed, the new Shell that was at /etc directory died and we came back to the previous Shell which our current directory as /home/mydir. Do other tests using cd and ls to fix the concepts.
>
>
- Are you crazy, man ? Of course not ! The interesting in the parentesis use is that it calls a new Shell to execute the commands inside them. In this way, we really gone to /etc directory, but when all parentesis commands were executed, the new Shell that was at /etc directory died and we came back to the previous Shell which our current directory as /home/mydir. Do other tests using cd and ls to fix the concepts.
 Now we already know these concepts, take a lookt at the following example:
Deleted:
<
<
 $ mail support << END >Hi support, today at `date"+%hh:mm"`
>we had that problem again
Line: 295 to 330
 Finally now we have knowledge to show what we had talk about here document. The commands between grave are priorized and then the Shell will execute them before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment. The default Shell primary prompt, as we saw, is the dolar ( $ ), but Shell uses a concept of secondary prompt, or command continue, that is sent to the screen when we have a line feed and the instruction didn't end yet. This prompt is represented as a greather than signal ( > ), that we see at the beggining of the second line and above.
Deleted:
<
<
 To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the graves. They are the constructions like $(cmd>), where cmd are one or many commands that will be executed with priority in its context.
Changed:
<
<
In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all shell flavoes. Here in the pub, I'll use both ways, with no distiction.
>
>
In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all Shell flavoes. Here in the pub, I'll use both ways, with no distiction.
 Lets see again the gave example to the grave in this new point of view:
Deleted:
<
<
 $ echo There is $(who | grep wc -l) connected users There is 8 connected users
Deleted:
<
<
 Take a look at this case:
Deleted:
<
<
 $ Arqs=ls $ echo $Arqs ls

Revision 109 Nov 2005 - JulioNeves

Line: 1 to 1
Added:
>
>

Pub Talk Parte I



Dialog listened between a Linuxer and a "Mouse Pusher:"

Who's Bash?

Bash is the newest son of Shell Family

Hey dude ! You're gonna drive me crazy. I had one doubt... Now I have two !

No, man. It's been a long time you are crazy. Since you decided to use that operational system you need to boot ten times a day and don't have any kind of domain about what's happening in your computer. But, never mind. I'm gonna to explain what Shell and your Family are and, in the end, you'll tell: "Holy God of Shell ! Why didn't I choose linux before ?"

The Linux Environment To understand what is Shell and how it works, first of all I'll show you how the Linux Layers Environment works. Take a look at the graph:

In this graph, we can see that Hardware Layer is the most deep and made for the phisical components of your computer. Involving that we have the Linux Kernel Layer, that is your core. This layer is responsible to make the hardware work, managing and controlling it. The programs and commands that involve the kernel use it to run the jobs they was developed. Closing this, we have the Shell, that has this name because it is between the User and the Operational System, managing everything that needs to interact with the Operational System.

The Shell Environment Well... as to get the Linux Core, that's the ambition of all aplications, is needed the Shell filtering, let's understand how it works, to take the maximum of the uncountable tools he gives to us. The Linux, by definition, is a multi-user system - we can't forget this, ever - and to allow the access to specific users and deny other, there is a file called /etc/passwd that gives data for this "hoster" function and give informations to login of those who passed the first obstacle. The last field of its records tells to the system which is the shell that the user will get at login. Did you remember I told the Shell Family, brother ? That's it, lets understand this: the Shell is the concept of the shell involving the operational system as is, and is the generic name to treat the sons of this idea that, for the years of Unix existence, was born. Nowadays there are lots of Shell flavors. We can tell about sh ( Bourne Shell ), the ksh ( Korn Shell ), the bash ( Bourne Again Shell ) and the csh ( C Shell ).

A Little Bang in the Main Shell Flavors Bourne Shell (sh) Developed by Stephen Bourne, at AT&T Bell Labs ( where Unix was developed too ), this was during many years the default Shell of Unix Operational System. Is also called Standard Shell, because it was for years the only one shell and is the most used today, because it was ported to all Unix environments and Linux distros.

Korn Shell (ksh) Developed by David Korn, from Bell Labs, is a superset of sh, that means, it has all easinesses of sh and to them agregated many others. The total compatibility with sh brings many users and Shell programers to this environment.

Boune Again Shell (bash) This is the most modern shell ( excepting on bash 2 ) and whose number of adepts is growing more and more in whole world, or because it is the Linux default shell, or because its big diversity of commands, that also incorporates many C-Shell commands.

C Shell (csh) Developed by Bill Joy from Berkley University, is the most used BSD and Xenix Shell. Its command structure is very similar to C language structure. Your biggest sin was to ignore the SH compatibility, walking its own way. There are some other shells, but we only will talk about the three firsts, treating them generically as "Shell" and pointing the particular characteristics of each one, if they have.

When I said that the last field of /etc/passwd tells to the system wich is the default user shell at login, we can understand it as is, that means, if in this field we have prog, the user will have the prog program screen and, at finish of the execution, he will have a logout. Imagine how much security we can implement with this simple tool.

Explaining Shell Work The shell is the first program you have when you make login at Linux. He will solve lots of things in order to not burden Kernel with repetitive tasks, alliviating him to take care about more noble tasks. As each user has your own shell interposed between him and Linux, is the Shell that will interpret the commands that are typed and checks its syntax, passing it clean to execution.

YO ! This kind of interpret command doesn't have anything with an interpreter ? Yes, it has. In the truth, the Shell is an interpeter that brings with him a powerfull language with high-level commands, that allows loop construction, decision structures and values storage in variables, as I'll show you. Let's me explain the main tasks that Shell do, in its execution order. Pay attencion in this order, because she's fundamental to the rest of our speech understanding.

Examination of the Command Line In this examination, the shell identifies the special ( reserved ) characters that have meaning for interpretation of the line, and checks if the passed line is a command or an atribuition.

Command When a line is typed at linux prompt, she is divided in pieces separeted by blank spaces: the first piece is the name of the program and will have your existence searched; next identifies, in this order, options/parameters, redirects and variables. When the identified program exists, the Shell verifies the permissions of involved files ( including the own program ), generating an error if you don't have permissions to run this job.

Attribuition If the Shell finds two fields separated by an equal (=) without blank spaces between them, identifies this sequency as an attribuition.

$ ls linux linux

In this example, the Shell identified the ls as a program and linux as a parameter passed to ls program.

$ value=1000

In this case, because we don't have blank spaces ( and we can notice that the blank space is one of those reservated characters ), the shell identified an atribuition and put 1000 on variable value.

$ value = 10000 bash: value: not found

Redirections Resolution After identifies the components at command line you typed, the Shell goes to redirections resolution. The Shell has in your advantage issues something we call redirections, that can be input ( stdin ), output ( stdout ) or error ( stderr ), as I´ll explain soon.

Variable Substitutions At this point, Shell verifies if the variables ( parameters started by $ ), found at command scope, are defined and change them to its present values.

Metacharacters Substitutions If any metacharacter ( *, ? ou [] ) was found at command line, it will be changed by its possible values, at this point. Supose that the only file in your actual directory started by "t" be a directory named "thisisaveryhugenameforadirectorybutismydirectoryname", you can do:

$ cd t*

As until here who's working your command line is the Shell and the command ( program ) cd isn't executed yet, the Shell changes the t* in thisisaveryhugenameforadirectorybutismydirectoryname and the command cdwill be successfully executed.

Sending Command Line to the Kernel Completed the previous jbos, the Shell mounts the command line, now with all changes done, call the kernel to execute it in a new Shell ( Son Shell ), wining a process number called PID ( Process Identification ) and stays inactive, taking a little nap, during the program execution. Once finished this process ( together the son shell ), it takes the control again and, showing the prompt, tells it is ready to execute new commands.

Decrypting the Roseta's Stone To take off that feeling you have when you see a Shell script, that's like a letter soup or hierogliphs, I'll show you the main special characteres that allow you to walk as Jean-François Champollion ( make a little research at Google to find out who's this man ) decrypting the Roseta's Stone.

Scape Characters That's it. When we desire Shell to interpret a special character, we must "hide" it from him. This can be done in many ways:

Apostrophe (') When the Shell see a character chain behing apostrophes, he takes of the apostrophes and doesn't interprets its content.

$ ls linux* linuxmagazine $ ls 'linux*' bash: linux* no such file or directory

In the first case, Shell "expanded" the * and discovered the file linuxmagazine to list.In the second case, the apostrophes inhibited the shell interpretation and we got the answer that there is no file "linux*". That means, the * was expanded in the first case, but was interpreted as a literal * character in the second case.

Backslash (\) At the same way that apostrophes work, backslash inhibities the interpretation only of the character that follows her.

Imagine you acidentally had created a file named * (asterisks ) - some Unix flavors allow it - and wants to remove it. If you do:

$ rm *

You will doing a big mess, because the rm would erase ALL files in the current directory. The best way to do this is: In this way, Shell didn't interpretate the asteristiks, doing its expansion.

$ rm \*

Do the following cientific experiences:

$ cd /etc

$ echo '*'

$ echo \*

$ echo *

Did you see the diferences ? So, I don't need to explain nothing more.

Quotation Marks (") Likelly at apostrophes, excepting if the chain between quotation marks has a dolar ( $ ), a crasis ( ` ) or a backslash ( \ ). You don't need to get stressed, but I didn't give samples of quotation marks use because you don't know the dolar ( $ ) nor the crasis ( ` ). From here, we'll see the use of these special characters too many times. The most important is to understand what any one means.

Redirect Characters The most of commands have an input, an output and can generate errors. This input is called Standard Input or stdin and its default is the terminal keyboard. The output of a command is called Standard Output or stdout and its default is the terminal screen. To the terminal screen also is send by default the error messages that command can generate, called Standard Error or stderr. Let's see now how to change this state of things. Let's do a "parrot program". Do as following:

$ cat

The cat is an instruction that lists the contents of a specific file to the standard output ( stdout ). If this input aren't defined, he waits the data from stdin. As I didn't specify the input, he's waiting it from keyboard ( Standard Input ) and, as I also didn't tell the output, what I type will go to the screen ( standard output ), doing this way, as I was proposed, a "parrot program". Try it !

Redirecting Standard Output To specify the output of a program we can use the > ( greather than ) or the >> ( greather than, greather than ) followed by the name of a file to wich we want to send the output. Lets change the "parrot program" onto a "text editor" ( how pretensious, hu ? ).

$ cat > Arq

The cat continues without the specified input, so is waiting for data typed, but your output is redirected to the file Arq. In this way, everything typed is going to inside the Arq file, that means we did the shorter and whorst text editor of entire planet. If I do again:

$ cat > Arq

The data in Arq will be lost, as before the redirecting the Shell will create an empty Arq file. To put information at the end of file, it should be done:

$ cat >> Arq

As I already told you, the Shell resolves the line and after send the command to execution. Thus, if you redirect the output of a file to itself, first the Shell empty the file and after send the command to execution. In this way, you just lost your dear file.

With this, we can notice that >> is used to insert data at the end of file.

Standard Error Output Redirections As the Shell receives data from a keyboard and send the output to a screen by default, the errors also are send to the screen if you don't specify another output. To redirect the errors, use 2> error_file. Pay atention that between the number 2 and the greather than sign ( > ) there is no blank space.

ATENTION ! Don't make the confusion between >> with 2>. The first one insert data at the end of a file and the second one redirects the standard error outupt ( stderr ) to the specified file. This is important !

Supose that, during a script execution you can, or not ( it depends of the way the program execution takes ), created a file named /tmp/isthisexisting$$. To erase trash from your disc, at the end of the script you could put a line like:

rm /tmp/isthisexisting$$ If the file doesn't exist, an error message will be send to the screen. To not allow this, you should do:

rm /tmp/isthisexisting$$ 2> /dev/null About the example we just saw, I have two tips:

TIP # 1 - The $$ has the PID, this means, the process number. As Linux is a multi-user systme, is always good insert the $$ to the file names that will be used for many people to avoid properties problems, that means, if you named your file just as isthisexist, the first user ( the creator, then ) will be your owner and all others will have a permission error when tried to write something in the file.

To test you Standard Error Output at shell prompt, I'll give one example. Do:

$ ls donotexist bash: donotexist no such file or directory $ ls donotexist 2> errorfile $ cat errofile bash: donotexist no such file or directory

In this case, we saw that when we did a ls at donotexist, we got an error message. After redirect the standard error output to errorfile and run the same command, we got only the shell prompt back. When listing the erro messagem file, we saw the error message was stored in it. Do the same test.

TIP # 2 - Who's the hell of/dev/null? In Unix, there is a ghost file. It's called /dev/null. Everything is sent to this file desapears. It's like a Black Hole. In my example, as I was not interested in store a possible error message from rm command, I just redirect it to this file.

It is good to notice that those redirecting characters are cumulatives, this means, if in the previous example we did:

$ ls donotexist 2>> errorfile

the error message from ls will inserted at the end of errorfile.

Standard Input Redirections To do the Standard Input Redirection we use the < ( less than ). And this is used for what, you'll ask me.

You'll understand too fast. Let me show you an example.

Supose taht you want to send an e-mail to your boss. To the Boss, we always whim, right ? So, instead of start typing the e-mail at the prompt that makes the correction of a previous phrase impossible, you write a file with the message and after ten checks without see any error, you decide to send it, and do:

$ mail boss < filewithmailtotheboss

Your boss will receive the text in the filewithmailtotheboss. Another type of very crazy redirection Shell allows is called here document. He's represented by << (less than, less than) and indicates to the Shell that the command escope begins at the next line and ends when found a line that contains only the label that follow the sign <<. See the following script, with a ftp routine:

ftp -ivn remotehost <<endftp user $USER $PASSWD binary get remotefile endftp

This little portion of code we have lots of interesting details:

The options I used to ftp ( -ivn ) are used to it list everything is happening ( -v from verbose ), to not ask if you really want to get the file ( -i from interactive ) and, last but not least, to doesn't require user and password, ( -n ), because these parameters will be informed by the specified instruction user; When I used the << endftp, I was telling the following: "Listen to me, Shell. Do not mess with nothing from here until find the label endftp. You didn't understand anything, as they are ftp specific instructions". If this was the end, it would be simple, but following the example, we can see that there are two variables ( $USER and $PASSWD ), that the shell will interpret before the redirection. But the great advantage of this kind of construction is that it allows to commands be interpreted inside the here document escope, that opposes what I just said. Soon I'll explain how this thing works. Now we can't, because you don't know all the tools; The command user is a ftp command and is used to pass user and password that were read in a previous routine and inserted in our two variables: $USER and $PASSWD; The binary is another ftpinstruction, that is used to indicate that the transfer of the remotefile file will be done in binary way, that means, the file data will not interpreted to know if it is ASCII, EBCDIC, etc; The get remotefile tells to ftp to download this file from remotehost to our local host. If we want to send the file, we used the command put.

A very frequent error in the labels use ( as the endftp in our previous example ) is caused by the existence of blank spaces before or after it. Pay atention on it, because this kind of error uses to spank the programer's ass, until its detection. Remember: a good label must be an entire line to her.

All right... all right... I know I was babling and walked by ftpcommands, outing of our main subject, but is always good to learn and is very rare to find people that loves to teach...

Command Redirection The redirections we told until now always refered to files, that means, they sent things to a file, they got things from a file, they simulated local files. What we'll see from now redirects the output of a command to the input of another. This is very usefull and make lots of things easy. You name is pipe and acts as a pipe between two commands, or in other words, acts pipeing information from one command to another. Your representation is a vertical bar ( | ).

$ ls | wc -l

The lscommand passed the file list to the wccommand, that when it has the option -l counts the lines received. Using this, we can say how many files we have in our directory.

$ cat /etc/passwd |sort | lp

This command line sends contents of /etc/passwd file to the sort command input. This command classifies it and sends to lp, that is our printer spool manager.

Environment Characters When you want to priorize one expression, you put it between parentesis, right ? So, because of arithmetic, this is a normal think. But in shell what really priorizes expressions are the grave ( ` ) and not the parentesis. I'll give you examples of grave uses, to get better understanding. I want to know how many users are logged in my computer. I can do:

$ who | wc -l

The who command sends the connected users list to the command wc -l that counts how many lines it received and shows the answer in the termina. So, if we want to have more than a number alone in the screen, what I want is that is stays in the middle of a phrase. To send phrases to the screen I use the echo command. So let see how it works:

$ echo "There is who | wc -l connected users" There is who | wc -l connected users

What ? Look that ! It didn't work. It didn't work indeed, and wasn't because the quotation marks I used, but because I must to execute the who | wc -l command before the echo command. To solve this problem, I need to priorize this second command with the use of grave, doing this:

$ echo "There is `who | wc -l ` connected users"

There is 8 connected users

To remove those blank spaces before 8 that wc -l produced, we just need to remove quotations. Like this:

$ echo There is `who | wc -l ` connected users There is 8 connected users

As I said, the quotation marks protect everything that is inside your limits from Shell interpretation. As to the Shell a single blank space as separator is enought, the extra spcaes will be changed by an only one after we remove the quotation marks. Before tell about parentesis use, let me give a little bang about the semi-collon ( ; ) use. When you are in the Shell, you must always give only one command in each line. To group commands at the same line, we need to separate ir by semi-collon. So:

$ pwd ; cd /etc; pwd; cd -; pwd /home/mydir /etc/ /home/mydir

At this example, I listed the name of current directory with pwdcommand, changed to the /etc directory, again listed the directory name and finally back to the previous directory ( cd - ), listing its name. Note that I put the semi-collon ( ; ) in all possible ways, to show that don't mind if there is blank spaces before or after this character. Finally, lets see the parentesis case. Take a look at the following case, likelly the previous example:

$ (pwd ; cd /etc ; pwd;) /home/mydir /etc/ $ pwd /home/mydir

What the heck ? I was in /home/mydir, changed to /etc, check that I really was in this directory with the pwd and, when the command group finished, I saw I was at the /etc/mydir, as if I never had out of there !

- Oh crap. It's a kind of magic !

- Are you crazy, man ? Of course not ! The interesting in the parentesis use is that it calls a new shell to execute the commands inside them. In this way, we really gone to /etc directory, but when all parentesis commands were executed, the new Shell that was at /etc directory died and we came back to the previous Shell which our current directory as /home/mydir. Do other tests using cd and ls to fix the concepts. Now we already know these concepts, take a lookt at the following example:

$ mail support << END >Hi support, today at `date"+%hh:mm"`
>we had that problem again
>that I was reported by
>phone. As you ask
>here it goes a file list from
>the directory:
>`ls -l`
>Best Reggards.
>END

Finally now we have knowledge to show what we had talk about here document. The commands between grave are priorized and then the Shell will execute them before the mail instruction. When the support received the e-mail, will see that the commands date and ls were executed before the command mail, receiving then the snapshot of environment at the e-mail send moment. The default Shell primary prompt, as we saw, is the dolar ( $ ), but Shell uses a concept of secondary prompt, or command continue, that is sent to the screen when we have a line feed and the instruction didn't end yet. This prompt is represented as a greather than signal ( > ), that we see at the beggining of the second line and above.

To end and mess with everything, I need to say that exists a newer, modern, construction that is used as command execution priorization way, like the graves. They are the constructions like $(cmd>), where cmd are one or many commands that will be executed with priority in its context. In this way, the use of graves or constructions like $(cmd) have the same target, but for whom works with multi-plataform operational systems, I advice the use of graves, as the $(cmd) wasn't ported to all shell flavoes. Here in the pub, I'll use both ways, with no distiction.

Lets see again the gave example to the grave in this new point of view:

$ echo There is $(who | grep wc -l) connected users There is 8 connected users

Take a look at this case:

$ Arqs=ls $ echo $Arqs ls

In this example, I did an atribuition ( = ) and run an instruction. What I wanted was the variable $Arqs had received the output of ls command. As the instructions of a script are interpreted from above to bellow and from left to right, the atribuition was done before the execution of ls. To do what we want is needed to priorize the execution of this command in detriment of atribuition and this can be done in any of the following ways:

$ Arqs=`ls`

or:

$ Arqs=$(ls)

To finish this topic, let see only one example. Say I'd want to put into the variable $Arqs the long list (ls -l) of all files started by arq and followed by a single character (?). I should do:

$ Arqs=$(ls -l arq?)

or:

$ Arqs=`ls -l arq?`

But, look at this:

echo $Arqs -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql

Wow! Everything messed !

As I told you man, if you let the Shell "see" the blank spaces, always we have many blank spaces together, they will be changed by only one. To see a cute list, we need to protect the variable from Shell interpretation, like this:

$ echo "$Arqs" -rw-r--r-- 1 jneves jneves 19 May 24 19:41 arq1 -rw-r--r-- 1 jneves jneves 23 May 24 19:43 arq2 -rw-r--r-- 1 jneves jneves 1866 Jan 22 2003 arql

- Look pall, go training these examples because, when we meet again, I'll explain a series of tipical Shell Programming instructions. Bye ! Oh, only one little thing I was forgotting. In Shell, the Hash ( # ) is used to do a comment.

$ exit # Ask the check frown

 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Wiki-SL? Send feedback