| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html401/loose.dtd"> |
| <html> |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| <head> |
| <title>CentOS Artwork Repository: 2.61 The trunk/Scripts/Functions Directory</title> |
| |
| <meta name="description" content="CentOS Artwork Repository: 2.61 The trunk/Scripts/Functions Directory"> |
| <meta name="keywords" content="CentOS Artwork Repository: 2.61 The trunk/Scripts/Functions Directory"> |
| <meta name="resource-type" content="document"> |
| <meta name="distribution" content="global"> |
| <meta name="Generator" content="texi2html 1.76"> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| <style type="text/css"> |
| <!-- |
| @import "/home/centos/artwork/trunk/Identity/Manual/repository.css"; |
| |
| a.summary-letter {text-decoration: none} |
| pre.display {font-family: serif} |
| pre.format {font-family: serif} |
| pre.menu-comment {font-family: serif} |
| pre.menu-preformatted {font-family: serif} |
| pre.smalldisplay {font-family: serif; font-size: smaller} |
| pre.smallexample {font-size: smaller} |
| pre.smallformat {font-family: serif; font-size: smaller} |
| pre.smalllisp {font-size: smaller} |
| span.sansserif {font-family:sans-serif; font-weight:normal;} |
| ul.toc {list-style: none} |
| --> |
| </style> |
| |
| |
| </head> |
| |
| <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> |
| |
| <table cellpadding="1" cellspacing="1" border="0"> |
| <tr><td valign="middle" align="left">[<a href="repository_67.html#SEC333" title="Previous section in reading order"> < </a>]</td> |
| <td valign="middle" align="left">[<a href="#SEC335" title="Next section in reading order"> > </a>]</td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left">[<a href="repository_7.html#SEC12" title="Beginning of this chapter or previous chapter"> << </a>]</td> |
| <td valign="middle" align="left">[<a href="repository_7.html#SEC12" title="Up section"> Up </a>]</td> |
| <td valign="middle" align="left">[<a href="repository_80.html#SEC416" title="Next chapter"> >> </a>]</td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left">[<a href="repository.html#SEC_Top" title="Cover (top) of document">Top</a>]</td> |
| <td valign="middle" align="left">[<a href="repository_toc.html#SEC_Contents" title="Table of contents">Contents</a>]</td> |
| <td valign="middle" align="left">[<a href="repository_80.html#SEC416" title="Index">Index</a>]</td> |
| <td valign="middle" align="left">[<a href="repository_abt.html#SEC_About" title="About (help)"> ? </a>]</td> |
| </tr></table> |
| <a name="Directories-trunk-Scripts-Functions"></a> |
| <a name="SEC334"></a> |
| <h2 class="section"> 2.61 The <tt>`trunk/Scripts/Functions'</tt> Directory </h2> |
| |
| |
| <a name="SEC335"></a> |
| <h3 class="subsection"> 2.61.1 Goals </h3> |
| |
| <p>The <tt>`trunk/Scripts/Bash/Functions'</tt> directory exists to organize |
| <tt>`centos-art.sh'</tt> specific functionalities. |
| </p> |
| |
| <a name="SEC336"></a> |
| <h3 class="subsection"> 2.61.2 Description </h3> |
| |
| <p>The specific functions of <tt>`centos-art.sh'</tt> script are designed |
| with "Software Toolbox" philosophy (see <a href="../coreutils/Toolbox-introduction.html#Toolbox-introduction">(coreutils.info)Toolbox introduction</a>) in mind: each program "should do one |
| thing well". Inside <tt>`centos-art.sh'</tt> script, each specific |
| functionality is considered a program that should do one thing well. |
| Of course, if you find that they still don't do it, feel free to |
| improve them in order for them to do so. |
| </p> |
| <p>The specific functions of <tt>`centos-art.sh'</tt> script are organized |
| inside specific directories under <tt>`trunk/Scripts/Bash/Functions'</tt> |
| location. Each specific function directory should be named as the |
| function it represents, with the first letter in uppercase. For |
| example, if the function name is <code>render</code>, the specific function |
| directory for it would be <samp>`trunk/Scripts/Bash/Functions/Render'</samp>. |
| </p> |
| <p>To better understand how specific functions of <tt>`centos-art.sh'</tt> |
| script are designed, lets create one function which only goal is to |
| output different kind of greetings to your screen. |
| </p> |
| <p>When we create specific functions for <tt>`centos-art.sh'</tt> script it |
| is crucial to know what these functions will do exactly and if there |
| is any function that already does what we intend to do. If there is no |
| one, it is good time to create them then. Otherwise, if |
| functionalities already available don't do what you exactly expect, |
| contact their authors and work together to improve them. |
| </p> |
| <blockquote class="orange"><img src="/home/centos/artwork/trunk/Identity/Images/Webenv/icon-admonition-idea.png" alt="Info"><h3>Tip</h3><p> Join CentOS developers mailing list |
| <a class="mailto" href="mailto:centos-art@centos.org">centos-art@centos.org</a> to share your ideas. |
| </p></blockquote> |
| |
| <p>It is also worth to know what global functions and variables do we |
| have available inside <tt>`centos-art.sh'</tt> script, so advantage can be |
| taken from them. Global variables are defined inside global function |
| scripts. Global functions scripts are stored immediatly under |
| <tt>`trunk/Scripts/Bash/Functions'</tt> directory, in files begining with |
| <samp>`cli'</samp> prefix. |
| </p> |
| <p>OK, let's begin with our functionality example. |
| </p> |
| <p>What function name do we use? Well, lets use <code>greet</code>. Note that |
| <samp>`hello'</samp> word is not a verb; but an expression, a kind of |
| greeting, an interjection specifically. In contrast, <samp>`greet'</samp> is a |
| verb and describes what we do when we say <samp>`Hello!'</samp>, <samp>`Hi!'</samp>, |
| and similar expressions. |
| </p> |
| <p>So far, we've gathered the following function information: |
| </p> |
| <pre class="verbatim">Name: greet |
| Path: trunk/Scripts/Bash/Functions/Greet |
| File: trunk/Scripts/Bash/Functions/Greet/greet.sh |
| </pre> |
| <p>The <tt>`greet.sh'</tt> function script is the first file |
| <tt>`centos-art.sh'</tt> script loads when the <samp>`greet'</samp> functionality |
| is called using commands like <samp>`centos-art greet --hello='World''</samp>. |
| The <tt>`greet.sh'</tt> function script contains the <code>greet</code> function |
| definition. |
| </p> |
| <p>Inside <tt>`centos-art.sh'</tt> script, as convenction, each function |
| script has one top commentary, followed by one blank line, and then |
| one function defintion below it only. |
| </p> |
| <p>Inside <tt>`centos-art.sh'</tt> script functions, top commentaries have |
| the following components: the functionality description, one-line for |
| copyright note with your personal information, the license under |
| which the function source code is released --the <tt>`centos-art.sh'</tt> |
| script is released as GPL, so do all its functions--, the <code>$Id$</code> |
| keyword of Subversion is later expanded by <code>svn propset</code> |
| command. |
| </p> |
| <p>In our <code>greet</code> function example, top commentary for |
| <tt>`greet.sh'</tt> function script would look like the following: |
| </p> |
| <pre class="verbatim">#!/bin/bash |
| # |
| # greet.sh -- This function outputs different kind of greetings to |
| # your screen. Use this function to understand how centos-art.sh |
| # script specific functionalities work. |
| # |
| # Copyright (C) YEAR YOURFULLNAME |
| # |
| # This program is free software; you can redistribute it and/or modify |
| # it under the terms of the GNU General Public License as published by |
| # the Free Software Foundation; either version 2 of the License, or |
| # (at your option) any later version. |
| # |
| # This program is distributed in the hope that it will be useful, but |
| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| # General Public License for more details. |
| # |
| # You should have received a copy of the GNU General Public License |
| # along with this program; if not, write to the Free Software |
| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 |
| # USA. |
| # |
| # ---------------------------------------------------------------------- |
| # $Id$ |
| # ---------------------------------------------------------------------- |
| </pre> |
| <p>After top commentary, separated by one blank line, the <code>greet</code> |
| function definition would look like the following: |
| </p> |
| <pre class="verbatim">function greet { |
| |
| # Define global variables. |
| |
| # Define command-line interface. |
| greet_getActions |
| |
| } |
| </pre> |
| <p>The first definition inside <code>greet</code> function, are global |
| variables that will be available along <code>greet</code> function execution |
| environment. This time we didn't use global variable definitions for |
| <code>greet</code> function execution environment, so we left that section |
| empty. |
| </p> |
| <p>Later, we call <code>greet_getActions</code> function to define the |
| command-line interface of <code>greet</code> functionality. The command-line |
| interface of <code>greet</code> functionality defines what and how actions |
| are performed, based on arguments combination passed to |
| <tt>`centos-art.sh'</tt> script. |
| </p> |
| <pre class="verbatim">function greet_getActions { |
| |
| case "$ACTIONNAM" in |
| |
| --hello ) |
| greet_doHello |
| ;; |
| |
| --bye ) |
| greet_doBye |
| ;; |
| |
| * ) |
| cli_printMessage "`gettext "The option provided is not valid."`" |
| cli_printMessage "$(caller)" 'AsToKnowMoreLine' |
| |
| esac |
| |
| } |
| </pre> |
| <p>The <var>ACTIONNAM</var> global variable is defined in <tt>`cli.sh'</tt> |
| function script and contains the value passed before the equal sign |
| (i.e., <samp>`='</samp>) in the second command-line argument of |
| <tt>`centos-art.sh'</tt> script. For example, if the second command-line |
| argument is <samp>`--hello='World''</samp>, the value of <var>ACTIONNAM</var> |
| variable would be <samp>`--hello'</samp>. Using this configuration let us |
| deside which action to perform based on the action name passed to |
| <tt>`centos-art.sh'</tt> script as second argument. |
| </p> |
| <p>The <code>greet</code> function definition makes available two valid |
| greetings through <samp>`--hello'</samp> and <samp>`--bye'</samp> options. If no |
| one of them is provided as second command-line argument, the <samp>`*'</samp> |
| case is evaluated instead. |
| </p> |
| <p>The <samp>`*'</samp> case and its two lines further on should always be |
| present in <tt>`_getActions.sh'</tt> function scripts, no matter what |
| specific functionality you are creating. This convenction helps the |
| user to find out documentation about current functionality in use, |
| when no valid action is provided. |
| </p> |
| <p>The <code>greet_doHello</code> and <code>greet_doBye</code> function definitions |
| are the core of <code>greet</code> specific functionality. In such function |
| definitions we set what our <code>greet</code> function really does: to |
| output different kinds of greetings. |
| </p> |
| <pre class="verbatim">function greet_doHello { |
| |
| cli_printMessage "`gettext "Hello"` $ACTIONVAL" |
| |
| } |
| </pre> |
| <p>The <code>greet_doHello</code> function definition is stored in |
| <tt>`greet_doHello.sh'</tt> function script. |
| </p> |
| <pre class="verbatim">function greet_doBye { |
| |
| cli_printMessage "`gettext "Goodbye"` $ACTIONVAL" |
| |
| } |
| </pre> |
| <p>The <code>greet_doBye</code> function definition is stored in the |
| <tt>`greet_doBye.sh'</tt> function script. |
| </p> |
| <p>Both <tt>`greet_doHello.sh'</tt> and <tt>`greet_doBye.sh'</tt> function |
| scripts are stored inside <code>greet</code> function directory path (i.e. |
| <tt>`trunk/Scripts/Bash/Functions/Greet'</tt>). |
| </p> |
| <p>The <var>ACTIONVAL</var> global variable is defined in <tt>`cli.sh'</tt> |
| function script and contains the value passed after the equal sign |
| (i.e., <samp>`='</samp>) in the second command-line argument of |
| <tt>`centos-art.sh'</tt> script. For example, if the second command-line |
| argument is <samp>`--hello='World''</samp>, the value of <var>ACTIONVAL</var> |
| variable would be <samp>`World'</samp> without quotes. |
| </p> |
| <p>Let's see how <code>greet</code> specific functionality files are organzied |
| under <code>greet</code> function directory. To see file organization we use |
| the <code>tree</code> command: |
| </p> |
| <pre class="verbatim">trunk/Scripts/Bash/Functions/Greet |
| |-- greet_doBye.sh |
| |-- greet_doHello.sh |
| |-- greet_getActions.sh |
| `-- greet.sh |
| </pre> |
| <p>To try the <code>greet</code> specific functionality we've just created, |
| pass the function name (i.e., <samp>`greet'</samp>) as first argument to |
| <tt>`centos-art.sh'</tt> script, and any of the valid options as second |
| argument. Some examples are illustrated below: |
| </p> |
| <pre class="verbatim">[centos@projects ~]$ centos-art greet --hello='World' |
| Hello World |
| [centos@projects ~]$ centos-art greet --bye='World' |
| Goodbye World |
| [centos@projects ~]$ |
| </pre> |
| <p>The word <samp>`World'</samp> in the examples above can be anything. In fact, |
| change it to have a little fun. |
| </p> |
| <p>Now that we have a specific function that works as we expect, it is |
| time to document it. To document <code>greet</code> specific functionality, |
| we use its directory path and the <code>manual</code> functionality |
| (-- <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Manual) --) of <tt>`centos-art.sh'</tt> |
| script, just as the following command illustrates: |
| </p> |
| <pre class="verbatim">centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet |
| </pre> |
| <p>To have a well documented function helps user to understand how your |
| function really works, and how it should be used. When no valid |
| action is passed to a function, the <tt>`centos-art.sh'</tt> script uses |
| the function documentation entry as vehicle to communicate which the |
| valid functions are. When no documentation entry exists for a |
| function, the <tt>`centos-art.sh'</tt> script informs that no |
| documentation entry exists for such function and requests user to |
| create it right at that time. |
| </p> |
| <p>Now that we have documented our function, it is time to translate its |
| output messages to different languages. To translate specific |
| functionality output messages to different languages we use the |
| <code>locale</code> functionality (-- <strong>Removed</strong>(pxref:trunk Scripts Bash Functions |
| Locale) --) of <tt>`centos-art.sh'</tt> script, just as the following command |
| illustrates: |
| </p> |
| <pre class="verbatim">centos-art locale --edit |
| </pre> |
| <blockquote class="orange"><img src="/home/centos/artwork/trunk/Identity/Images/Webenv/icon-admonition-alert.png" alt="Warning"><h3>Warning</h3><p> To translate output messages in different languages, |
| your system locale information --as in <code>LANG</code> environment |
| variable-- must be set to that locale you want to produce translated |
| messages for. For example, if you want to produce translated messages |
| for Spanish language, your system locale information must be set to |
| <samp>`es_ES.UTF-8'</samp>, or similar, first. |
| </p></blockquote> |
| |
| <p>Well, it seems that our example is rather complete by now. |
| </p> |
| <p>In <code>greet</code> function example we've described so far, we only use |
| <code>cli_printMessage</code> global function in action specific function |
| definitions in order to print messages, but more interesting things |
| can be achieved inside action specific function definitions. For |
| example, if you pass a directory path as action value in second |
| argument, you could retrive a list of files from therein, and process |
| them. If the list of files turns too long or you just want to control |
| which files to process, you could add the third argument in the form |
| <samp>`--filter='regex''</samp> and reduce the amount of files to process |
| using a regular expression pattern. |
| </p> |
| <p>The <code>greet</code> function described in this section may serve you as |
| an introduction to understand how specific functionalities work inside |
| <tt>`centos-art.sh'</tt> script. With some of luck this introduction will |
| also serve you as motivation to create your own <tt>`centos-art.sh'</tt> |
| script specific functionalities. |
| </p> |
| <p>By the way, the <code>greet</code> functionality doesn't exist inside |
| <tt>`centos-art.sh'</tt> script yet. Would you like to create it? |
| </p> |
| |
| <a name="SEC337"></a> |
| <h3 class="subsection"> 2.61.3 Usage </h3> |
| |
| |
| <a name="SEC338"></a> |
| <h4 class="subsubsection"> 2.61.3.1 Global variables </h4> |
| |
| <p>The following global variables of <tt>`centos-art.sh'</tt> script, are |
| available for you to use inside specific functions: |
| </p> |
| <dl> |
| <dt><u>Variable:</u> <b>TEXTDOMAIN</b> |
| <a name="IDX1"></a> |
| </dt> |
| <dd><p>Default domain used to retrieve translated messages. This value is set |
| in <tt>`initFunctions.sh'</tt> and shouldn't be changed. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>TEXTDOMAINDIR</b> |
| <a name="IDX2"></a> |
| </dt> |
| <dd><p>Default directory used to retrieve translated messages. This value is |
| set in <tt>`initFunctions.sh'</tt> and shouldn't be changed. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>FUNCNAM</b> |
| <a name="IDX3"></a> |
| </dt> |
| <dd><p>Define function name. |
| </p> |
| <p>Function names associate sets of actions. There is one set of actions |
| for each unique function name inside <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>Dunction names are passed as first argument in <tt>`centos-art.sh'</tt> |
| command-line interface. For example, in the command <samp>`centos-art |
| render --entry=path/to/dir --filter=regex'</samp>, the <var>ACTION</var> passed to |
| <tt>`centos-art.sh'</tt> script is <samp>`render'</samp>. |
| </p> |
| <p>When first argument is not provided, the <tt>`centos-art.sh'</tt> script |
| immediatly ends its execution. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>FUNCDIR</b> |
| <a name="IDX4"></a> |
| </dt> |
| </dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>FUNCDIRNAME</b> |
| <a name="IDX5"></a> |
| </dt> |
| </dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>FUNCSCRIPT</b> |
| <a name="IDX6"></a> |
| </dt> |
| </dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>FUNCCONFIG</b> |
| <a name="IDX7"></a> |
| </dt> |
| </dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>ACTIONNAM</b> |
| <a name="IDX8"></a> |
| </dt> |
| <dd><p>Define action name. |
| </p> |
| <p>Each action name identifies an specific action to perform, inside an |
| specific function. |
| </p> |
| <p>Action name names aare passed as second argument in |
| <tt>`centos-art.sh'</tt> command-line interface. For example, in the |
| command <samp>`centos-art render --entry=path/to/dir --filter=regex'</samp>, |
| the <var>ACTIONNAM</var> passed to <tt>`centos-art.sh'</tt> script is |
| <samp>`--entry'</samp>. |
| </p> |
| <p>When second argument is not provided, the <tt>`centos-art.sh'</tt> script |
| immediatly ends its execution. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>ACTIONVAL</b> |
| <a name="IDX9"></a> |
| </dt> |
| <dd><p>Define action value. |
| </p> |
| <p>Action values are associated to just one action name. Action values |
| contain the working copy entry over which its associated action will be |
| performed in. Working copy entries can be files or directories inside |
| the working copy. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>REGEX</b> |
| <a name="IDX10"></a> |
| </dt> |
| <dd><p>Define regular expression used as pattern to build the list of files |
| to process. |
| </p> |
| <p>By default, <var>REGEX</var> variable is set to <code>.+</code> to match all |
| files. |
| </p> |
| <p>Functions that need to build a list of files to process use the option |
| <samp>`--filter'</samp> to redefine <var>REGEX</var> variable default value, and |
| so, control the amount of files to process. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>ARGUMENTS</b> |
| <a name="IDX11"></a> |
| </dt> |
| <dd><p>Define optional arguments. |
| </p> |
| <p>Optional arguments, inside <tt>`centos-art.sh'</tt> script, are considered |
| as all command-line arguments passed to <tt>`centos-art.sh'</tt> script, |
| from third argument position on. For example, in the command |
| <samp>`centos-art render --entry=path/to/dir --filter=regex'</samp> , the |
| optional arguments are from <samp>`--filter=regex'</samp> argument on. |
| </p> |
| <p>Optional arguments are parsed using <code>getopt</code> command through |
| the following base construction: |
| </p> |
| <pre class="verbatim"># Define short options we want to support. |
| local ARGSS="" |
| |
| # Define long options we want to support. |
| local ARGSL="filter:,to:" |
| |
| # Parse arguments using getopt(1) command parser. |
| cli_doParseArguments |
| |
| # Reset positional parameters using output from (getopt) argument |
| # parser. |
| eval set -- "$ARGUMENTS" |
| |
| # Define action to take for each option passed. |
| while true; do |
| case "$1" in |
| --filter ) |
| REGEX="$2" |
| shift 2 |
| ;; |
| --to ) |
| TARGET="$2" |
| shift 2 |
| ;; |
| * ) |
| break |
| esac |
| done |
| </pre> |
| <p>Optional arguments provide support to command options inside |
| <tt>`centos-art.sh'</tt> script. For instance, consider the Subversion |
| (<code>svn</code>) command, where there are many options (e.g., |
| <samp>`copy'</samp>, <samp>`delete'</samp>, <samp>`move'</samp>, etc), and inside each |
| option there are several modifiers (e.g., <samp>`--revision'</samp>, |
| <samp>`--message'</samp>, <samp>`--username'</samp>, etc.) that can be combined one |
| another in their short or long variants. |
| </p> |
| <p>The <var>ARGUMENTS</var> variable is used to store arguments passed from |
| command-line for later use inside <tt>`centos-art.sh'</tt> script. Storing |
| arguments is specially useful when we want to run a command with some |
| specific options from them. Consider the following command: |
| </p> |
| <pre class="verbatim">centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe' |
| </pre> |
| <p>In the above command, the <samp>`--message'</samp>, and <samp>`--username'</samp> |
| options are specific to <code>svn copy</code> command. In such cases, |
| options are not interpreted by <tt>`centos-art.sh'</tt> script itself. |
| Instead, the <tt>`centos-art.sh'</tt> script uses <code>getopt</code> to |
| retrive them and store them in the <var>ARGUMENTS</var> variable for later |
| use, as described in the following command: |
| </p> |
| <pre class="verbatim"># Build subversion command to duplicate locations inside the |
| # workstation. |
| eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS |
| </pre> |
| <p>When <code>getopt</code> parses <var>ARGUMENTS</var>, we may use short options |
| (e.g., <samp>`-m'</samp>) or long options (e.g., <samp>`--message'</samp>). When |
| we use short options, arguments are separated by one space from the |
| option (e.g., <samp>`-m 'This is a commit message.''</samp>). When we use |
| long options arguments are separated by an equal sign (<samp>`='</samp>) |
| (e.g., <samp>`--message='This is a commit message''</samp>). |
| </p> |
| <p>In order for <code>getopt</code> to parse <var>ARGUMENTS</var> correctly, it |
| is required to provide the short and long definition of options that |
| will be passed or at least supported by the command performing the |
| final action the function script exists for. |
| </p> |
| <p>As convenction, inside <tt>`centos-art.sh'</tt> script, short option |
| definitions are set in the <var>ARGSS</var> variable; and long option |
| definitions are set in the <var>ARGSL</var> variable. |
| </p> |
| <p>When you define short and long options, it may be needed to define |
| which of these option arguments are required and which not. To define |
| an option argument as required, you need to set one colon <samp>`:'</samp> |
| after the option definition (e.g., <samp>`-o m: -l message:'</samp>). On |
| the other hand, to define an option argument as not required, you need |
| to set two colons <samp>`::'</samp> after the option definition (e.g., |
| <samp>`-o m:: -l message::'</samp>). |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Variable:</u> <b>EDITOR</b> |
| <a name="IDX12"></a> |
| </dt> |
| <dd><p>Default text editor. |
| </p> |
| <p>The <tt>`centos-art.sh'</tt> script uses default text <code>EDITOR</code> to edit |
| pre-commit subversion messages, translation files, configuration |
| files, script files, and similar text-based files. |
| </p> |
| <p>If <code>EDITOR</code> environment variable is not set, <tt>`centos-art.sh'</tt> |
| script uses <tt>`/usr/bin/vim'</tt> as default text editor. Otherwise, the |
| following values are recognized by <tt>`centos-art.sh'</tt> script: |
| </p> |
| <ul class="toc"> |
| <li> <tt>`/usr/bin/vim'</tt> |
| </li><li> <tt>`/usr/bin/emacs'</tt> |
| </li><li> <tt>`/usr/bin/nano'</tt> |
| </li></ul> |
| |
| <p>If no one of these values is set in <code>EDITOR</code> environment variable, |
| <tt>`centos-art.sh'</tt> uses <tt>`/usr/bin/vim'</tt> text editor by default. |
| </p></dd></dl> |
| |
| |
| <a name="SEC339"></a> |
| <h4 class="subsubsection"> 2.61.3.2 Global functions </h4> |
| |
| <p>Function scripts stored directly under |
| <tt>`trunk/Scripts/Bash/Functions/'</tt> directory are used to define |
| global functions. Global functions can be used inside action specific |
| functionalities and or even be reused inside themselves. This section |
| provides introductory information to global functions you can use |
| inside <tt>`centos-art.sh'</tt> script. |
| </p> |
| <dl> |
| <dt><u>Function:</u> <b>cli_checkActionArguments</b> |
| <a name="IDX13"></a> |
| </dt> |
| <dd><p>Validate action value (<var>ACTIONVAL</var>) variable. |
| </p> |
| <p>The action value variable can take one of the following values: |
| </p> |
| <ol> |
| <li> Path to one directory inside the local working copy, |
| </li><li> Path to one file inside the local working copy, |
| </li></ol> |
| |
| <p>If another value different from that specified above is passed to |
| action value variable, the <tt>`centos-art.sh'</tt> script prints an error |
| message and ends script execution. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_checkFiles</b><i> FILE [TYPE]</i> |
| <a name="IDX14"></a> |
| </dt> |
| <dd><p>Verify file existence. |
| </p> |
| <p><code>cli_checkFiles</code> receives a <var>FILE</var> absolute path and performs |
| file verification as specified in <var>TYPE</var>. When <var>TYPE</var> is not |
| specified, <code>cli_checkFiles</code> verifies <var>FILE</var> existence, no |
| matter what kind of file it be. If <var>TYPE</var> is specified, use one |
| of the following values: |
| </p> |
| <dl compact="compact"> |
| <dt> <samp>`d'</samp></dt> |
| <dt> <samp>`directory'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is not a directory. |
| </p> |
| <p>When you verify directories with cli_checkFiles, if directory doesn't |
| exist, <tt>`centos-art.sh'</tt> script asks you for confirmation in order |
| to create that directory. If you answer positively, |
| <tt>`centos-art.sh'</tt> script creates that directory and continues |
| script flows normally. Otherwise, if you answer negatively, |
| <tt>`centos-art.sh'</tt> ends script execution with an error and |
| documentation message. |
| </p> |
| </dd> |
| <dt> <samp>`f'</samp></dt> |
| <dt> <samp>`regular-file'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is not a regular file. |
| </p></dd> |
| <dt> <samp>`h'</samp></dt> |
| <dt> <samp>`symbolic-link'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is not a symbolic link. |
| </p></dd> |
| <dt> <samp>`x'</samp></dt> |
| <dt> <samp>`execution'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is not executable. |
| </p></dd> |
| <dt> <samp>`fh'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is neither a regular file nor a |
| symbolic link. |
| </p></dd> |
| <dt> <samp>`fd'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is neither a regular file nor a |
| directory. |
| </p></dd> |
| <dt> <samp>`isInWorkingCopy'</samp></dt> |
| <dd><p>Ends script execution if <var>FILE</var> is not inside the working copy. |
| </p></dd> |
| </dl> |
| |
| <p>As default behaviour, if <var>FILE</var> passes all verifications, |
| <tt>`centos-art.sh'</tt> script continues with its normal flow. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_commitRepoChanges</b><i> [LOCATION]</i> |
| <a name="IDX15"></a> |
| </dt> |
| <dd><p>Syncronize changes between repository and working copy. |
| </p> |
| <p>The <code>cli_commitRepoChanges</code> function brings changes from the |
| central repository down to the working copy--using <code>svn |
| update</code>--, checks the working copy changes--using <code>svn |
| status</code> command--, prints status report--using both <code>svn |
| update</code> and <code>svn status</code> commands output, and finally, commits |
| recent changes from the working copy up to the repository--using |
| <code>svn commit</code> command--. |
| </p> |
| <p>Previous to commit the working copy changes up to the central |
| repository, the <code>cli_commitRepoChanges</code> function asks you to |
| verify changes--using <code>svn diff</code> command--, and later, |
| another confirmation question is shown to be sure you really want to |
| commit changes up to central repository. |
| </p> |
| <p>If <var>LOCATION</var> argument is not specified, the value of |
| <var>ACTIONVAL</var> variable is used as reference instead. |
| </p> |
| <div class="float"><a name="trunk_002fScripts_002fBash_002fFunctions_002fcli_005fcommitRepoChanges"></a> |
| <pre class="verbatim">---------------------------------------------------------------------- |
| --> Bringing changes from the repository into the working copy |
| --> Checking changes in the working copy |
| ---------------------------------------------------------------------- |
| Added 0 file from the repository. |
| Deleted 0 file from the repository. |
| Updated 0 file from the repository. |
| Conflicted 0 file from the repository. |
| Merged 0 file from the repository. |
| Modified 4 files from the working copy. |
| Unversioned 0 file from the working copy. |
| Deleted 0 file from the working copy. |
| Added 0 file from the working copy. |
| ---------------------------------------------------------------------- |
| </pre> |
| </div><p><strong>Figure 2.3: The <code>cli_commitRepoChanges</code> function output. |
| </strong> |
| </p> |
| <p>Call the <code>cli_commitRepoChanges</code> function before or/and after |
| calling functions that modify files or directories inside the working |
| copy as you may need to. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_doParseArguments</b> |
| <a name="IDX16"></a> |
| </dt> |
| <dd><p>Redefine arguments (<var>ARGUMENTS</var>) global variable using |
| <code>getopt</code> command output. For more information about how to use |
| <code>cli_doParseArguments</code> function, see <var>ARGUMENTS</var> variable |
| description above. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_doParseArgumentsReDef</b><i> $@</i> |
| <a name="IDX17"></a> |
| </dt> |
| <dd><p>Initialize/reset arguments (<var>ARGUMENTS</var>) global variable using |
| positional parameters variable (<var>$@</var>) as reference. |
| </p> |
| <p>When we work inside function definitions, positional parameters are |
| reset to the last function definition positional parameters. If you |
| need to redefine positional parameters from one specific function, you |
| need to call <code>cli_doParseArgumentsReDef</code> with the positional |
| parameters variable (<var>$@</var>), set as first argument, to that |
| specific function you want to redefine positional parameters at. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getArguments</b> |
| <a name="IDX18"></a> |
| </dt> |
| <dd><p>Initialize function name (<var>FUNCNAM</var>), action name |
| (<var>ACTIONNAM</var>), and action value (<var>ACTIONVAL</var>) global |
| variables, using positional parameters passed in <var>$@</var> variable. |
| </p> |
| <p>The <code>cli_getArguments</code> function is called from <code>cli.sh</code> |
| function script, using <code>cli</code> function positional parameters |
| (i.e., the positional parameters passed as arguments in the |
| command-line) as first function argument. |
| </p> |
| <p>Once command-line positional parameters are accesible to |
| <tt>`centos-art.sh'</tt> script execution evironment, |
| <code>cli_getArguments</code> uses regular expression to retrive |
| action variables from first and second argument. The first argument |
| defines the value used as function name (<var>FUNCNAM</var>), and the |
| second argument defines both values used as action name |
| (<var>ACTIONNAM</var>) and action value (<var>ACTIONVAL</var>), respectively. |
| </p> |
| <p>The first argument is a word in lower case. This word specifies the |
| name of the functionality you want to use (e.g., <samp>`render'</samp> to |
| render images, <samp>`manual'</samp> to work on documentation, and so on.) |
| </p> |
| <p>The second argument has a long option style (e.g., |
| <samp>`--option=value'</samp>). The <samp>`--option'</samp> represents the action name |
| (<var>ACTIONNAM</var>), and the characters inbetween the equal sign |
| (<samp>`='</samp>) and the first space character, are considered as the action |
| value (<var>ACTIONVAL</var>). In order to provide action values with space |
| characters inbetween you need to enclose action value with quotes like |
| in <samp>`--option='This is long value with spaces inbetween''</samp>. |
| Generally, action values are used to specify paths over which the |
| action name acts on. |
| </p> |
| <p>Once action related variables (i.e., <var>FUNCNAM</var>, <var>ACTIONNAM</var>, |
| and <var>ACTIONVAL</var>) are defined and validated, |
| <code>cli_getArguments</code> shifts the positional arguments to remove the |
| first two arguments passed (i.e., those used to retrive action related |
| variables) and redefine the arguments (<var>ARGUMENTS</var>) global |
| variable with the new positional parameters information. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getFunctions</b> |
| <a name="IDX19"></a> |
| </dt> |
| <dd><p>Initialize funtionalities supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>Functionalities supported by <tt>`centos-art.sh'</tt> script are organized |
| in functionality directories under |
| <tt>`trunk/Scripts/Bash/Functions/'</tt> directory. Each functionality |
| directory stores function scripts to the functionality such directory |
| was created for. Function scripts contain function definitions. |
| Function definitions contain several commands focused on achieving one |
| specific task only (i.e., the one such functionality was created for). |
| </p> |
| <p>In order for <tt>`centos-art.sh'</tt> script to recognize a functionality, |
| such functionality needs to be stored under |
| <tt>`trunk/Scripts/Bash/Functions/'</tt> in a directory written |
| capitalized (i.e., the whole name is written in lowercase except the |
| first character which is in uppercase). The directory where one |
| specific functionality is stored is known as the <samp>`functionality |
| directory'</samp>. |
| </p> |
| <p>Inside each functionality directory, the functionalty itself is |
| implemented through function scripts. Function scripts are organized |
| in files independently one another and written in <samp>`camelCase'</samp> |
| format with the function name as prefix. Separation between prefix |
| and description is done using underscore (<samp>`_'</samp>) character. |
| </p> |
| <p>In order for <tt>`centos-art.sh'</tt> script to load functionalities |
| correctly, function definition inside function scripts should be set |
| using the <samp>`function'</samp> reserved word, just as in the following |
| example: |
| </p> |
| <pre class="verbatim">function prefix_doSomething { |
| |
| # Do something here... |
| |
| } |
| </pre> |
| <p>The above function definition is just a convenction we use, in order |
| to make identification of function names easier read and automate by |
| <tt>`centos-art.sh'</tt> script initialization commands, once |
| <tt>`centos-art.sh'</tt> script determines which functionality directory |
| to use. Specifically, in order to initialize and export functions, |
| <tt>`centos-art.sh'</tt> script executes all function scripts inside the |
| functionality directory, and later <code>grep</code> on them using a |
| regular expression pattern, where the <samp>`function'</samp> reserved word is |
| used as reference to retrive the function names and export them to |
| <tt>`centos-art.sh'</tt> script execution environment, and so, make |
| function definitions --from function scripts inside the functionality |
| directory-- available for further calls. |
| </p> |
| <p>If the functionality specified in the command-line first argument |
| doesn't have a functionality directory, <tt>`centos-art.sh'</tt> script |
| considers the functionality provided in the command-line as invalid |
| functionality and immediatly stops script execution with an error |
| message. |
| </p> |
| <p>In order to keep visual consistency among function scripts, please |
| consider using the following function script design model as template |
| for your own function scripts: |
| </p> |
| <pre class="verbatim">#!/bin/bash |
| # |
| # prefix_doSomething.sh -- This function illustrates function scripts |
| # design model you can use to create your own function scripts inside |
| # centos-art.sh script. |
| # |
| # Copyright (C) YEAR YOURFULLNAME |
| # |
| # This program is free software; you can redistribute it and/or modify |
| # it under the terms of the GNU General Public License as published by |
| # the Free Software Foundation; either version 2 of the License, or |
| # (at your option) any later version. |
| # |
| # This program is distributed in the hope that it will be useful, but |
| # WITHOUT ANY WARRANTY; without even the implied warranty of |
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| # General Public License for more details. |
| # |
| # You should have received a copy of the GNU General Public License |
| # along with this program; if not, write to the Free Software |
| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 |
| # USA. |
| # |
| # ---------------------------------------------------------------------- |
| # $Id$ |
| # ---------------------------------------------------------------------- |
| |
| function prefix_doSomething { |
| |
| # Do something here... |
| |
| } |
| </pre></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getCountryCodes</b><i> [FILTER]</i> |
| <a name="IDX20"></a> |
| </dt> |
| <dd><p>Output country codes supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>The <code>cli_getCountryCodes</code> function outputs a list with country |
| codes as defined in ISO3166 standard. When <var>FILTER</var> is provided, |
| <code>cli_getCountryCodes</code> outputs country codes that match |
| <var>FILTER</var> regular expression pattern. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getCountryName</b><i> [FILTER]</i> |
| <a name="IDX21"></a> |
| </dt> |
| <dd><p>Outputs country name supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>The <code>cli_getCountryName</code> function reads one language locale code |
| in the format LL_CC and outputs the name of its related country as in |
| ISO3166. If filter is specified, <code>cli_getCountryName</code> returns the |
| country name that matches the locale code specified in <var>FILTER</var>, |
| exactly. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getCurrentLocale</b> |
| <a name="IDX22"></a> |
| </dt> |
| <dd><p>Output current locale used by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>The <code>cli_getCurrentLocale</code> function uses <code>LANG</code> environment |
| variable to build a locale pattern that is later applied to |
| <code>cli_getLocales</code> function output in order to return the current |
| locale that <tt>`centos-art.sh'</tt> script works with. |
| </p> |
| <p>The current locale information, returned by |
| <code>cli_getCurrentLocale</code>, is output from more specific to less |
| specific. For example, if <samp>`en_GB'</samp> locale exists in |
| <code>cli_getLocales</code> function output, the <samp>`en_GB'</samp> locale would |
| take precedence before <samp>`en'</samp> locale. |
| </p> |
| <p>Locale precedence selection is quite important in order to define the |
| locale type we use for message translations. For example, if |
| <samp>`en_GB'</samp> is used, we are also saying that the common language |
| specification for English language (i.e., <samp>`en'</samp>) is no longer |
| used. Instead, we are using English non-common country-specific |
| language specifications like <samp>`en_AU'</samp>, <samp>`en_BW'</samp>, <samp>`en_GB'</samp>, |
| <samp>`en_US'</samp>, etc., for message translations. |
| </p> |
| <p>Use <code>cli_getCurrentLocale</code> function to know what current locale |
| information to use inside <tt>`centos-art.sh'</tt> script. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getFilesList</b><i> [LOCATION]</i> |
| <a name="IDX23"></a> |
| </dt> |
| <dd><p>Output list of files to process. |
| </p> |
| <p>The <code>cli_getFilesList</code> function uses <var>LOCATION</var> variable as |
| source location to build a list of files just as specified by regular |
| expression (<var>REGEX</var>) global variable. Essentially, what the |
| <code>cli_getFilesList</code> function does is using <code>find</code> command |
| to look for files in the location (<var>LOCATION</var>) just as posix-egrep |
| regular expression (<var>REGEX</var>) specifies. |
| </p> |
| <p>If <var>LOCATION</var> is not specified when <code>cli_getFilesList</code> |
| function is called, the action value (<var>ACTIONVAL</var>) global variable |
| is used as location value instead. |
| </p> |
| <p>By default, if the regular expression (<var>REGEX</var>) global variable is |
| not redefined after its first definition in the <code>cli</code> function, |
| all files that match default regular expression value (i.e., |
| <samp>`.+'</samp>) will be added to the list of files to process. Otherwise, |
| if you redefine the regular expression global variable after its first |
| definition in the <code>cli</code> function and before calling |
| <code>cli_getFilesList</code> function, the last value you specifed is used |
| instead. |
| </p> |
| <p>When you need to customize the regular expression (<var>REGEX</var>) global |
| variable value inside a function, do not redefine the global variable |
| (at least you be absolutly convinced you need to). Instead, set the |
| regular expression global variable as <samp>`local'</samp> to the function you |
| need a customized regular expression value for. If we don't redefine |
| the regular expression global variable as local to the function, or |
| use another name for the regular expression variable (which is not |
| very convenient in order to keep the amount of names to remember low), |
| you may experiment undesired concantenation issues that make your |
| regular expression to be something different from that you expect them |
| to be, specially if the function where you are doing the variable |
| redefinition is called several times during the same script execution. |
| </p> |
| <p>As result, the <code>cli_getFilesList</code> re-defines the value of |
| <var>FILES</var> variable with the list of files the <code>find</code> command |
| returned. As example, consider the following construction: |
| </p> |
| <pre class="verbatim">function prefix_doSomething { |
| |
| # Initialize the list of files to process. |
| local FILES='' |
| |
| # Initialize location. |
| local LOCATION=/home/centos/artwork/trunk/Identity/Themes/Models/Default |
| |
| # Re-define regular expression to match scalable vector graphic |
| # files only. Note how we use the global value of REGEX to build a |
| # new local REGEX value here. |
| local REGEX="${REGEX}.*\.(svgz|svg)" |
| |
| # Redefine list of files to process. |
| cli_getFilesList $LOCATION |
| |
| # Process list of files. |
| for FILE in $FILES;do |
| cli_printMessages "$FILE" 'AsResponseLine' |
| # Do something else here on... |
| done |
| |
| } |
| </pre> |
| </dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getLangCodes</b><i> [FILTER]</i> |
| <a name="IDX24"></a> |
| </dt> |
| <dd><p>Outputs language codes supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p><code>cli_getLangCodes</code> function outputs a list of language codes as |
| defined in ISO639 standard. When <var>FILTER</var> is provided, |
| <code>cli_getLangCodes</code> outputs language codes that match <var>FILTER</var> |
| regular expression pattern. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getLangName</b><i> [FILTER]</i> |
| <a name="IDX25"></a> |
| </dt> |
| <dd><p>Outputs language names supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p><code>cli_getLangName</code> function reads one language locale code in the |
| format LL_CC and outputs the language related name as in ISO639. If |
| filter is specified, <code>cli_getLangName</code> returns the language name |
| that matches the locale code specified in <var>FILTER</var>, exactly. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getLocales</b> |
| <a name="IDX26"></a> |
| </dt> |
| <dd><p>Output locale codes supported by <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>Occasionally, you use <code>cli_getLocales</code> function to add locale |
| information in non-common country-specific language (<samp>`LL_CC'</samp>) |
| format for those languages (e.g., <samp>`bn_IN'</samp>, <samp>`pt_BR'</samp>, etc.) |
| which locale differences cannot be solved using common language |
| specifications (<samp>`LL'</samp>) into one unique common locale specification |
| (e.g., <samp>`bn'</samp>, <samp>`pt'</samp>, etc.). |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getRepoName</b><i> NAME TYPE</i> |
| <a name="IDX27"></a> |
| </dt> |
| <dd><p>Sanitate file names. |
| </p> |
| <p>Inside <tt>`centos-art.sh'</tt> script, specific functionalities rely both |
| in <code>cli_getRepoName</code> and repository file system organization to |
| achieve their goals. Consider <code>cli_getRepoName</code> function as |
| central place to manage file name convenctions for other functions |
| inside <tt>`centos-art.sh'</tt> script. |
| </p> |
| <blockquote class="orange"><img src="/home/centos/artwork/trunk/Identity/Images/Webenv/icon-admonition-star.png" alt="Important"><h3>Important</h3><p> <code>cli_getRepoName</code> function doesn't verify file |
| or directory existence, for that purpose use <code>cli_checkFiles</code> |
| function instead. |
| </p></blockquote> |
| |
| <p>The <var>NAME</var> variable contains the file name or directory name you |
| want to sanitate. |
| </p> |
| <p>The <var>TYPE</var> variable specifies what type of sanitation you want to |
| perform on <var>NAME</var>. The <var>TYPE</var> can be one of the following |
| values: |
| </p> |
| <dl compact="compact"> |
| <dt> <samp>`d'</samp></dt> |
| <dt> <samp>`directory'</samp></dt> |
| <dd><p>Sanitate directory <var>NAME</var>s. |
| </p></dd> |
| <dt> <samp>`f'</samp></dt> |
| <dt> <samp>`regular-file'</samp></dt> |
| <dd><p>Sanitate regular file <var>NAME</var>s. |
| </p></dd> |
| </dl> |
| |
| <p>Use <code>cli_getRepoName</code> function to sanitate file names and |
| directory names before their utilization. |
| </p> |
| <p>Use <code>cli_getRepoName</code> when you need to change file name |
| convenctions inside <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>When we change file name convenctions inside <code>cli_getRepoName</code> |
| what we are really changing is the way functions interpret repository |
| file system organization. Notice that when we change a file name |
| (e.g., a function name), it is necessary to update all files where |
| such file name is placed on. This may require a massive substitution |
| inside the repository, each time we change name convenctions in the |
| repository (-- <strong>Removed</strong>(pxref:trunk Scripts Bash Functions Path) --, for more |
| information). |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getRepoStatus</b><i> [LOCATION]</i> |
| <a name="IDX28"></a> |
| </dt> |
| <dd><p>Request repository status. |
| </p> |
| <p>This function requests the status of a <var>LOCATION</var> inside the |
| working copy using the <code>svn status</code> command and returns the |
| first character in the output line, just as described in <code>svn |
| help status</code>. If <var>LOCATION</var> is not a regular file or a directory, |
| inside the working copy, the <tt>`centos-art.sh'</tt> script prints a |
| message and ends its execution. |
| </p> |
| <p>Use this function to perform verifications based a repository |
| <var>LOCATION</var> status. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getTemporalFile</b><i> <var>NAME</var></i> |
| <a name="IDX29"></a> |
| </dt> |
| <dd><p>Output absolute path to temporal file <var>NAME</var>. |
| </p> |
| <p>The <code>cli_getTemporalFile</code> function uses <tt>`/tmp'</tt> directory as |
| source location to store temporal files, the <tt>`centos-art.sh'</tt> |
| script name, and a random identification string to let you run more |
| than one <tt>`centos-art.sh'</tt> script simultaneously on the same user |
| session. For example, due the following temporal file defintion: |
| </p> |
| <pre class="verbatim">cli_getTemporalFile $FILE |
| </pre> |
| <p>If <var>FILE</var> name is <tt>`instance.svg'</tt> and the unique random string |
| is <samp>`f16f7b51-ac12-4b7f-9e66-72df847f12de'</samp>, the final temporal |
| file, built from previous temporal file definition, would be: |
| </p> |
| <pre class="verbatim">/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg |
| </pre> |
| <p>When you use the <code>cli_getTemporalFile</code> function to create |
| temporal files, be sure to remove temporal files created once you've |
| ended up with them. For example, consider the following construction: |
| </p> |
| <pre class="verbatim">for FILE in $FILES;do |
| |
| # Initialize temporal instance of file. |
| INSTANCE=$(cli_getTemporalFile $FILE) |
| |
| # Do something ... |
| |
| # Remove temporal instance of file. |
| if [[ -f $INSTANCE ]];then |
| rm $INSTANCE |
| fi |
| |
| done |
| </pre> |
| <p>Use the <code>cli_getTemporalFile</code> function whenever you need to |
| create temporal files inside <tt>`centos-art.sh'</tt> script. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_getThemeName</b> |
| <a name="IDX30"></a> |
| </dt> |
| <dd><p>Output theme name. |
| </p> |
| <p>In order for <code>cli_getThemeName</code> function to extract theme name |
| correctly, the <var>ACTIONVAL</var> variable must contain a directory path |
| under <tt>`trunk/Identity/Themes/Motifs/'</tt> directory structure. |
| Otherwise, <code>cli_getThemeName</code> returns an empty string. |
| </p></dd></dl> |
| |
| <dl> |
| <dt><u>Function:</u> <b>cli_printMessage</b><i> MESSAGE [FORMAT]</i> |
| <a name="IDX31"></a> |
| </dt> |
| <dd><p>Define standard output message definition supported by |
| <tt>`centos-art.sh'</tt> script. |
| </p> |
| <p>When <var>FORMAT</var> is not specified, <code>cli_printMessage</code> outputs |
| information just as it was passed in <var>MESSAGE</var> variable. |
| Otherwise, <var>FORMAT</var> can take one of the following values: |
| </p> |
| <dl compact="compact"> |
| <dt> <samp>`AsHeadingLine'</samp></dt> |
| <dd><p>To print heading messages. |
| </p><pre class="verbatim">---------------------------------------------------------------------- |
| $MESSAGE |
| ---------------------------------------------------------------------- |
| </pre> |
| </dd> |
| <dt> <samp>`AsWarningLine'</samp></dt> |
| <dd><p>To print warning messages. |
| </p><pre class="verbatim">---------------------------------------------------------------------- |
| WARNING: $MESSAGE |
| ---------------------------------------------------------------------- |
| </pre> |
| </dd> |
| <dt> <samp>`AsNoteLine'</samp></dt> |
| <dd><p>To print note messages. |
| </p><pre class="verbatim">---------------------------------------------------------------------- |
| NOTE: $MESSAGE |
| ---------------------------------------------------------------------- |
| </pre> |
| </dd> |
| <dt> <samp>`AsUpdatingLine'</samp></dt> |
| <dd><p>To print <samp>`Updating'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Updating $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsRemovingLine'</samp></dt> |
| <dd><p>To print <samp>`Removing'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Removing $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsCheckingLine'</samp></dt> |
| <dd><p>To print <samp>`Checking'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Checking $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsCreatingLine'</samp></dt> |
| <dd><p>To print <samp>`Creating'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Creating $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsSavedAsLine'</samp></dt> |
| <dd><p>To print <samp>`Saved as'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Saved as $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsLinkToLine'</samp></dt> |
| <dd><p>To print <samp>`Linked to'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Linked to $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsMovedToLine'</samp></dt> |
| <dd><p>To print <samp>`Moved to'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Moved to $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsTranslationLine'</samp></dt> |
| <dd><p>To print <samp>`Translation'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Translation $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsConfigurationLine'</samp></dt> |
| <dd><p>To print <samp>`Configuration'</samp> messages on two-columns format. |
| </p><pre class="verbatim">Configuration $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsResponseLine'</samp></dt> |
| <dd><p>To print response messages on one-column format. |
| </p><pre class="verbatim">--> $MESSAGE |
| </pre> |
| </dd> |
| <dt> <samp>`AsRequestLine'</samp></dt> |
| <dd><p>To print request messages on one-column format. Request messages |
| output messages with one colon (<samp>`:'</samp>) and without trailing newline |
| (<samp>`\n'</samp>) at message end. |
| </p><pre class="verbatim">$MESSAGE: |
| </pre> |
| </dd> |
| <dt> <samp>`AsYesOrNoRequestLine'</samp></dt> |
| <dd><p>To print <samp>`yes or no'</samp> request messages on one-column format. If |
| something different from <samp>`y'</samp> is answered (when using |
| <code>en_US.UTF-8</code> locale), script execution ends immediatly. |
| </p> |
| <pre class="verbatim">$MESSAGE [y/N]: |
| </pre> |
| <p>When we use <tt>`centos-art.sh'</tt> script in a locale different from |
| <code>en_US.UTF-8</code>, confirmation answer may be different from |
| <samp>`y'</samp>. For example, if you use <code>es_ES.UTF-8</code> locale, the |
| confirmation question would look like: |
| </p> |
| <pre class="verbatim">$MESSAGE [s/N]: |
| </pre> |
| <p>and the confirmation answer would be <samp>`s'</samp>, as it is on Spanish |
| <samp>`sí'</samp> word. |
| </p> |
| <p>Definition of which confirmation word to use is set on translation |
| messages for your specific locale information. -- <strong>Removed</strong>(xref:trunk Scripts |
| Bash Functions Locale) --, for more information about locale-specific |
| translation messages. |
| </p> |
| </dd> |
| <dt> <samp>`AsToKnowMoreLine'</samp></dt> |
| <dd><p>To standardize <samp>`to know more, run the following command:'</samp> |
| messages. When the <samp>`AsToKnowMoreLine'</samp> option is used, the |
| <var>MESSAGE</var> value should be set to <code>"$(caller)"</code>. <code>caller</code> |
| is a Bash builtin that returns the context of the current subroutine |
| call. <samp>`AsToKnowMoreLine'</samp> option uses <code>caller</code> builtin |
| output to build documentation entries dynamically. |
| </p> |
| <pre class="verbatim">---------------------------------------------------------------------- |
| To know more, run the following command: |
| centos-art manual --read='path/to/dir' |
| ---------------------------------------------------------------------- |
| </pre> |
| <p>Use <samp>`AsToKnowMoreLine'</samp> option after errors and for intentional |
| script termination. |
| </p> |
| </dd> |
| <dt> <samp>`AsRegularLine'</samp></dt> |
| <dd><p>To standardize regular messages on one-column format. |
| </p> |
| <p>When <var>MESSAGE</var> contains a colon inside (e.g., <samp>`description: |
| message'</samp>), the <code>cli_printMessage</code> function outputs <var>MESSAGE</var> |
| on two-columns format. |
| </p></dd> |
| </dl> |
| |
| <p>Use <code>cli_printMessage</code> function whenever you need to output |
| information from <tt>`centos-art.sh'</tt> script. |
| </p> |
| <blockquote class="orange"><img src="/home/centos/artwork/trunk/Identity/Images/Webenv/icon-admonition-idea.png" alt="Info"><h3>Tip</h3><p> To improve two-columns format, change the following file: |
| </p><pre class="verbatim">trunk/Scripts/Bash/Styles/output_forTwoColumns.awk |
| </pre></blockquote> |
| </dd></dl> |
| |
| |
| <a name="SEC340"></a> |
| <h4 class="subsubsection"> 2.61.3.3 Specific functions </h4> |
| |
| <p>The following specific functions of <tt>`centos-art.sh'</tt> script, are |
| available for you to use: |
| </p> |
| |
| |
| <a name="SEC341"></a> |
| <h3 class="subsection"> 2.61.4 See also </h3> |
| |
| <table class="menu" border="0" cellspacing="0"> |
| <tr><td align="left" valign="top"><a href="repository_67.html#SEC329">2.60 The <tt>`trunk/Scripts'</tt> Directory</a></td><td> </td><td align="left" valign="top"> |
| </td></tr> |
| </table> |
| |
| |
| <table cellpadding="1" cellspacing="1" border="0"> |
| <tr><td valign="middle" align="left">[<a href="#SEC340" title="Previous section in reading order"> < </a>]</td> |
| <td valign="middle" align="left">[<a href="repository_69.html#SEC342" title="Next section in reading order"> > </a>]</td> |
| <td valign="middle" align="left"> </td> |
| <td valign="middle" align="left">[<a href="repository_7.html#SEC12" title="Beginning of this chapter or previous chapter"> << </a>]</td> |
| <td valign="middle" align="left">[<a href="#SEC334" title="Up section"> Up </a>]</td> |
| <td valign="middle" align="left">[<a href="repository_80.html#SEC416" title="Next chapter"> >> </a>]</td> |
| </tr></table> |
| <p> |
| <font size="-1"> |
| This document was generated on <i>March, 24 2011</i> using <a class="www" href="http://texi2html.cvshome.org/"><i>texi2html 1.76</i></a>. |
| </font> |
| <br> |
| |
| </p> |
| </body> |
| </html> |