fox2mike 05/07/14 14:59:55 Added: xml/htdocs/doc/en/articles bash-by-example-p1.xml Log: #98770 - Bash by example part 1, Initial version. Thanks to Lukasz Damentko.
Revision Changes Path 1.1 xml/htdocs/doc/en/articles/bash-by-example-p1.xml 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 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 Index: bash-by-example-p1.xml =================================================================== <?xml version='1.0' encoding="UTF-8"?> <!-- $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 $ --> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <guide link="/doc/en/articles/bash-by-example-p1.xml"> <title>Bash by example, Part 1</title> <author title="Author"> <mail link="[EMAIL PROTECTED]">Daniel Robbins</mail> </author> <author title="Editor"> <mail link="[EMAIL PROTECTED]">Åukasz Damentko</mail> </author> <abstract> By learning how to program in the bash scripting language, your day-to-day interaction with Linux will become more fun and productive, and you'll be able to build upon those standard UNIX constructs (like pipelines and redirection) that you already know and love. In this three-part series, Daniel Robbins will teach you how to program in bash by example. He'll cover the absolute basics (making this an excellent series for beginners) and bring in more advanced features as the series proceeds. </abstract> <!-- The original version of this article was published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux Documentation team --> <version>1.0</version> <date>2005-07-12</date> <chapter> <title>Fundamental programming in the Bourne again shell (bash)</title> <section> <title>Introduction</title> <body> <note> The original version of this article was published on IBM developerWorks, and is property of Westtech Information Services. This document is an updated version of the original article, and contains various improvements made by the Gentoo Linux Documentation team. </note> <p> You might wonder why you ought to learn Bash programming. Well, here are a couple of compelling reasons: </p> </body> </section> <section> <title>You're already running it</title> <body> <p> If you check, you'll probably find that you are running bash right now. Even if you changed your default shell, bash is probably still running somewhere on your system, because it's the standard Linux shell and is used for a variety of purposes. Because bash is already running, any additional bash scripts that you run are inherently memory-efficient because they share memory with any already-running bash processes. Why load a 500K interpreter if you already are running something that will do the job, and do it well? </p> </body> </section> <section> <title>You're already using it</title> <body> <p> Not only are you already running bash, but you're actually interacting with bash on a daily basis. It's always there, so it makes sense to learn how to use it to its fullest potential. Doing so will make your bash experience more fun and productive. But why should you learn bash programming? Easy, because you already think in terms of running commands, CPing files, and piping and redirecting output. Shouldn't you learn a language that allows you to use and build upon these powerful time-saving constructs you already know how to use? Command shells unlock the potential of a UNIX system, and bash is the Linux shell. It's the high-level glue between you and the machine. Grow in your knowledge of bash, and you'll automatically increase your productivity under Linux and UNIX -- it's that simple. </p> </body> </section> <section> <title>Bash confusion</title> <body> <p> Learning bash the wrong way can be a very confusing process. Many newbies type <c>man bash</c> to view the bash man page, only to be confronted with a very terse and technical description of shell functionality. Others type <c>info bash</c> (to view the GNU info documentation), causing either the man page to be redisplayed, or (if they are lucky) only slightly more friendly info documentation to appear. </p> <p> While this may be somewhat disappointing to novices, the standard bash documentation can't be all things to all people, and caters towards those already familiar with shell programming in general. There's definitely a lot of excellent technical information in the man page, but its helpfulness to beginners is limited. </p> <p> That's where this series comes in. In it, I'll show you how to actually use bash programming constructs, so that you will be able to write your own scripts. Instead of technical descriptions, I'll provide you with explanations in plain English, so that you will know not only what something does, but when you should actually use it. By the end of this three-part series, you'll be able to write your own intricate bash scripts, and be at the level where you can comfortably use bash and supplement your knowledge by reading (and understanding!) the standard bash documentation. Let's begin. </p> </body> </section> <section> <title>Environment variables</title> <body> <p> Under bash and almost all other shells, the user can define environment variables, which are stored internally as ASCII strings. One of the handiest things about environment variables is that they are a standard part of the UNIX process model. This means that environment variables not only are exclusive to shell scripts, but can be used by standard compiled programs as well. When we "export" an environment variable under bash, any subsequent program that we run can read our setting, whether it is a shell script or not. A good example is the <c>vipw</c> command, which normally allows root to edit the system password file. By setting the <c>EDITOR</c> environment variable to the name of your favorite text editor, you can configure vipw to use it instead of vi, a handy thing if you are used to xemacs and really dislike vi. </p> <p> The standard way to define an environment variable under bash is: </p> <pre caption="Defining environment variable"> $ <i>myvar='This is my environment variable!'</i> </pre> <p> The above command defined an environment variable called "myvar" and contains the string "This is my environment variable!". There are several things to notice above: first, there is no space on either side of the "=" sign; any space will result in an error (try it and see). The second thing to notice is that while we could have done away with the quotes if we were defining a single word, they are necessary when the value of the environment variable is more than a single word (contains spaces or tabs). </p> <note> For extremely detailed information on how quotes should be used in bash, you may want to look at the "QUOTING" section in the bash man page. The existence of special character sequences that get "expanded" (replaced) with other values does complicate how strings are handled in bash. We will just cover the most often-used quoting functionality in this series. </note> <p> Thirdly, while we can normally use double quotes instead of single quotes, doing so in the above example would have caused an error. Why? Because using single quotes disables a bash feature called expansion, where special characters and sequences of characters are replaced with values. For example, the "!" character is the history expansion character, which bash normally replaces with a previously-typed command. (We won't be covering history expansion in this series of articles, because it is not frequently used in bash programming. For more information on it, see the "HISTORY EXPANSION" section in the bash man page.) While this macro-like functionality can come in handy, right now we want a literal exclamation point at the end of our environment variable, rather than a macro. </p> <p> Now, let's take a look at how one actually uses environment variables. Here's an example: </p> <pre caption="Using environment variables"> $ <i>echo $myvar</i> This is my environment variable! </pre> <p> By preceding the name of our environment variable with a $, we can cause bash to replace it with the value of myvar. In bash terminology, this is called "variable expansion". But, what if we try the following: </p> <pre caption="First try to use variable expansion"> $ <i>echo foo$myvarbar</i> foo -- [email protected] mailing list
