Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status

Gentoo Archives: gentoo-doc-cvs

From: Shyam Mani <fox2mike@×××××××××××.org>
To: gentoo-doc-cvs@l.g.o
Subject: [gentoo-doc-cvs] cvs commit: bash-by-example-p1.xml
Date: Thu, 14 Jul 2005 15:00:16
Message-Id: 200507141500.j6EF01mH019105@robin.gentoo.org
1 fox2mike 05/07/14 14:59:55
2
3 Added: xml/htdocs/doc/en/articles bash-by-example-p1.xml
4 Log:
5 #98770 - Bash by example part 1, Initial version. Thanks to Lukasz Damentko.
6
7 Revision Changes Path
8 1.1 xml/htdocs/doc/en/articles/bash-by-example-p1.xml
9
10 file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/bash-by-example-p1.xml?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=gentoo
11 plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/articles/bash-by-example-p1.xml?rev=1.1&content-type=text/plain&cvsroot=gentoo
12
13 Index: bash-by-example-p1.xml
14 ===================================================================
15 <?xml version='1.0' encoding="UTF-8"?>
16 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/articles/bash-by-example-p1.xml,v 1.1 2005/07/14 14:59:54 fox2mike Exp $ -->
17 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
18
19 <guide link="/doc/en/articles/bash-by-example-p1.xml">
20 <title>Bash by example, Part 1</title>
21
22 <author title="Author">
23 <mail link="drobbins@g.o">Daniel Robbins</mail>
24 </author>
25 <author title="Editor">
26 <mail link="rane@××××××.pl">Łukasz Damentko</mail>
27 </author>
28
29 <abstract>
30 By learning how to program in the bash scripting language, your day-to-day
31 interaction with Linux will become more fun and productive, and you'll be able
32 to build upon those standard UNIX constructs (like pipelines and redirection)
33 that you already know and love. In this three-part series, Daniel Robbins will
34 teach you how to program in bash by example. He'll cover the absolute basics
35 (making this an excellent series for beginners) and bring in more advanced
36 features as the series proceeds.
37 </abstract>
38
39 <!-- The original version of this article was published on IBM developerWorks,
40 and is property of Westtech Information Services. This document is an updated
41 version of the original article, and contains various improvements made by the
42 Gentoo Linux Documentation team -->
43
44 <version>1.0</version>
45 <date>2005-07-12</date>
46
47 <chapter>
48 <title>Fundamental programming in the Bourne again shell (bash)</title>
49 <section>
50 <title>Introduction</title>
51 <body>
52
53 <note>
54 The original version of this article was published on IBM developerWorks, and
55 is property of Westtech Information Services. This document is an updated
56 version of the original article, and contains various improvements made by the
57 Gentoo Linux Documentation team.
58 </note>
59
60 <p>
61 You might wonder why you ought to learn Bash programming. Well, here are a
62 couple of compelling reasons:
63 </p>
64
65 </body>
66 </section>
67 <section>
68 <title>You're already running it</title>
69 <body>
70
71 <p>
72 If you check, you'll probably find that you are running bash right now. Even if
73 you changed your default shell, bash is probably still running somewhere on your
74 system, because it's the standard Linux shell and is used for a variety of
75 purposes. Because bash is already running, any additional bash scripts that you
76 run are inherently memory-efficient because they share memory with any
77 already-running bash processes. Why load a 500K interpreter if you already are
78 running something that will do the job, and do it well?
79 </p>
80
81 </body>
82 </section>
83 <section>
84 <title>You're already using it</title>
85 <body>
86
87 <p>
88 Not only are you already running bash, but you're actually interacting with bash
89 on a daily basis. It's always there, so it makes sense to learn how to use it to
90 its fullest potential. Doing so will make your bash experience more fun and
91 productive. But why should you learn bash programming? Easy, because you already
92 think in terms of running commands, CPing files, and piping and redirecting
93 output. Shouldn't you learn a language that allows you to use and build upon
94 these powerful time-saving constructs you already know how to use? Command
95 shells unlock the potential of a UNIX system, and bash is the Linux shell. It's
96 the high-level glue between you and the machine. Grow in your knowledge of bash,
97 and you'll automatically increase your productivity under Linux and UNIX -- it's
98 that simple.
99 </p>
100
101 </body>
102 </section>
103 <section>
104 <title>Bash confusion</title>
105 <body>
106
107 <p>
108 Learning bash the wrong way can be a very confusing process. Many newbies type
109 <c>man bash</c> to view the bash man page, only to be confronted with a very
110 terse and technical description of shell functionality. Others type <c>info
111 bash</c> (to view the GNU info documentation), causing either the man page to be
112 redisplayed, or (if they are lucky) only slightly more friendly info
113 documentation to appear.
114 </p>
115
116 <p>
117 While this may be somewhat disappointing to novices, the standard bash
118 documentation can't be all things to all people, and caters towards those
119 already familiar with shell programming in general. There's definitely a lot of
120 excellent technical information in the man page, but its helpfulness to
121 beginners is limited.
122 </p>
123
124 <p>
125 That's where this series comes in. In it, I'll show you how to actually use bash
126 programming constructs, so that you will be able to write your own scripts.
127 Instead of technical descriptions, I'll provide you with explanations in plain
128 English, so that you will know not only what something does, but when you should
129 actually use it. By the end of this three-part series, you'll be able to write
130 your own intricate bash scripts, and be at the level where you can comfortably
131 use bash and supplement your knowledge by reading (and understanding!) the
132 standard bash documentation. Let's begin.
133 </p>
134
135 </body>
136 </section>
137 <section>
138 <title>Environment variables</title>
139 <body>
140
141 <p>
142 Under bash and almost all other shells, the user can define environment
143 variables, which are stored internally as ASCII strings. One of the handiest
144 things about environment variables is that they are a standard part of the UNIX
145 process model. This means that environment variables not only are exclusive to
146 shell scripts, but can be used by standard compiled programs as well. When we
147 "export" an environment variable under bash, any subsequent program that we run
148 can read our setting, whether it is a shell script or not. A good example is the
149 <c>vipw</c> command, which normally allows root to edit the system password
150 file. By setting the <c>EDITOR</c> environment variable to the name of your
151 favorite text editor, you can configure vipw to use it instead of vi, a handy
152 thing if you are used to xemacs and really dislike vi.
153 </p>
154
155 <p>
156 The standard way to define an environment variable under bash is:
157 </p>
158
159 <pre caption="Defining environment variable">
160 $ <i>myvar='This is my environment variable!'</i>
161 </pre>
162
163 <p>
164 The above command defined an environment variable called "myvar" and contains
165 the string "This is my environment variable!". There are several things to
166 notice above: first, there is no space on either side of the "=" sign; any space
167 will result in an error (try it and see). The second thing to notice is that
168 while we could have done away with the quotes if we were defining a single word,
169 they are necessary when the value of the environment variable is more than a
170 single word (contains spaces or tabs).
171 </p>
172
173 <note>
174 For extremely detailed information on how quotes should be used in bash, you may
175 want to look at the "QUOTING" section in the bash man page. The existence of
176 special character sequences that get "expanded" (replaced) with other values
177 does complicate how strings are handled in bash. We will just cover the most
178 often-used quoting functionality in this series.
179 </note>
180
181 <p>
182 Thirdly, while we can normally use double quotes instead of single quotes, doing
183 so in the above example would have caused an error. Why? Because using single
184 quotes disables a bash feature called expansion, where special characters and
185 sequences of characters are replaced with values. For example, the "!" character
186 is the history expansion character, which bash normally replaces with a
187 previously-typed command. (We won't be covering history expansion in this series
188 of articles, because it is not frequently used in bash programming. For more
189 information on it, see the "HISTORY EXPANSION" section in the bash man page.)
190 While this macro-like functionality can come in handy, right now we want a
191 literal exclamation point at the end of our environment variable, rather than a
192 macro.
193 </p>
194
195 <p>
196 Now, let's take a look at how one actually uses environment variables. Here's an
197 example:
198 </p>
199
200 <pre caption="Using environment variables">
201 $ <i>echo $myvar</i>
202 This is my environment variable!
203 </pre>
204
205 <p>
206 By preceding the name of our environment variable with a $, we can cause bash to
207 replace it with the value of myvar. In bash terminology, this is called
208 "variable expansion". But, what if we try the following:
209 </p>
210
211 <pre caption="First try to use variable expansion">
212 $ <i>echo foo$myvarbar</i>
213 foo
214
215
216
217 --
218 gentoo-doc-cvs@g.o mailing list
Report Message
Find on MARC Find on Google Groups