From 9bfd151afed71a4b421e31c4b39236a13defe15b Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Mar 09 2011 04:58:19 +0000 Subject: Update repository documentation manual. --- diff --git a/Manual/Filesystem/branches.texi b/Manual/Filesystem/branches.texi index fb39647..b2ea441 100755 --- a/Manual/Filesystem/branches.texi +++ b/Manual/Filesystem/branches.texi @@ -1,22 +1,71 @@ @subsection Goals -@itemize -@item ... -@end itemize +This directory implements the Subversion's branches concept in a +trunk, branches, tags repository structure. @subsection Description -@itemize -@item ... -@end itemize +The @file{branches/} directory structure is an intermediate space +between @file{trunk/} directory structure and @file{tags/} directory +structure. @subsection Usage -@itemize -@item ... -@end itemize +If changes committed to the main develpment line are all predictable +(e.g., there is just one person committing changes), there is no a big +need of using @file{branches/} directory structure, in this case we +can go straight from @file{trunk/} to @file{tags/}. However, when +there is no way to predict changes in the main development directory +structure (e.g., there are many people working at it at the same time) +it is required to find out a space when changes can occur in +predictable ways. + +At this point several options may arise to work with branches. Let's +see a few ones: + +@subsubsection Temporal Branch + +The branched directory is created temporaly to fix a problem and when +it is done, it is merged back into @file{trunk/} directory structure +and removed from the repository. + +@subsubsection Major Release Branch + +The branched directory is created to implement the concept of major +release. In this configuration we frequently take a functional +instance of @file{trunk/} directory structure and create branch for +it. While @file{trunk/} directory structure can receive new +functionalities or remove old ones, the branched instance of it does +not. The branched instance can receive updates for available files +only but not introduce new ones or remove old ones as it is done in +@file{trunk/} directory structure. + +The frequency each branched directory is created depends on how long +can the branched directory could be on its state before consider it as +dated and also the time we want to provide it as stable for everyone +to use as expected. The exact time depends on the sort of information +such branched directory structure contains. + +To illustrate this concept consider the @file{trunk/Scripts/Bash/Cli} +directory structure. This directory contains the main development line +of @command{centos-art} command-line internface. If there are several +people working on it and you find a problem in it, it could be very +frustrating for you try to solve it in an environment when other +changes could be introduced unexpectedly, specially if such change you +need to do is considerable long. For that reasing it is much better to +commit small changes frequently to fix small things, but if you +absolutly need to make a long change (e.g., you want to implement a +new functionality) it is necessary you create branch of @file{trunk/} +directory structure (or any other branch or tag already created) to be +on the safe side while you implement your functionality. + +In order to keep branch creation organized, we use the @file{trunk} +directory structure as reference and add a numerical identifier to the +end of the path that increments one unit for each branch created. @subsection See also @menu +* Filesystem trunk:: +* Filesystem tags:: @end menu diff --git a/Manual/Filesystem/chapter-intro.texi b/Manual/Filesystem/chapter-intro.texi index e69de29..3ded8b3 100644 --- a/Manual/Filesystem/chapter-intro.texi +++ b/Manual/Filesystem/chapter-intro.texi @@ -0,0 +1,10 @@ +The CentOS Artwork Repsotiroy File System is the place where we +organize The CentOS Project Corporate Visual Identity. The CentOS +Artwork Repository uses directories to organize files and describe +conceptual idea about corporate identity. Such conceptual ideas are +explained in each directory related documentation entry. + +In this chapter you'll learn what each directory inside The CentOS +Artwork Repository is for and so, how you can make use of them. For +that purpose, the following list of directories is available for you +to explore: diff --git a/Manual/Filesystem/chapter-menu.texi b/Manual/Filesystem/chapter-menu.texi index 08d0968..9cc3aeb 100644 --- a/Manual/Filesystem/chapter-menu.texi +++ b/Manual/Filesystem/chapter-menu.texi @@ -56,6 +56,7 @@ * Filesystem trunk Locales Identity Themes Backgrounds:: * Filesystem trunk Locales Identity Themes Distro Anaconda Progress:: * Filesystem trunk Locales Identity Widgets:: +* Filesystem trunk Manual:: * Filesystem trunk Manuals:: * Filesystem trunk Scripts:: * Filesystem trunk Scripts Bash:: diff --git a/Manual/Filesystem/chapter-nodes.texi b/Manual/Filesystem/chapter-nodes.texi index a738409..d32fa76 100644 --- a/Manual/Filesystem/chapter-nodes.texi +++ b/Manual/Filesystem/chapter-nodes.texi @@ -283,6 +283,11 @@ @cindex Filesystem trunk Locales Identity Widgets @include Filesystem/trunk/Locales/Identity/Widgets.texi +@node Filesystem trunk Manual +@section The @file{trunk/Manual} Directory +@cindex Filesystem trunk Manual +@include Filesystem/trunk/Manual.texi + @node Filesystem trunk Manuals @section The @file{trunk/Manuals} Directory @cindex Filesystem trunk Manuals diff --git a/Manual/Filesystem/trunk.texi b/Manual/Filesystem/trunk.texi index e69de29..25b9f36 100644 --- a/Manual/Filesystem/trunk.texi +++ b/Manual/Filesystem/trunk.texi @@ -0,0 +1,123 @@ +@subsection Goals + +This directory implements the Subversion's trunk concept in a +trunk, branches, tags repository structure. + +@subsection Description + +The @file{trunk/} directory structure is the main development line +inside the CentOS Artwork Repository. Here is where we produce the +information required by The CentOS Project corporate visual identity. +Additionally, here is where documentation and automation scripts are +conceived to make both understanding and using of CentOS Artwork +Repository easier for everyone. + +The @file{trunk/} directory structure covers the following topics: + +@table @strong +@item Identity +This directory organizes the production of images in different formats +and some non-image formats like XHTML and text files, as well. This is +the perfect place to consolidate @emph{The CentOS Artwork SIG}. If you +are interested in producing art works for The CentOS Project, this +place is for you. + +@xref{Filesystem trunk Identity}, for more information. + +@item Documentation +This directory organizes the production of @emph{CentOS Artwork +Repository Manual} (i.e., the place where the documentation you are +reading right now is stored in). If you are interested on improving +The CentOS Artwork Repository Manual, in this place you'll find the +Texinfo documentation structure you need to work with. + +@xref{Filesystem trunk Manual}, for more information. + +@item Localization +This directory organizes translation messages specifically produced to +satisfy internationalization needs inside the CentOS Artwork +Repository. This place is perfect to consolidate @emph{The CentOS +Translation SIG}. If you love translating, you'll find lot of messages +waiting for you to translate here. + +@xref{Filesystem trunk Locales}, for more information. + +@item Automation +This directory organizes the production of @command{centos-art}, a +command-line interface specially designed to automate most frequent +tasks in the repository (e.g., image rendition, documenting directory +structures, translating content, etc.). If you can't resist the idea +of automating repeatable tasks, then take a look here. + +@xref{Filesystem trunk Scripts}, for more information. +@end table + +@subsection Usage + +When we need to create branches or tags, the @file{trunk/} directory +structure is the one used as reference to build them. Take a look at +the following directory structure construction and notice how the +@file{/Scripts/Bash/Cli} string is repeated in the paths and how it is +put on it: + +@table @file +@item trunk/Scripts/Bash/Cli + +This directory structure provides the main development line of the +@file{centos-art} command-line interface written in bash. In this +directory changes may occur pretty fast and in unpredicted ways. This +configuration could provoke that the @file{centos-art} command-line +stop working in a manner unprediceted due the way changes are +introduced to it. + +@item branches/Scripts/Bash/Cli/1 + +This directory structure, however, provides an intermediate place for +less unpredicted changes and that way to provide more stability than +@file{trunk/} directory structure is able to provide. + +Notice that we used a number to identify the branch (the number `1' in +this case). Changing this number we could create several branches +that could be maintained at the same time to fix specific problems +simultaneausly otherwise difficult to fix in an unpredictable area +like that provided by @file{trunk/} directory structure. Once the +specific problems has been fixed, the branch is merged into +@file{trunk/} and removed from the repository file system. + +If you are the only person working in the repository, you probably +don't want to worry about creating branches at all and prefer going +straight from trunk to tags. Ask yourself: If I'm the only person +working in the trunk directory structure whom else could introduce +unpredictable changes but myself? In that case, such changes wouldn't +be unpredictable at all, don't you think? + +@item tags/Scripts/Bash/Cli/1.0 + +Instead of removing the branch directory structure from the repository +file system, it could be very convenient to create a check-point in +time with such problems fixed and so providing a predictable release +of the @file{centos-art} command-line interface. + +Notice that we used the number 1.0 to store the tag. These means that +we are creating the tag number 0 from the branch numbered as 1 (i.e., +the first number before the dot represents the branch number and the +second number after the dot represents the tag number). + +Using the @file{centos-art} command-line from tags diectory structure +does provide more stable results than those from branches or trunk +directory structures. The tags directory structure doesn't introduce +changes at all, so you are safe to get what you expect after reading +the release notes for that tag. This configuration is not possible +supported on trunk nor branches since they do change through time. +@end table + +It seems to be no other immediate use for this directory but those +described above. + +@subsection See also + +@menu +* Filesystem branches:: +* Filesystem tags:: +@end menu + diff --git a/Manual/Filesystem/trunk/Manual.texi b/Manual/Filesystem/trunk/Manual.texi new file mode 100755 index 0000000..fb39647 --- /dev/null +++ b/Manual/Filesystem/trunk/Manual.texi @@ -0,0 +1,22 @@ +@subsection Goals + +@itemize +@item ... +@end itemize + +@subsection Description + +@itemize +@item ... +@end itemize + +@subsection Usage + +@itemize +@item ... +@end itemize + +@subsection See also + +@menu +@end menu diff --git a/Manual/Introduction/chapter-intro.texi b/Manual/Introduction/chapter-intro.texi index 315beed..63dd878 100644 --- a/Manual/Introduction/chapter-intro.texi +++ b/Manual/Introduction/chapter-intro.texi @@ -17,24 +17,19 @@ This manual discusses the following intermedite topics: @end itemize This manual is organized in the same way the CentOS Artwork Repository -file system does. In the CentOS Artwork Repository we use directories -to store conceptual ideas of CentOS Corporate Visual Identity. For -this manual sake, each directory in the CentOS Artwork Repository has -its own documentation section to describe the related conceptual -ideas. @xref{Filesystem,,Repository File System}, for more information. +directory structure does. In the CentOS Artwork Repository we use +directories to store conceptual ideas of CentOS Corporate Visual +Identity. For this manual sake, each directory in the CentOS Artwork +Repository has its own documentation section to describe the related +conceptual ideas of it. -This manual is structured dynamically through @command{centos-art} -command-line. The @command{centos-art} command-line provides an -interface for writers to document directories in the working copies of -CentOS Artwork Repository using a predefined Texinfo documentation -structure. The @command{centos-art} command-line, also, takes care of -updating menus, nodes and cross-references inside the documentation -structure when documentation sections are added to or removed from the -manual. @xref{Filesystem trunk Scripts Bash Cli Functions Manual,,The -@file{trunk/Scripts/Bash/Cli/Functions/Manual} Directory}, for more -information. +This manual uses Texinfo as base documentation system. The Texinfo +documentation structure is controlled by the @command{centos-art} +script which is used to perform most common documentation tasks (e.g., +edition, deletion, renaming, updating nodes, menus and cross +references) in a standard way. This guide assumes you have a basic understanding of your CentOS system. If you need help with CentOS, refer to the help page on the CentOS Wiki (@url{http://wiki.centos.org/Help}) for a list of -different places you can go to look for help. +different places you can find help. diff --git a/Manual/Introduction/convenctions.texi b/Manual/Introduction/convenctions.texi index 900382a..025f8c0 100644 --- a/Manual/Introduction/convenctions.texi +++ b/Manual/Introduction/convenctions.texi @@ -1,3 +1,7 @@ +In this manual the word @emph{we}, as personal pronoun, is used to +repesent @emph{The CentOS Artwork SIG}, the group of persons building +the CentOS Artwork Repository. + In this manual, certain words are represented in different fonts, typefaces, sizes, and weights. This highlighting is systematic; different words are represented in the same style to indicate their @@ -32,7 +36,7 @@ the initialization script, written in Bash, used to automate most of tasks in the repository. The @command{centos-art} command uses the @file{ImageMagick} RPM -package to convert images from PNG format to many different formats. +package to convert images from PNG format to other formats. @end table @table @key diff --git a/Manual/Introduction/feedback.texi b/Manual/Introduction/feedback.texi index 6a1a6c1..a3fd751 100644 --- a/Manual/Introduction/feedback.texi +++ b/Manual/Introduction/feedback.texi @@ -1,9 +1,8 @@ - If you find an error in the @emph{CentOS Artwork Repository Manual}, - or if you have thought of a way to make this manual better, we would - like to hear from you! Create a new ticket in artwork project - (@url{https://projects.centos.org/trac/artwork/}). +If you find an error in the @emph{CentOS Artwork Repository Manual}, +or if you have thought of a way to make this manual better, we would +like to hear from you! Create a new ticket in The CentOS Artwork SIG +web site (@url{https://projects.centos.org/trac/artwork/}). - If you have a suggestion for improving the documentation, try to be - as specific as possible. If you have found an error, include the - section number and some of the surrounding text so we can find it - easily. +If you have a suggestion for improving the documentation, try to be as +specific as possible. If you have found an error, include the section +number and some of the surrounding text so we can find it easily. diff --git a/Manual/repository-html/repository.html b/Manual/repository-html/repository.html index a39cc88..3df0d7d 100644 --- a/Manual/repository-html/repository.html +++ b/Manual/repository-html/repository.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -CentOS Artwork Repository: 2.58 The trunk/Manuals Directory +CentOS Artwork Repository: 2.58 The trunk/Manual Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.58 The `trunk/Manuals' Directory

+ + +

2.58 The `trunk/Manual' Directory

- +

2.58.1 Goals

- +

2.58.2 Description

- +

2.58.3 Usage

- +

2.58.4 See also

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_63.html b/Manual/repository-html/repository_63.html index a6d71e2..4eb3095 100644 --- a/Manual/repository-html/repository_63.html +++ b/Manual/repository-html/repository_63.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.59 The trunk/Scripts Directory +CentOS Artwork Repository: 2.59 The trunk/Manuals Directory - - + + @@ -55,38 +55,35 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.59 The `trunk/Scripts' Directory

+ + +

2.59 The `trunk/Manuals' Directory

- +

2.59.1 Goals

-

The `trunk/Scripts' directory exists to: -

- +

2.59.2 Description

- +

2.59.3 Usage

- +

2.59.4 See also

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_64.html b/Manual/repository-html/repository_64.html index 54af199..bb2dcc5 100644 --- a/Manual/repository-html/repository_64.html +++ b/Manual/repository-html/repository_64.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.60 The trunk/Scripts/Bash Directory +CentOS Artwork Repository: 2.60 The trunk/Scripts Directory - - + + @@ -55,197 +55,69 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.60 The `trunk/Scripts/Bash' Directory

+ + +

2.60 The `trunk/Scripts' Directory

- +

2.60.1 Goals

-

The `trunk/Scripts/Bash' directory exists to organize the trunk -development line of `centos-art.sh' automation script. The -`centos-art.sh' script standardizes frequent tasks inside your -working copy of CentOS Artwork Repository. +

The `trunk/Scripts' directory exists to:

+ - + +

2.60.2 Description

-

The best way to understand `centos-art.sh' automation script is -studying its source code. However, as start point, you may prefer to -read an introductory resume before diving into the source code -details. -

-

The `centos-art.sh' script is written in Bash. Most tasks, inside -`centos-art.sh' script, have been organized in many specific -functionalities that you can invoke from the centos-art -command-line interface. -

-

When you type the centos-art command in your terminal, the -operating system trys to execute that command. In order to execute the -command, the operating system needs to know where it is, so the -operating system uses the PATH environment variable to look for -that command location. If your system was prepared to use CentOS -Artwork Repository correctly (-- Removed(pxref:trunk Scripts Bash Functions -Verify) --), you should have a symbolic link inside `~/bin/' -directory that points to the `centos-art.sh' script file. As -`~/bin/' directory is, by default, inside PATH environment -variable, the execution of centos-art command runs the -`centos-art.sh' script. -

-

When `centos-art.sh' script is executed, the first it does is -executing the `trunk/Scripts/Bash/initEnvironment.sh' script to -initialize global variables (e.g., gettext variables) and -global function scripts. Global function scripts are located inside -`trunk/Scripts/Bash/Functions' directory and their file names -begin with `cli'. Global function scripts provide common -functionalities that can be used anywhere inside `centos-art.sh' -script execution environment. -

-

Once global variables and function scripts have been loaded, -`centos-art.sh' script executes the cli global function -from `cli.sh' function script to retrive command-line arguments -and define some default values that may be used later by specific -function scripts (-- Removed(pxref:trunk Scripts Bash Functions) --). -

-

As convenction, the `centos-art.sh' command-line arguments have -the following format: -

-
centos-art arg1 --arg2=val2 --arg3=val3
-
-

In the above example, `centos-art' is the command you use to -invoke `centos-art.sh' script. The `arg1' is required and -represents the functionality you want to perform (e.g., -`verify', `render', `locale', `manual', -etc.). The remaining arguments are modifiers to `arg1'. The -`--arg2' definition is required and represets, specifically, -the action inside the functionality you want to perform. The -`--arg3' and on, are optional. -

-

Once command-line arguments have been retrived, the -`centos-art.sh' script loads specific functionalities using the -`cli_getFunctions.sh' function script. Only one specific -functionality can be loaded at one script execution I.e., you run -centos-art.sh script to run just one functionality. -

-
-
+----------------------------------------------------------------------+
-| [centos@host]$ centos-art function --action='value' --option='value' |
-+----------------------------------------------------------------------+
-| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh      |
-+---v-----------------------------------------v------------------------+
-    | centos-art.sh                           |
-    +---v---------------------------------v---+
-    .   | initEnvironment.sh              |   .
-    .   +---------------------------------+   .
-    .   | cli $@                          |   .
-    .   +---v-------------------------v---+   .
-    .   .   | cli_getFunctions        |   .   .
-    .   .   +---v-----------------v---+   .   .
-    .   .   .   | function1       |   .   .   .
-    .   .   .   | function2       |   .   .   .
-    .   .   .   | function3       |   .   .   .
-    .   .   .   +-----------------+   .   .   .
-    .   .   ...........................   .   .
-    .   ...................................   .
-    ...........................................
-
-

Figure 2.1: The functionalities initialization environment. - -

-

Functionalities are implemented by means of actions. Once the -functionality has been initiazalized, actions initialization take -place for that functionality. Actions initialization model is very -similar to functions initialization model. But with the difference, -that actions are loaded inside function environment, and so, share -variables and functions defined inside function environment. -

-
-
+--------------------------------------+
-| cli_getFunctions                     |
-+---v------------------------------v---+
-.   | function1                    |   .
-.   +---v----------------------v---+   .
-.   .   | function1_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-.   +------------------------------+   .
-.   | function2                    |   .
-.   +---v----------------------v---+   .
-.   .   | function2_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-.   +------------------------------+   .
-.   | function3                    |   .
-.   +---v----------------------v---+   .
-.   .   | function3_getActions |   .   .
-.   .   +---v--------------v---+   .   .
-.   .   .   | action 1     |   .   .   .
-.   .   .   | action 2     |   .   .   .
-.   .   .   | action n     |   .   .   .
-.   .   .   +--------------+   .   .   .
-.   .   ........................   .   .
-.   ................................   .
-........................................
-
-

Figure 2.2: The actions initialization environment. - -

+ - + +

2.60.3 Usage

-

The `centos-art.sh' script usage information is described inside -each specific function documentation (-- Removed(pxref:trunk Scripts Bash -Functions) --). -

+ + - +

2.60.4 See also

- - -
2.59 The `trunk/Scripts' Directory   -
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_65.html b/Manual/repository-html/repository_65.html index 0e74dec..9a9c19e 100644 --- a/Manual/repository-html/repository_65.html +++ b/Manual/repository-html/repository_65.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.61 The trunk/Scripts/Bash/Cli Directory +CentOS Artwork Repository: 2.61 The trunk/Scripts/Bash Directory - - + + @@ -55,38 +55,197 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.61 The `trunk/Scripts/Bash/Cli' Directory

+ + +

2.61 The `trunk/Scripts/Bash' Directory

+ +

2.61.1 Goals

+ +

The `trunk/Scripts/Bash' directory exists to organize the trunk +development line of `centos-art.sh' automation script. The +`centos-art.sh' script standardizes frequent tasks inside your +working copy of CentOS Artwork Repository. +

+ + +

2.61.2 Description

+ +

The best way to understand `centos-art.sh' automation script is +studying its source code. However, as start point, you may prefer to +read an introductory resume before diving into the source code +details. +

+

The `centos-art.sh' script is written in Bash. Most tasks, inside +`centos-art.sh' script, have been organized in many specific +functionalities that you can invoke from the centos-art +command-line interface. +

+

When you type the centos-art command in your terminal, the +operating system trys to execute that command. In order to execute the +command, the operating system needs to know where it is, so the +operating system uses the PATH environment variable to look for +that command location. If your system was prepared to use CentOS +Artwork Repository correctly (-- Removed(pxref:trunk Scripts Bash Functions +Verify) --), you should have a symbolic link inside `~/bin/' +directory that points to the `centos-art.sh' script file. As +`~/bin/' directory is, by default, inside PATH environment +variable, the execution of centos-art command runs the +`centos-art.sh' script. +

+

When `centos-art.sh' script is executed, the first it does is +executing the `trunk/Scripts/Bash/initEnvironment.sh' script to +initialize global variables (e.g., gettext variables) and +global function scripts. Global function scripts are located inside +`trunk/Scripts/Bash/Functions' directory and their file names +begin with `cli'. Global function scripts provide common +functionalities that can be used anywhere inside `centos-art.sh' +script execution environment. +

+

Once global variables and function scripts have been loaded, +`centos-art.sh' script executes the cli global function +from `cli.sh' function script to retrive command-line arguments +and define some default values that may be used later by specific +function scripts (-- Removed(pxref:trunk Scripts Bash Functions) --). +

+

As convenction, the `centos-art.sh' command-line arguments have +the following format: +

+
centos-art arg1 --arg2=val2 --arg3=val3
+
+

In the above example, `centos-art' is the command you use to +invoke `centos-art.sh' script. The `arg1' is required and +represents the functionality you want to perform (e.g., +`verify', `render', `locale', `manual', +etc.). The remaining arguments are modifiers to `arg1'. The +`--arg2' definition is required and represets, specifically, +the action inside the functionality you want to perform. The +`--arg3' and on, are optional. +

+

Once command-line arguments have been retrived, the +`centos-art.sh' script loads specific functionalities using the +`cli_getFunctions.sh' function script. Only one specific +functionality can be loaded at one script execution I.e., you run +centos-art.sh script to run just one functionality. +

+
+
+----------------------------------------------------------------------+
+| [centos@host]$ centos-art function --action='value' --option='value' |
++----------------------------------------------------------------------+
+| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh      |
++---v-----------------------------------------v------------------------+
+    | centos-art.sh                           |
+    +---v---------------------------------v---+
+    .   | initEnvironment.sh              |   .
+    .   +---------------------------------+   .
+    .   | cli $@                          |   .
+    .   +---v-------------------------v---+   .
+    .   .   | cli_getFunctions        |   .   .
+    .   .   +---v-----------------v---+   .   .
+    .   .   .   | function1       |   .   .   .
+    .   .   .   | function2       |   .   .   .
+    .   .   .   | function3       |   .   .   .
+    .   .   .   +-----------------+   .   .   .
+    .   .   ...........................   .   .
+    .   ...................................   .
+    ...........................................
+
+

Figure 2.1: The functionalities initialization environment. + +

+

Functionalities are implemented by means of actions. Once the +functionality has been initiazalized, actions initialization take +place for that functionality. Actions initialization model is very +similar to functions initialization model. But with the difference, +that actions are loaded inside function environment, and so, share +variables and functions defined inside function environment. +

+
+
+--------------------------------------+
+| cli_getFunctions                     |
++---v------------------------------v---+
+.   | function1                    |   .
+.   +---v----------------------v---+   .
+.   .   | function1_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function2                    |   .
+.   +---v----------------------v---+   .
+.   .   | function2_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function3                    |   .
+.   +---v----------------------v---+   .
+.   .   | function3_getActions |   .   .
+.   .   +---v--------------v---+   .   .
+.   .   .   | action 1     |   .   .   .
+.   .   .   | action 2     |   .   .   .
+.   .   .   | action n     |   .   .   .
+.   .   .   +--------------+   .   .   .
+.   .   ........................   .   .
+.   ................................   .
+........................................
+
+

Figure 2.2: The actions initialization environment. + +

+ + +

2.61.3 Usage

+ +

The `centos-art.sh' script usage information is described inside +each specific function documentation (-- Removed(pxref:trunk Scripts Bash +Functions) --). +

+ + +

2.61.4 See also

+ + + +
2.60 The `trunk/Scripts' Directory   +
+ - - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_66.html b/Manual/repository-html/repository_66.html index ca302da..6846982 100644 --- a/Manual/repository-html/repository_66.html +++ b/Manual/repository-html/repository_66.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.62 The trunk/Scripts/Bash/Cli/Functions Directory +CentOS Artwork Repository: 2.62 The trunk/Scripts/Bash/Cli Directory - - + + @@ -55,1300 +55,38 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.62 The `trunk/Scripts/Bash/Cli/Functions' Directory

+ + +

2.62 The `trunk/Scripts/Bash/Cli' Directory

- -

2.62.1 Goals

- -

The `trunk/Scripts/Bash/Functions' directory exists to organize -`centos-art.sh' specific functionalities. -

- - -

2.62.2 Description

- -

The specific functions of `centos-art.sh' script are designed -with "Software Toolbox" philosophy (see (coreutils.info)Toolbox introduction) in mind: each program "should do one -thing well". Inside `centos-art.sh' 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. -

-

The specific functions of `centos-art.sh' script are organized -inside specific directories under `trunk/Scripts/Bash/Functions' -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 render, the specific function -directory for it would be `trunk/Scripts/Bash/Functions/Render'. -

-

To better understand how specific functions of `centos-art.sh' -script are designed, lets create one function which only goal is to -output different kind of greetings to your screen. -

-

When we create specific functions for `centos-art.sh' 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. -

-
Info

Tip

Join CentOS developers mailing list -centos-art@centos.org to share your ideas. -

- -

It is also worth to know what global functions and variables do we -have available inside `centos-art.sh' script, so advantage can be -taken from them. Global variables are defined inside global function -scripts. Global functions scripts are stored immediatly under -`trunk/Scripts/Bash/Functions' directory, in files begining with -`cli' prefix. -

-

OK, let's begin with our functionality example. -

-

What function name do we use? Well, lets use greet. Note that -`hello' word is not a verb; but an expression, a kind of -greeting, an interjection specifically. In contrast, `greet' is a -verb and describes what we do when we say `Hello!', `Hi!', -and similar expressions. -

-

So far, we've gathered the following function information: -

-
Name: greet
-Path: trunk/Scripts/Bash/Functions/Greet
-File: trunk/Scripts/Bash/Functions/Greet/greet.sh
-
-

The `greet.sh' function script is the first file -`centos-art.sh' script loads when the `greet' functionality -is called using commands like `centos-art greet --hello='World''. -The `greet.sh' function script contains the greet function -definition. -

-

Inside `centos-art.sh' script, as convenction, each function -script has one top commentary, followed by one blank line, and then -one function defintion below it only. -

-

Inside `centos-art.sh' 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 `centos-art.sh' -script is released as GPL, so do all its functions--, the $Id$ -keyword of Subversion is later expanded by svn propset -command. -

-

In our greet function example, top commentary for -`greet.sh' function script would look like the following: -

-
#!/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$
-# ----------------------------------------------------------------------
-
-

After top commentary, separated by one blank line, the greet -function definition would look like the following: -

-
function greet {
-
-    # Define global variables.
-
-    # Define command-line interface.
-    greet_getActions
-
-}
-
-

The first definition inside greet function, are global -variables that will be available along greet function execution -environment. This time we didn't use global variable definitions for -greet function execution environment, so we left that section -empty. -

-

Later, we call greet_getActions function to define the -command-line interface of greet functionality. The command-line -interface of greet functionality defines what and how actions -are performed, based on arguments combination passed to -`centos-art.sh' script. -

-
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
-
-}
-
-

The ACTIONNAM global variable is defined in `cli.sh' -function script and contains the value passed before the equal sign -(i.e., `=') in the second command-line argument of -`centos-art.sh' script. For example, if the second command-line -argument is `--hello='World'', the value of ACTIONNAM -variable would be `--hello'. Using this configuration let us -deside which action to perform based on the action name passed to -`centos-art.sh' script as second argument. -

-

The greet function definition makes available two valid -greetings through `--hello' and `--bye' options. If no -one of them is provided as second command-line argument, the `*' -case is evaluated instead. -

-

The `*' case and its two lines further on should always be -present in `_getActions.sh' 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. -

-

The greet_doHello and greet_doBye function definitions -are the core of greet specific functionality. In such function -definitions we set what our greet function really does: to -output different kinds of greetings. -

-
function greet_doHello {
-
-    cli_printMessage "`gettext "Hello"` $ACTIONVAL"
-
-}
-
-

The greet_doHello function definition is stored in -`greet_doHello.sh' function script. -

-
function greet_doBye {
-
-    cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
-
-}
-
-

The greet_doBye function definition is stored in the -`greet_doBye.sh' function script. -

-

Both `greet_doHello.sh' and `greet_doBye.sh' function -scripts are stored inside greet function directory path (i.e. -`trunk/Scripts/Bash/Functions/Greet'). -

-

The ACTIONVAL global variable is defined in `cli.sh' -function script and contains the value passed after the equal sign -(i.e., `=') in the second command-line argument of -`centos-art.sh' script. For example, if the second command-line -argument is `--hello='World'', the value of ACTIONVAL -variable would be `World' without quotes. -

-

Let's see how greet specific functionality files are organzied -under greet function directory. To see file organization we use -the tree command: -

-
trunk/Scripts/Bash/Functions/Greet
-|-- greet_doBye.sh
-|-- greet_doHello.sh
-|-- greet_getActions.sh
-`-- greet.sh
-
-

To try the greet specific functionality we've just created, -pass the function name (i.e., `greet') as first argument to -`centos-art.sh' script, and any of the valid options as second -argument. Some examples are illustrated below: -

-
[centos@projects ~]$ centos-art greet --hello='World'
-Hello World
-[centos@projects ~]$ centos-art greet --bye='World'
-Goodbye World
-[centos@projects ~]$ 
-
-

The word `World' in the examples above can be anything. In fact, -change it to have a little fun. -

-

Now that we have a specific function that works as we expect, it is -time to document it. To document greet specific functionality, -we use its directory path and the manual functionality -(-- Removed(pxref:trunk Scripts Bash Functions Manual) --) of `centos-art.sh' -script, just as the following command illustrates: -

-
centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
-
-

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 `centos-art.sh' script uses -the function documentation entry as vehicle to communicate which the -valid functions are. When no documentation entry exists for a -function, the `centos-art.sh' script informs that no -documentation entry exists for such function and requests user to -create it right at that time. -

-

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 -locale functionality (-- Removed(pxref:trunk Scripts Bash Functions -Locale) --) of `centos-art.sh' script, just as the following command -illustrates: -

-
centos-art locale --edit
-
-
Warning

Warning

To translate output messages in different languages, -your system locale information --as in LANG 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 -`es_ES.UTF-8', or similar, first. -

- -

Well, it seems that our example is rather complete by now. -

-

In greet function example we've described so far, we only use -cli_printMessage 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 -`--filter='regex'' and reduce the amount of files to process -using a regular expression pattern. -

-

The greet function described in this section may serve you as -an introduction to understand how specific functionalities work inside -`centos-art.sh' script. With some of luck this introduction will -also serve you as motivation to create your own `centos-art.sh' -script specific functionalities. -

-

By the way, the greet functionality doesn't exist inside -`centos-art.sh' script yet. Would you like to create it? -

- - -

2.62.3 Usage

- - - -

2.62.3.1 Global variables

- -

The following global variables of `centos-art.sh' script, are -available for you to use inside specific functions: -

-
-
Variable: TEXTDOMAIN - -
-

Default domain used to retrieve translated messages. This value is set -in `initFunctions.sh' and shouldn't be changed. -

- -
-
Variable: TEXTDOMAINDIR - -
-

Default directory used to retrieve translated messages. This value is -set in `initFunctions.sh' and shouldn't be changed. -

- -
-
Variable: FUNCNAM - -
-

Define function name. -

-

Function names associate sets of actions. There is one set of actions -for each unique function name inside `centos-art.sh' script. -

-

Dunction names are passed as first argument in `centos-art.sh' -command-line interface. For example, in the command `centos-art -render --entry=path/to/dir --filter=regex', the ACTION passed to -`centos-art.sh' script is `render'. -

-

When first argument is not provided, the `centos-art.sh' script -immediatly ends its execution. -

- -
-
Variable: FUNCDIR - -
-
- -
-
Variable: FUNCDIRNAME - -
-
- -
-
Variable: FUNCSCRIPT - -
-
- -
-
Variable: FUNCCONFIG - -
-
- -
-
Variable: ACTIONNAM - -
-

Define action name. -

-

Each action name identifies an specific action to perform, inside an -specific function. -

-

Action name names aare passed as second argument in -`centos-art.sh' command-line interface. For example, in the -command `centos-art render --entry=path/to/dir --filter=regex', -the ACTIONNAM passed to `centos-art.sh' script is -`--entry'. -

-

When second argument is not provided, the `centos-art.sh' script -immediatly ends its execution. -

- -
-
Variable: ACTIONVAL - -
-

Define action value. -

-

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. -

- -
-
Variable: REGEX - -
-

Define regular expression used as pattern to build the list of files -to process. -

-

By default, REGEX variable is set to .+ to match all -files. -

-

Functions that need to build a list of files to process use the option -`--filter' to redefine REGEX variable default value, and -so, control the amount of files to process. -

- -
-
Variable: ARGUMENTS - -
-

Define optional arguments. -

-

Optional arguments, inside `centos-art.sh' script, are considered -as all command-line arguments passed to `centos-art.sh' script, -from third argument position on. For example, in the command -`centos-art render --entry=path/to/dir --filter=regex' , the -optional arguments are from `--filter=regex' argument on. -

-

Optional arguments are parsed using getopt command through -the following base construction: -

-
# 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
-
-

Optional arguments provide support to command options inside -`centos-art.sh' script. For instance, consider the Subversion -(svn) command, where there are many options (e.g., -`copy', `delete', `move', etc), and inside each -option there are several modifiers (e.g., `--revision', -`--message', `--username', etc.) that can be combined one -another in their short or long variants. -

-

The ARGUMENTS variable is used to store arguments passed from -command-line for later use inside `centos-art.sh' script. Storing -arguments is specially useful when we want to run a command with some -specific options from them. Consider the following command: -

-
centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
-
-

In the above command, the `--message', and `--username' -options are specific to svn copy command. In such cases, -options are not interpreted by `centos-art.sh' script itself. -Instead, the `centos-art.sh' script uses getopt to -retrive them and store them in the ARGUMENTS variable for later -use, as described in the following command: -

-
# Build subversion command to duplicate locations inside the
-# workstation.
-eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
-
-

When getopt parses ARGUMENTS, we may use short options -(e.g., `-m') or long options (e.g., `--message'). When -we use short options, arguments are separated by one space from the -option (e.g., `-m 'This is a commit message.''). When we use -long options arguments are separated by an equal sign (`=') -(e.g., `--message='This is a commit message''). -

-

In order for getopt to parse ARGUMENTS 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. -

-

As convenction, inside `centos-art.sh' script, short option -definitions are set in the ARGSS variable; and long option -definitions are set in the ARGSL variable. -

-

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 `:' -after the option definition (e.g., `-o m: -l message:'). On -the other hand, to define an option argument as not required, you need -to set two colons `::' after the option definition (e.g., -`-o m:: -l message::'). -

- -
-
Variable: EDITOR - -
-

Default text editor. -

-

The `centos-art.sh' script uses default text EDITOR to edit -pre-commit subversion messages, translation files, configuration -files, script files, and similar text-based files. -

-

If EDITOR environment variable is not set, `centos-art.sh' -script uses `/usr/bin/vim' as default text editor. Otherwise, the -following values are recognized by `centos-art.sh' script: -

-
    -
  • `/usr/bin/vim' -
  • `/usr/bin/emacs' -
  • `/usr/bin/nano' -
- -

If no one of these values is set in EDITOR environment variable, -`centos-art.sh' uses `/usr/bin/vim' text editor by default. -

- - - -

2.62.3.2 Global functions

- -

Function scripts stored directly under -`trunk/Scripts/Bash/Functions/' 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 `centos-art.sh' script. -

-
-
Function: cli_checkActionArguments - -
-

Validate action value (ACTIONVAL) variable. -

-

The action value variable can take one of the following values: -

-
    -
  1. Path to one directory inside the local working copy, -
  2. Path to one file inside the local working copy, -
- -

If another value different from that specified above is passed to -action value variable, the `centos-art.sh' script prints an error -message and ends script execution. -

- -
-
Function: cli_checkFiles FILE [TYPE] - -
-

Verify file existence. -

-

cli_checkFiles receives a FILE absolute path and performs -file verification as specified in TYPE. When TYPE is not -specified, cli_checkFiles verifies FILE existence, no -matter what kind of file it be. If TYPE is specified, use one -of the following values: -

-
-
`d'
-
`directory'
-

Ends script execution if FILE is not a directory. -

-

When you verify directories with cli_checkFiles, if directory doesn't -exist, `centos-art.sh' script asks you for confirmation in order -to create that directory. If you answer positively, -`centos-art.sh' script creates that directory and continues -script flows normally. Otherwise, if you answer negatively, -`centos-art.sh' ends script execution with an error and -documentation message. -

-
-
`f'
-
`regular-file'
-

Ends script execution if FILE is not a regular file. -

-
`h'
-
`symbolic-link'
-

Ends script execution if FILE is not a symbolic link. -

-
`x'
-
`execution'
-

Ends script execution if FILE is not executable. -

-
`fh'
-

Ends script execution if FILE is neither a regular file nor a -symbolic link. -

-
`fd'
-

Ends script execution if FILE is neither a regular file nor a -directory. -

-
`isInWorkingCopy'
-

Ends script execution if FILE is not inside the working copy. -

-
- -

As default behaviour, if FILE passes all verifications, -`centos-art.sh' script continues with its normal flow. -

- -
-
Function: cli_commitRepoChanges [LOCATION] - -
-

Syncronize changes between repository and working copy. -

-

The cli_commitRepoChanges function brings changes from the -central repository down to the working copy--using svn -update--, checks the working copy changes--using svn -status command--, prints status report--using both svn -update and svn status commands output, and finally, commits -recent changes from the working copy up to the repository--using -svn commit command--. -

-

Previous to commit the working copy changes up to the central -repository, the cli_commitRepoChanges function asks you to -verify changes--using svn diff command--, and later, -another confirmation question is shown to be sure you really want to -commit changes up to central repository. -

-

If LOCATION argument is not specified, the value of -ACTIONVAL variable is used as reference instead. -

-
-
----------------------------------------------------------------------
---> 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.
-----------------------------------------------------------------------
-
-

Figure 2.3: The cli_commitRepoChanges function output. - -

-

Call the cli_commitRepoChanges function before or/and after -calling functions that modify files or directories inside the working -copy as you may need to. -

- -
-
Function: cli_doParseArguments - -
-

Redefine arguments (ARGUMENTS) global variable using -getopt command output. For more information about how to use -cli_doParseArguments function, see ARGUMENTS variable -description above. -

- -
-
Function: cli_doParseArgumentsReDef $@ - -
-

Initialize/reset arguments (ARGUMENTS) global variable using -positional parameters variable ($@) as reference. -

-

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 cli_doParseArgumentsReDef with the positional -parameters variable ($@), set as first argument, to that -specific function you want to redefine positional parameters at. -

- -
-
Function: cli_getArguments - -
-

Initialize function name (FUNCNAM), action name -(ACTIONNAM), and action value (ACTIONVAL) global -variables, using positional parameters passed in $@ variable. -

-

The cli_getArguments function is called from cli.sh -function script, using cli function positional parameters -(i.e., the positional parameters passed as arguments in the -command-line) as first function argument. -

-

Once command-line positional parameters are accesible to -`centos-art.sh' script execution evironment, -cli_getArguments uses regular expression to retrive -action variables from first and second argument. The first argument -defines the value used as function name (FUNCNAM), and the -second argument defines both values used as action name -(ACTIONNAM) and action value (ACTIONVAL), respectively. -

-

The first argument is a word in lower case. This word specifies the -name of the functionality you want to use (e.g., `render' to -render images, `manual' to work on documentation, and so on.) -

-

The second argument has a long option style (e.g., -`--option=value'). The `--option' represents the action name -(ACTIONNAM), and the characters inbetween the equal sign -(`=') and the first space character, are considered as the action -value (ACTIONVAL). In order to provide action values with space -characters inbetween you need to enclose action value with quotes like -in `--option='This is long value with spaces inbetween''. -Generally, action values are used to specify paths over which the -action name acts on. -

-

Once action related variables (i.e., FUNCNAM, ACTIONNAM, -and ACTIONVAL) are defined and validated, -cli_getArguments shifts the positional arguments to remove the -first two arguments passed (i.e., those used to retrive action related -variables) and redefine the arguments (ARGUMENTS) global -variable with the new positional parameters information. -

- -
-
Function: cli_getFunctions - -
-

Initialize funtionalities supported by `centos-art.sh' script. -

-

Functionalities supported by `centos-art.sh' script are organized -in functionality directories under -`trunk/Scripts/Bash/Functions/' 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). -

-

In order for `centos-art.sh' script to recognize a functionality, -such functionality needs to be stored under -`trunk/Scripts/Bash/Functions/' 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 `functionality -directory'. -

-

Inside each functionality directory, the functionalty itself is -implemented through function scripts. Function scripts are organized -in files independently one another and written in `camelCase' -format with the function name as prefix. Separation between prefix -and description is done using underscore (`_') character. -

-

In order for `centos-art.sh' script to load functionalities -correctly, function definition inside function scripts should be set -using the `function' reserved word, just as in the following -example: -

-
function prefix_doSomething {
-
-    # Do something here...
-
-}
-
-

The above function definition is just a convenction we use, in order -to make identification of function names easier read and automate by -`centos-art.sh' script initialization commands, once -`centos-art.sh' script determines which functionality directory -to use. Specifically, in order to initialize and export functions, -`centos-art.sh' script executes all function scripts inside the -functionality directory, and later grep on them using a -regular expression pattern, where the `function' reserved word is -used as reference to retrive the function names and export them to -`centos-art.sh' script execution environment, and so, make -function definitions --from function scripts inside the functionality -directory-- available for further calls. -

-

If the functionality specified in the command-line first argument -doesn't have a functionality directory, `centos-art.sh' script -considers the functionality provided in the command-line as invalid -functionality and immediatly stops script execution with an error -message. -

-

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: -

-
#!/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...
-
-}
-
- -
-
Function: cli_getCountryCodes [FILTER] - -
-

Output country codes supported by `centos-art.sh' script. -

-

The cli_getCountryCodes function outputs a list with country -codes as defined in ISO3166 standard. When FILTER is provided, -cli_getCountryCodes outputs country codes that match -FILTER regular expression pattern. -

- -
-
Function: cli_getCountryName [FILTER] - -
-

Outputs country name supported by `centos-art.sh' script. -

-

The cli_getCountryName 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, cli_getCountryName returns the -country name that matches the locale code specified in FILTER, -exactly. -

- -
-
Function: cli_getCurrentLocale - -
-

Output current locale used by `centos-art.sh' script. -

-

The cli_getCurrentLocale function uses LANG environment -variable to build a locale pattern that is later applied to -cli_getLocales function output in order to return the current -locale that `centos-art.sh' script works with. -

-

The current locale information, returned by -cli_getCurrentLocale, is output from more specific to less -specific. For example, if `en_GB' locale exists in -cli_getLocales function output, the `en_GB' locale would -take precedence before `en' locale. -

-

Locale precedence selection is quite important in order to define the -locale type we use for message translations. For example, if -`en_GB' is used, we are also saying that the common language -specification for English language (i.e., `en') is no longer -used. Instead, we are using English non-common country-specific -language specifications like `en_AU', `en_BW', `en_GB', -`en_US', etc., for message translations. -

-

Use cli_getCurrentLocale function to know what current locale -information to use inside `centos-art.sh' script. -

- -
-
Function: cli_getFilesList [LOCATION] - -
-

Output list of files to process. -

-

The cli_getFilesList function uses LOCATION variable as -source location to build a list of files just as specified by regular -expression (REGEX) global variable. Essentially, what the -cli_getFilesList function does is using find command -to look for files in the location (LOCATION) just as posix-egrep -regular expression (REGEX) specifies. -

-

If LOCATION is not specified when cli_getFilesList -function is called, the action value (ACTIONVAL) global variable -is used as location value instead. -

-

By default, if the regular expression (REGEX) global variable is -not redefined after its first definition in the cli function, -all files that match default regular expression value (i.e., -`.+') 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 cli function and before calling -cli_getFilesList function, the last value you specifed is used -instead. -

-

When you need to customize the regular expression (REGEX) 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 `local' 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. -

-

As result, the cli_getFilesList re-defines the value of -FILES variable with the list of files the find command -returned. As example, consider the following construction: -

-
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
-
-}
-
-
- -
-
Function: cli_getLangCodes [FILTER] - -
-

Outputs language codes supported by `centos-art.sh' script. -

-

cli_getLangCodes function outputs a list of language codes as -defined in ISO639 standard. When FILTER is provided, -cli_getLangCodes outputs language codes that match FILTER -regular expression pattern. -

- -
-
Function: cli_getLangName [FILTER] - -
-

Outputs language names supported by `centos-art.sh' script. -

-

cli_getLangName function reads one language locale code in the -format LL_CC and outputs the language related name as in ISO639. If -filter is specified, cli_getLangName returns the language name -that matches the locale code specified in FILTER, exactly. -

- -
-
Function: cli_getLocales - -
-

Output locale codes supported by `centos-art.sh' script. -

-

Occasionally, you use cli_getLocales function to add locale -information in non-common country-specific language (`LL_CC') -format for those languages (e.g., `bn_IN', `pt_BR', etc.) -which locale differences cannot be solved using common language -specifications (`LL') into one unique common locale specification -(e.g., `bn', `pt', etc.). -

- -
-
Function: cli_getRepoName NAME TYPE - -
-

Sanitate file names. -

-

Inside `centos-art.sh' script, specific functionalities rely both -in cli_getRepoName and repository file system organization to -achieve their goals. Consider cli_getRepoName function as -central place to manage file name convenctions for other functions -inside `centos-art.sh' script. -

-
Important

Important

cli_getRepoName function doesn't verify file -or directory existence, for that purpose use cli_checkFiles -function instead. -

- -

The NAME variable contains the file name or directory name you -want to sanitate. -

-

The TYPE variable specifies what type of sanitation you want to -perform on NAME. The TYPE can be one of the following -values: -

-
-
`d'
-
`directory'
-

Sanitate directory NAMEs. -

-
`f'
-
`regular-file'
-

Sanitate regular file NAMEs. -

-
- -

Use cli_getRepoName function to sanitate file names and -directory names before their utilization. -

-

Use cli_getRepoName when you need to change file name -convenctions inside `centos-art.sh' script. -

-

When we change file name convenctions inside cli_getRepoName -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 (-- Removed(pxref:trunk Scripts Bash Functions Path) --, for more -information). -

- -
-
Function: cli_getRepoStatus [LOCATION] - -
-

Request repository status. -

-

This function requests the status of a LOCATION inside the -working copy using the svn status command and returns the -first character in the output line, just as described in svn -help status. If LOCATION is not a regular file or a directory, -inside the working copy, the `centos-art.sh' script prints a -message and ends its execution. -

-

Use this function to perform verifications based a repository -LOCATION status. -

- -
-
Function: cli_getTemporalFile NAME - -
-

Output absolute path to temporal file NAME. -

-

The cli_getTemporalFile function uses `/tmp' directory as -source location to store temporal files, the `centos-art.sh' -script name, and a random identification string to let you run more -than one `centos-art.sh' script simultaneously on the same user -session. For example, due the following temporal file defintion: -

-
cli_getTemporalFile $FILE
-
-

If FILE name is `instance.svg' and the unique random string -is `f16f7b51-ac12-4b7f-9e66-72df847f12de', the final temporal -file, built from previous temporal file definition, would be: -

-
/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
-
-

When you use the cli_getTemporalFile 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: -

-
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
-
-

Use the cli_getTemporalFile function whenever you need to -create temporal files inside `centos-art.sh' script. -

- -
-
Function: cli_getThemeName - -
-

Output theme name. -

-

In order for cli_getThemeName function to extract theme name -correctly, the ACTIONVAL variable must contain a directory path -under `trunk/Identity/Themes/Motifs/' directory structure. -Otherwise, cli_getThemeName returns an empty string. -

- -
-
Function: cli_printMessage MESSAGE [FORMAT] - -
-

Define standard output message definition supported by -`centos-art.sh' script. -

-

When FORMAT is not specified, cli_printMessage outputs -information just as it was passed in MESSAGE variable. -Otherwise, FORMAT can take one of the following values: -

-
-
`AsHeadingLine'
-

To print heading messages. -

----------------------------------------------------------------------
-$MESSAGE
-----------------------------------------------------------------------
-
-
-
`AsWarningLine'
-

To print warning messages. -

----------------------------------------------------------------------
-WARNING: $MESSAGE
-----------------------------------------------------------------------
-
-
-
`AsNoteLine'
-

To print note messages. -

----------------------------------------------------------------------
-NOTE: $MESSAGE
-----------------------------------------------------------------------
-
-
-
`AsUpdatingLine'
-

To print `Updating' messages on two-columns format. -

Updating        $MESSAGE
-
-
-
`AsRemovingLine'
-

To print `Removing' messages on two-columns format. -

Removing        $MESSAGE
-
-
-
`AsCheckingLine'
-

To print `Checking' messages on two-columns format. -

Checking        $MESSAGE
-
-
-
`AsCreatingLine'
-

To print `Creating' messages on two-columns format. -

Creating        $MESSAGE
-
-
-
`AsSavedAsLine'
-

To print `Saved as' messages on two-columns format. -

Saved as        $MESSAGE
-
-
-
`AsLinkToLine'
-

To print `Linked to' messages on two-columns format. -

Linked to       $MESSAGE
-
-
-
`AsMovedToLine'
-

To print `Moved to' messages on two-columns format. -

Moved to        $MESSAGE
-
-
-
`AsTranslationLine'
-

To print `Translation' messages on two-columns format. -

Translation     $MESSAGE
-
-
-
`AsConfigurationLine'
-

To print `Configuration' messages on two-columns format. -

Configuration   $MESSAGE
-
-
-
`AsResponseLine'
-

To print response messages on one-column format. -

--> $MESSAGE
-
-
-
`AsRequestLine'
-

To print request messages on one-column format. Request messages -output messages with one colon (`:') and without trailing newline -(`\n') at message end. -

$MESSAGE:
-
-
-
`AsYesOrNoRequestLine'
-

To print `yes or no' request messages on one-column format. If -something different from `y' is answered (when using -en_US.UTF-8 locale), script execution ends immediatly. -

-
$MESSAGE [y/N]:
-
-

When we use `centos-art.sh' script in a locale different from -en_US.UTF-8, confirmation answer may be different from -`y'. For example, if you use es_ES.UTF-8 locale, the -confirmation question would look like: -

-
$MESSAGE [s/N]:
-
-

and the confirmation answer would be `s', as it is on Spanish -`sí' word. -

-

Definition of which confirmation word to use is set on translation -messages for your specific locale information. -- Removed(xref:trunk Scripts -Bash Functions Locale) --, for more information about locale-specific -translation messages. -

-
-
`AsToKnowMoreLine'
-

To standardize `to know more, run the following command:' -messages. When the `AsToKnowMoreLine' option is used, the -MESSAGE value should be set to "$(caller)". caller -is a Bash builtin that returns the context of the current subroutine -call. `AsToKnowMoreLine' option uses caller builtin -output to build documentation entries dynamically. -

-
----------------------------------------------------------------------
-To know more, run the following command:
-centos-art manual --read='path/to/dir'
-----------------------------------------------------------------------
-
-

Use `AsToKnowMoreLine' option after errors and for intentional -script termination. -

-
-
`AsRegularLine'
-

To standardize regular messages on one-column format. -

-

When MESSAGE contains a colon inside (e.g., `description: -message'), the cli_printMessage function outputs MESSAGE -on two-columns format. -

-
- -

Use cli_printMessage function whenever you need to output -information from `centos-art.sh' script. -

-
Info

Tip

To improve two-columns format, change the following file: -

trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
-
-
- - - -

2.62.3.3 Specific functions

- -

The following specific functions of `centos-art.sh' script, are -available for you to use: -

- - - -

2.62.4 See also

- - - -
2.60 The `trunk/Scripts/Bash' Directory   -
- - - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_67.html b/Manual/repository-html/repository_67.html index ed9b016..ebcd1c3 100644 --- a/Manual/repository-html/repository_67.html +++ b/Manual/repository-html/repository_67.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.63 The trunk/Scripts/Bash/Cli/Functions/Help Directory +CentOS Artwork Repository: 2.63 The trunk/Scripts/Bash/Cli/Functions Directory - - + + @@ -55,66 +55,1300 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.63 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory

+ + +

2.63 The `trunk/Scripts/Bash/Cli/Functions' Directory

- +

2.63.1 Goals

- - +

The `trunk/Scripts/Bash/Functions' directory exists to organize +`centos-art.sh' specific functionalities. +

- +

2.63.2 Description

- +

The specific functions of `centos-art.sh' script are designed +with "Software Toolbox" philosophy (see (coreutils.info)Toolbox introduction) in mind: each program "should do one +thing well". Inside `centos-art.sh' 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. +

+

The specific functions of `centos-art.sh' script are organized +inside specific directories under `trunk/Scripts/Bash/Functions' +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 render, the specific function +directory for it would be `trunk/Scripts/Bash/Functions/Render'. +

+

To better understand how specific functions of `centos-art.sh' +script are designed, lets create one function which only goal is to +output different kind of greetings to your screen. +

+

When we create specific functions for `centos-art.sh' 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. +

+
Info

Tip

Join CentOS developers mailing list +centos-art@centos.org to share your ideas. +

+ +

It is also worth to know what global functions and variables do we +have available inside `centos-art.sh' script, so advantage can be +taken from them. Global variables are defined inside global function +scripts. Global functions scripts are stored immediatly under +`trunk/Scripts/Bash/Functions' directory, in files begining with +`cli' prefix. +

+

OK, let's begin with our functionality example. +

+

What function name do we use? Well, lets use greet. Note that +`hello' word is not a verb; but an expression, a kind of +greeting, an interjection specifically. In contrast, `greet' is a +verb and describes what we do when we say `Hello!', `Hi!', +and similar expressions. +

+

So far, we've gathered the following function information: +

+
Name: greet
+Path: trunk/Scripts/Bash/Functions/Greet
+File: trunk/Scripts/Bash/Functions/Greet/greet.sh
+
+

The `greet.sh' function script is the first file +`centos-art.sh' script loads when the `greet' functionality +is called using commands like `centos-art greet --hello='World''. +The `greet.sh' function script contains the greet function +definition. +

+

Inside `centos-art.sh' script, as convenction, each function +script has one top commentary, followed by one blank line, and then +one function defintion below it only. +

+

Inside `centos-art.sh' 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 `centos-art.sh' +script is released as GPL, so do all its functions--, the $Id$ +keyword of Subversion is later expanded by svn propset +command. +

+

In our greet function example, top commentary for +`greet.sh' function script would look like the following: +

+
#!/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$
+# ----------------------------------------------------------------------
+
+

After top commentary, separated by one blank line, the greet +function definition would look like the following: +

+
function greet {
 
+    # Define global variables.
 
-
+    # Define command-line interface.
+    greet_getActions
+
+}
+
+

The first definition inside greet function, are global +variables that will be available along greet function execution +environment. This time we didn't use global variable definitions for +greet function execution environment, so we left that section +empty. +

+

Later, we call greet_getActions function to define the +command-line interface of greet functionality. The command-line +interface of greet functionality defines what and how actions +are performed, based on arguments combination passed to +`centos-art.sh' script. +

+
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
+
+}
+
+

The ACTIONNAM global variable is defined in `cli.sh' +function script and contains the value passed before the equal sign +(i.e., `=') in the second command-line argument of +`centos-art.sh' script. For example, if the second command-line +argument is `--hello='World'', the value of ACTIONNAM +variable would be `--hello'. Using this configuration let us +deside which action to perform based on the action name passed to +`centos-art.sh' script as second argument. +

+

The greet function definition makes available two valid +greetings through `--hello' and `--bye' options. If no +one of them is provided as second command-line argument, the `*' +case is evaluated instead. +

+

The `*' case and its two lines further on should always be +present in `_getActions.sh' 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. +

+

The greet_doHello and greet_doBye function definitions +are the core of greet specific functionality. In such function +definitions we set what our greet function really does: to +output different kinds of greetings. +

+
function greet_doHello {
+
+    cli_printMessage "`gettext "Hello"` $ACTIONVAL"
+
+}
+
+

The greet_doHello function definition is stored in +`greet_doHello.sh' function script. +

+
function greet_doBye {
+
+    cli_printMessage "`gettext "Goodbye"` $ACTIONVAL"
+
+}
+
+

The greet_doBye function definition is stored in the +`greet_doBye.sh' function script. +

+

Both `greet_doHello.sh' and `greet_doBye.sh' function +scripts are stored inside greet function directory path (i.e. +`trunk/Scripts/Bash/Functions/Greet'). +

+

The ACTIONVAL global variable is defined in `cli.sh' +function script and contains the value passed after the equal sign +(i.e., `=') in the second command-line argument of +`centos-art.sh' script. For example, if the second command-line +argument is `--hello='World'', the value of ACTIONVAL +variable would be `World' without quotes. +

+

Let's see how greet specific functionality files are organzied +under greet function directory. To see file organization we use +the tree command: +

+
trunk/Scripts/Bash/Functions/Greet
+|-- greet_doBye.sh
+|-- greet_doHello.sh
+|-- greet_getActions.sh
+`-- greet.sh
+
+

To try the greet specific functionality we've just created, +pass the function name (i.e., `greet') as first argument to +`centos-art.sh' script, and any of the valid options as second +argument. Some examples are illustrated below: +

+
[centos@projects ~]$ centos-art greet --hello='World'
+Hello World
+[centos@projects ~]$ centos-art greet --bye='World'
+Goodbye World
+[centos@projects ~]$ 
+
+

The word `World' in the examples above can be anything. In fact, +change it to have a little fun. +

+

Now that we have a specific function that works as we expect, it is +time to document it. To document greet specific functionality, +we use its directory path and the manual functionality +(-- Removed(pxref:trunk Scripts Bash Functions Manual) --) of `centos-art.sh' +script, just as the following command illustrates: +

+
centos-art manual --edit=trunk/Scripts/Bash/Functions/Greet
+
+

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 `centos-art.sh' script uses +the function documentation entry as vehicle to communicate which the +valid functions are. When no documentation entry exists for a +function, the `centos-art.sh' script informs that no +documentation entry exists for such function and requests user to +create it right at that time. +

+

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 +locale functionality (-- Removed(pxref:trunk Scripts Bash Functions +Locale) --) of `centos-art.sh' script, just as the following command +illustrates: +

+
centos-art locale --edit
+
+
Warning

Warning

To translate output messages in different languages, +your system locale information --as in LANG 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 +`es_ES.UTF-8', or similar, first. +

+ +

Well, it seems that our example is rather complete by now. +

+

In greet function example we've described so far, we only use +cli_printMessage 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 +`--filter='regex'' and reduce the amount of files to process +using a regular expression pattern. +

+

The greet function described in this section may serve you as +an introduction to understand how specific functionalities work inside +`centos-art.sh' script. With some of luck this introduction will +also serve you as motivation to create your own `centos-art.sh' +script specific functionalities. +

+

By the way, the greet functionality doesn't exist inside +`centos-art.sh' script yet. Would you like to create it? +

+ +

2.63.3 Usage

+ + +

2.63.3.1 Global variables

+ +

The following global variables of `centos-art.sh' script, are +available for you to use inside specific functions: +

+
+
Variable: TEXTDOMAIN + +
+

Default domain used to retrieve translated messages. This value is set +in `initFunctions.sh' and shouldn't be changed. +

+ +
+
Variable: TEXTDOMAINDIR + +
+

Default directory used to retrieve translated messages. This value is +set in `initFunctions.sh' and shouldn't be changed. +

+ +
+
Variable: FUNCNAM + +
+

Define function name. +

+

Function names associate sets of actions. There is one set of actions +for each unique function name inside `centos-art.sh' script. +

+

Dunction names are passed as first argument in `centos-art.sh' +command-line interface. For example, in the command `centos-art +render --entry=path/to/dir --filter=regex', the ACTION passed to +`centos-art.sh' script is `render'. +

+

When first argument is not provided, the `centos-art.sh' script +immediatly ends its execution. +

+ +
+
Variable: FUNCDIR + +
+
+ +
+
Variable: FUNCDIRNAME + +
+
+ +
+
Variable: FUNCSCRIPT + +
+
+ +
+
Variable: FUNCCONFIG + +
+
+ +
+
Variable: ACTIONNAM + +
+

Define action name. +

+

Each action name identifies an specific action to perform, inside an +specific function. +

+

Action name names aare passed as second argument in +`centos-art.sh' command-line interface. For example, in the +command `centos-art render --entry=path/to/dir --filter=regex', +the ACTIONNAM passed to `centos-art.sh' script is +`--entry'. +

+

When second argument is not provided, the `centos-art.sh' script +immediatly ends its execution. +

+ +
+
Variable: ACTIONVAL + +
+

Define action value. +

+

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. +

+ +
+
Variable: REGEX + +
+

Define regular expression used as pattern to build the list of files +to process. +

+

By default, REGEX variable is set to .+ to match all +files. +

+

Functions that need to build a list of files to process use the option +`--filter' to redefine REGEX variable default value, and +so, control the amount of files to process. +

+ +
+
Variable: ARGUMENTS + +
+

Define optional arguments. +

+

Optional arguments, inside `centos-art.sh' script, are considered +as all command-line arguments passed to `centos-art.sh' script, +from third argument position on. For example, in the command +`centos-art render --entry=path/to/dir --filter=regex' , the +optional arguments are from `--filter=regex' argument on. +

+

Optional arguments are parsed using getopt command through +the following base construction: +

+
# 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
+
+

Optional arguments provide support to command options inside +`centos-art.sh' script. For instance, consider the Subversion +(svn) command, where there are many options (e.g., +`copy', `delete', `move', etc), and inside each +option there are several modifiers (e.g., `--revision', +`--message', `--username', etc.) that can be combined one +another in their short or long variants. +

+

The ARGUMENTS variable is used to store arguments passed from +command-line for later use inside `centos-art.sh' script. Storing +arguments is specially useful when we want to run a command with some +specific options from them. Consider the following command: +

+
centos-art path --copy=SOURCE --to=TARGET --message="The commit message goes here." --username='johndoe'
+
+

In the above command, the `--message', and `--username' +options are specific to svn copy command. In such cases, +options are not interpreted by `centos-art.sh' script itself. +Instead, the `centos-art.sh' script uses getopt to +retrive them and store them in the ARGUMENTS variable for later +use, as described in the following command: +

+
# Build subversion command to duplicate locations inside the
+# workstation.
+eval svn copy $SOURCE $TARGET --quiet $ARGUMENTS
+
+

When getopt parses ARGUMENTS, we may use short options +(e.g., `-m') or long options (e.g., `--message'). When +we use short options, arguments are separated by one space from the +option (e.g., `-m 'This is a commit message.''). When we use +long options arguments are separated by an equal sign (`=') +(e.g., `--message='This is a commit message''). +

+

In order for getopt to parse ARGUMENTS 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. +

+

As convenction, inside `centos-art.sh' script, short option +definitions are set in the ARGSS variable; and long option +definitions are set in the ARGSL variable. +

+

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 `:' +after the option definition (e.g., `-o m: -l message:'). On +the other hand, to define an option argument as not required, you need +to set two colons `::' after the option definition (e.g., +`-o m:: -l message::'). +

+ +
+
Variable: EDITOR + +
+

Default text editor. +

+

The `centos-art.sh' script uses default text EDITOR to edit +pre-commit subversion messages, translation files, configuration +files, script files, and similar text-based files. +

+

If EDITOR environment variable is not set, `centos-art.sh' +script uses `/usr/bin/vim' as default text editor. Otherwise, the +following values are recognized by `centos-art.sh' script: +

    -
  • ... +
  • `/usr/bin/vim' +
  • `/usr/bin/emacs' +
  • `/usr/bin/nano'
+

If no one of these values is set in EDITOR environment variable, +`centos-art.sh' uses `/usr/bin/vim' text editor by default. +

- + + +

2.63.3.2 Global functions

+ +

Function scripts stored directly under +`trunk/Scripts/Bash/Functions/' 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 `centos-art.sh' script. +

+
+
Function: cli_checkActionArguments + +
+

Validate action value (ACTIONVAL) variable. +

+

The action value variable can take one of the following values: +

+
    +
  1. Path to one directory inside the local working copy, +
  2. Path to one file inside the local working copy, +
+ +

If another value different from that specified above is passed to +action value variable, the `centos-art.sh' script prints an error +message and ends script execution. +

+ +
+
Function: cli_checkFiles FILE [TYPE] + +
+

Verify file existence. +

+

cli_checkFiles receives a FILE absolute path and performs +file verification as specified in TYPE. When TYPE is not +specified, cli_checkFiles verifies FILE existence, no +matter what kind of file it be. If TYPE is specified, use one +of the following values: +

+
+
`d'
+
`directory'
+

Ends script execution if FILE is not a directory. +

+

When you verify directories with cli_checkFiles, if directory doesn't +exist, `centos-art.sh' script asks you for confirmation in order +to create that directory. If you answer positively, +`centos-art.sh' script creates that directory and continues +script flows normally. Otherwise, if you answer negatively, +`centos-art.sh' ends script execution with an error and +documentation message. +

+
+
`f'
+
`regular-file'
+

Ends script execution if FILE is not a regular file. +

+
`h'
+
`symbolic-link'
+

Ends script execution if FILE is not a symbolic link. +

+
`x'
+
`execution'
+

Ends script execution if FILE is not executable. +

+
`fh'
+

Ends script execution if FILE is neither a regular file nor a +symbolic link. +

+
`fd'
+

Ends script execution if FILE is neither a regular file nor a +directory. +

+
`isInWorkingCopy'
+

Ends script execution if FILE is not inside the working copy. +

+
+ +

As default behaviour, if FILE passes all verifications, +`centos-art.sh' script continues with its normal flow. +

+ +
+
Function: cli_commitRepoChanges [LOCATION] + +
+

Syncronize changes between repository and working copy. +

+

The cli_commitRepoChanges function brings changes from the +central repository down to the working copy--using svn +update--, checks the working copy changes--using svn +status command--, prints status report--using both svn +update and svn status commands output, and finally, commits +recent changes from the working copy up to the repository--using +svn commit command--. +

+

Previous to commit the working copy changes up to the central +repository, the cli_commitRepoChanges function asks you to +verify changes--using svn diff command--, and later, +another confirmation question is shown to be sure you really want to +commit changes up to central repository. +

+

If LOCATION argument is not specified, the value of +ACTIONVAL variable is used as reference instead. +

+
+
----------------------------------------------------------------------
+--> 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.
+----------------------------------------------------------------------
+
+

Figure 2.3: The cli_commitRepoChanges function output. + +

+

Call the cli_commitRepoChanges function before or/and after +calling functions that modify files or directories inside the working +copy as you may need to. +

+ +
+
Function: cli_doParseArguments + +
+

Redefine arguments (ARGUMENTS) global variable using +getopt command output. For more information about how to use +cli_doParseArguments function, see ARGUMENTS variable +description above. +

+ +
+
Function: cli_doParseArgumentsReDef $@ + +
+

Initialize/reset arguments (ARGUMENTS) global variable using +positional parameters variable ($@) as reference. +

+

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 cli_doParseArgumentsReDef with the positional +parameters variable ($@), set as first argument, to that +specific function you want to redefine positional parameters at. +

+ +
+
Function: cli_getArguments + +
+

Initialize function name (FUNCNAM), action name +(ACTIONNAM), and action value (ACTIONVAL) global +variables, using positional parameters passed in $@ variable. +

+

The cli_getArguments function is called from cli.sh +function script, using cli function positional parameters +(i.e., the positional parameters passed as arguments in the +command-line) as first function argument. +

+

Once command-line positional parameters are accesible to +`centos-art.sh' script execution evironment, +cli_getArguments uses regular expression to retrive +action variables from first and second argument. The first argument +defines the value used as function name (FUNCNAM), and the +second argument defines both values used as action name +(ACTIONNAM) and action value (ACTIONVAL), respectively. +

+

The first argument is a word in lower case. This word specifies the +name of the functionality you want to use (e.g., `render' to +render images, `manual' to work on documentation, and so on.) +

+

The second argument has a long option style (e.g., +`--option=value'). The `--option' represents the action name +(ACTIONNAM), and the characters inbetween the equal sign +(`=') and the first space character, are considered as the action +value (ACTIONVAL). In order to provide action values with space +characters inbetween you need to enclose action value with quotes like +in `--option='This is long value with spaces inbetween''. +Generally, action values are used to specify paths over which the +action name acts on. +

+

Once action related variables (i.e., FUNCNAM, ACTIONNAM, +and ACTIONVAL) are defined and validated, +cli_getArguments shifts the positional arguments to remove the +first two arguments passed (i.e., those used to retrive action related +variables) and redefine the arguments (ARGUMENTS) global +variable with the new positional parameters information. +

+ +
+
Function: cli_getFunctions + +
+

Initialize funtionalities supported by `centos-art.sh' script. +

+

Functionalities supported by `centos-art.sh' script are organized +in functionality directories under +`trunk/Scripts/Bash/Functions/' 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). +

+

In order for `centos-art.sh' script to recognize a functionality, +such functionality needs to be stored under +`trunk/Scripts/Bash/Functions/' 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 `functionality +directory'. +

+

Inside each functionality directory, the functionalty itself is +implemented through function scripts. Function scripts are organized +in files independently one another and written in `camelCase' +format with the function name as prefix. Separation between prefix +and description is done using underscore (`_') character. +

+

In order for `centos-art.sh' script to load functionalities +correctly, function definition inside function scripts should be set +using the `function' reserved word, just as in the following +example: +

+
function prefix_doSomething {
+
+    # Do something here...
+
+}
+
+

The above function definition is just a convenction we use, in order +to make identification of function names easier read and automate by +`centos-art.sh' script initialization commands, once +`centos-art.sh' script determines which functionality directory +to use. Specifically, in order to initialize and export functions, +`centos-art.sh' script executes all function scripts inside the +functionality directory, and later grep on them using a +regular expression pattern, where the `function' reserved word is +used as reference to retrive the function names and export them to +`centos-art.sh' script execution environment, and so, make +function definitions --from function scripts inside the functionality +directory-- available for further calls. +

+

If the functionality specified in the command-line first argument +doesn't have a functionality directory, `centos-art.sh' script +considers the functionality provided in the command-line as invalid +functionality and immediatly stops script execution with an error +message. +

+

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: +

+
#!/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...
+
+}
+
+ +
+
Function: cli_getCountryCodes [FILTER] + +
+

Output country codes supported by `centos-art.sh' script. +

+

The cli_getCountryCodes function outputs a list with country +codes as defined in ISO3166 standard. When FILTER is provided, +cli_getCountryCodes outputs country codes that match +FILTER regular expression pattern. +

+ +
+
Function: cli_getCountryName [FILTER] + +
+

Outputs country name supported by `centos-art.sh' script. +

+

The cli_getCountryName 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, cli_getCountryName returns the +country name that matches the locale code specified in FILTER, +exactly. +

+ +
+
Function: cli_getCurrentLocale + +
+

Output current locale used by `centos-art.sh' script. +

+

The cli_getCurrentLocale function uses LANG environment +variable to build a locale pattern that is later applied to +cli_getLocales function output in order to return the current +locale that `centos-art.sh' script works with. +

+

The current locale information, returned by +cli_getCurrentLocale, is output from more specific to less +specific. For example, if `en_GB' locale exists in +cli_getLocales function output, the `en_GB' locale would +take precedence before `en' locale. +

+

Locale precedence selection is quite important in order to define the +locale type we use for message translations. For example, if +`en_GB' is used, we are also saying that the common language +specification for English language (i.e., `en') is no longer +used. Instead, we are using English non-common country-specific +language specifications like `en_AU', `en_BW', `en_GB', +`en_US', etc., for message translations. +

+

Use cli_getCurrentLocale function to know what current locale +information to use inside `centos-art.sh' script. +

+ +
+
Function: cli_getFilesList [LOCATION] + +
+

Output list of files to process. +

+

The cli_getFilesList function uses LOCATION variable as +source location to build a list of files just as specified by regular +expression (REGEX) global variable. Essentially, what the +cli_getFilesList function does is using find command +to look for files in the location (LOCATION) just as posix-egrep +regular expression (REGEX) specifies. +

+

If LOCATION is not specified when cli_getFilesList +function is called, the action value (ACTIONVAL) global variable +is used as location value instead. +

+

By default, if the regular expression (REGEX) global variable is +not redefined after its first definition in the cli function, +all files that match default regular expression value (i.e., +`.+') 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 cli function and before calling +cli_getFilesList function, the last value you specifed is used +instead. +

+

When you need to customize the regular expression (REGEX) 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 `local' 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. +

+

As result, the cli_getFilesList re-defines the value of +FILES variable with the list of files the find command +returned. As example, consider the following construction: +

+
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
+
+}
+
+
+ +
+
Function: cli_getLangCodes [FILTER] + +
+

Outputs language codes supported by `centos-art.sh' script. +

+

cli_getLangCodes function outputs a list of language codes as +defined in ISO639 standard. When FILTER is provided, +cli_getLangCodes outputs language codes that match FILTER +regular expression pattern. +

+ +
+
Function: cli_getLangName [FILTER] + +
+

Outputs language names supported by `centos-art.sh' script. +

+

cli_getLangName function reads one language locale code in the +format LL_CC and outputs the language related name as in ISO639. If +filter is specified, cli_getLangName returns the language name +that matches the locale code specified in FILTER, exactly. +

+ +
+
Function: cli_getLocales + +
+

Output locale codes supported by `centos-art.sh' script. +

+

Occasionally, you use cli_getLocales function to add locale +information in non-common country-specific language (`LL_CC') +format for those languages (e.g., `bn_IN', `pt_BR', etc.) +which locale differences cannot be solved using common language +specifications (`LL') into one unique common locale specification +(e.g., `bn', `pt', etc.). +

+ +
+
Function: cli_getRepoName NAME TYPE + +
+

Sanitate file names. +

+

Inside `centos-art.sh' script, specific functionalities rely both +in cli_getRepoName and repository file system organization to +achieve their goals. Consider cli_getRepoName function as +central place to manage file name convenctions for other functions +inside `centos-art.sh' script. +

+
Important

Important

cli_getRepoName function doesn't verify file +or directory existence, for that purpose use cli_checkFiles +function instead. +

+ +

The NAME variable contains the file name or directory name you +want to sanitate. +

+

The TYPE variable specifies what type of sanitation you want to +perform on NAME. The TYPE can be one of the following +values: +

+
+
`d'
+
`directory'
+

Sanitate directory NAMEs. +

+
`f'
+
`regular-file'
+

Sanitate regular file NAMEs. +

+
+ +

Use cli_getRepoName function to sanitate file names and +directory names before their utilization. +

+

Use cli_getRepoName when you need to change file name +convenctions inside `centos-art.sh' script. +

+

When we change file name convenctions inside cli_getRepoName +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 (-- Removed(pxref:trunk Scripts Bash Functions Path) --, for more +information). +

+ +
+
Function: cli_getRepoStatus [LOCATION] + +
+

Request repository status. +

+

This function requests the status of a LOCATION inside the +working copy using the svn status command and returns the +first character in the output line, just as described in svn +help status. If LOCATION is not a regular file or a directory, +inside the working copy, the `centos-art.sh' script prints a +message and ends its execution. +

+

Use this function to perform verifications based a repository +LOCATION status. +

+ +
+
Function: cli_getTemporalFile NAME + +
+

Output absolute path to temporal file NAME. +

+

The cli_getTemporalFile function uses `/tmp' directory as +source location to store temporal files, the `centos-art.sh' +script name, and a random identification string to let you run more +than one `centos-art.sh' script simultaneously on the same user +session. For example, due the following temporal file defintion: +

+
cli_getTemporalFile $FILE
+
+

If FILE name is `instance.svg' and the unique random string +is `f16f7b51-ac12-4b7f-9e66-72df847f12de', the final temporal +file, built from previous temporal file definition, would be: +

+
/tmp/centos-art.sh-f16f7b51-ac12-4b7f-9e66-72df847f12de-instance.svg
+
+

When you use the cli_getTemporalFile 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: +

+
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
+
+

Use the cli_getTemporalFile function whenever you need to +create temporal files inside `centos-art.sh' script. +

+ +
+
Function: cli_getThemeName + +
+

Output theme name. +

+

In order for cli_getThemeName function to extract theme name +correctly, the ACTIONVAL variable must contain a directory path +under `trunk/Identity/Themes/Motifs/' directory structure. +Otherwise, cli_getThemeName returns an empty string. +

+ +
+
Function: cli_printMessage MESSAGE [FORMAT] + +
+

Define standard output message definition supported by +`centos-art.sh' script. +

+

When FORMAT is not specified, cli_printMessage outputs +information just as it was passed in MESSAGE variable. +Otherwise, FORMAT can take one of the following values: +

+
+
`AsHeadingLine'
+

To print heading messages. +

----------------------------------------------------------------------
+$MESSAGE
+----------------------------------------------------------------------
+
+
+
`AsWarningLine'
+

To print warning messages. +

----------------------------------------------------------------------
+WARNING: $MESSAGE
+----------------------------------------------------------------------
+
+
+
`AsNoteLine'
+

To print note messages. +

----------------------------------------------------------------------
+NOTE: $MESSAGE
+----------------------------------------------------------------------
+
+
+
`AsUpdatingLine'
+

To print `Updating' messages on two-columns format. +

Updating        $MESSAGE
+
+
+
`AsRemovingLine'
+

To print `Removing' messages on two-columns format. +

Removing        $MESSAGE
+
+
+
`AsCheckingLine'
+

To print `Checking' messages on two-columns format. +

Checking        $MESSAGE
+
+
+
`AsCreatingLine'
+

To print `Creating' messages on two-columns format. +

Creating        $MESSAGE
+
+
+
`AsSavedAsLine'
+

To print `Saved as' messages on two-columns format. +

Saved as        $MESSAGE
+
+
+
`AsLinkToLine'
+

To print `Linked to' messages on two-columns format. +

Linked to       $MESSAGE
+
+
+
`AsMovedToLine'
+

To print `Moved to' messages on two-columns format. +

Moved to        $MESSAGE
+
+
+
`AsTranslationLine'
+

To print `Translation' messages on two-columns format. +

Translation     $MESSAGE
+
+
+
`AsConfigurationLine'
+

To print `Configuration' messages on two-columns format. +

Configuration   $MESSAGE
+
+
+
`AsResponseLine'
+

To print response messages on one-column format. +

--> $MESSAGE
+
+
+
`AsRequestLine'
+

To print request messages on one-column format. Request messages +output messages with one colon (`:') and without trailing newline +(`\n') at message end. +

$MESSAGE:
+
+
+
`AsYesOrNoRequestLine'
+

To print `yes or no' request messages on one-column format. If +something different from `y' is answered (when using +en_US.UTF-8 locale), script execution ends immediatly. +

+
$MESSAGE [y/N]:
+
+

When we use `centos-art.sh' script in a locale different from +en_US.UTF-8, confirmation answer may be different from +`y'. For example, if you use es_ES.UTF-8 locale, the +confirmation question would look like: +

+
$MESSAGE [s/N]:
+
+

and the confirmation answer would be `s', as it is on Spanish +`sí' word. +

+

Definition of which confirmation word to use is set on translation +messages for your specific locale information. -- Removed(xref:trunk Scripts +Bash Functions Locale) --, for more information about locale-specific +translation messages. +

+
+
`AsToKnowMoreLine'
+

To standardize `to know more, run the following command:' +messages. When the `AsToKnowMoreLine' option is used, the +MESSAGE value should be set to "$(caller)". caller +is a Bash builtin that returns the context of the current subroutine +call. `AsToKnowMoreLine' option uses caller builtin +output to build documentation entries dynamically. +

+
----------------------------------------------------------------------
+To know more, run the following command:
+centos-art manual --read='path/to/dir'
+----------------------------------------------------------------------
+
+

Use `AsToKnowMoreLine' option after errors and for intentional +script termination. +

+
+
`AsRegularLine'
+

To standardize regular messages on one-column format. +

+

When MESSAGE contains a colon inside (e.g., `description: +message'), the cli_printMessage function outputs MESSAGE +on two-columns format. +

+
+ +

Use cli_printMessage function whenever you need to output +information from `centos-art.sh' script. +

+
Info

Tip

To improve two-columns format, change the following file: +

trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
+
+
+ + + +

2.63.3.3 Specific functions

+ +

The following specific functions of `centos-art.sh' script, are +available for you to use: +

+ + +

2.63.4 See also

+ + +
2.61 The `trunk/Scripts/Bash' Directory   +
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_68.html b/Manual/repository-html/repository_68.html index eb690e1..dbb0c22 100644 --- a/Manual/repository-html/repository_68.html +++ b/Manual/repository-html/repository_68.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.64 The trunk/Scripts/Bash/Cli/Functions/Html Directory +CentOS Artwork Repository: 2.64 The trunk/Scripts/Bash/Cli/Functions/Help Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.64 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory

+ + +

2.64 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory

- +

2.64.1 Goals

- +

2.64.2 Description

- +

2.64.3 Usage

- +

2.64.4 See also

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_69.html b/Manual/repository-html/repository_69.html index a37236a..aacf3cd 100644 --- a/Manual/repository-html/repository_69.html +++ b/Manual/repository-html/repository_69.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.65 The trunk/Scripts/Bash/Cli/Functions/Locale Directory +CentOS Artwork Repository: 2.65 The trunk/Scripts/Bash/Cli/Functions/Html Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.65 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory

+ + +

2.65 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory

- +

2.65.1 Goals

- +

2.65.2 Description

-

This command looks for `.sh' files inside Bash directory and -extracts translatable strings from files, using xgettext -command, in order to create a portable object template -(`centos-art.sh.pot') file for them. -

-

With the `centos-art.sh.pot' file up to date, the -centos-art command removes the temporal list of files sotred -inside `/tmp' directory and checks the current language of your -user's session to create a portable object file for it, in the -location `$CLI_LANG/$CLI_LANG.po'. -

-

The CLI_LANG variable discribes the locale language used to -output messages inside centos-art command. The locale -language used inside centos-art command is taken from the -LANG environment variable. The CLI_LANG variable has the -`LL_CC' format, where `LL' is a language code from the -ISO-639 standard, and `CC' a country code from the ISO-3166 -standard. -

-

The LANG environment variable is set when you do log in to your -system. If you are using a graphical session, change language to your -native language and do login. That would set and exoprt the LANG -environment variable to the correct value. On the other side, if you -are using a text session edit your `~/.bash_profile' file to set -and export the LANG environment variable to your native locale -as defines the locale -a command output; do logout, and do -login again. -

-

At this point, the LANG environment variable has the appropriate -value you need, in order to translate centos-art.sh messages -to your native language (the one set in LANG environment -variable). -

-

With the `$CLI_LANG/$CLI_LANG.po' file up to date, the -centos-art opens it for you to update translation strings. -The centos-art command uses the value of EDITOR -environment variable to determine your favorite text editor. If no -value is defined on EDITOR, the `/usr/bin/vim' text editor -is used as default. -

-

When you finishd PO file edition and quit text editor, the -centos-art command creates the related machine object in the -location `$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo'. -

-

At this point, all translations you made in the PO file should be -available to your language when runing centos-art.sh script. -

-

In order to make the centos-art.sh internationalization, the -centos-art.sh script was modified as described in the -gettext info documentation (info gettext). You -can find such modifications in the following files: -

- - - +

2.65.3 Usage

-
-
`centos-art locale --edit'
-

Use this command to translate command-line interface output messages -in the current system locale you are using (as specified in LANG -environment variable). -

-
`centos-art locale --list'
-

Use this command to see the command-line interface locale report. -

-
+ - +

2.65.4 See also

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_7.html b/Manual/repository-html/repository_7.html index c10a219..cd4d15e 100644 --- a/Manual/repository-html/repository_7.html +++ b/Manual/repository-html/repository_7.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + - + -CentOS Artwork Repository: 2.66 The trunk/Scripts/Bash/Cli/Functions/Manual Directory +CentOS Artwork Repository: 2.66 The trunk/Scripts/Bash/Cli/Functions/Locale Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.66 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory

+ + +

2.66 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory

- +

2.66.1 Goals

- +

2.66.2 Description

+

This command looks for `.sh' files inside Bash directory and +extracts translatable strings from files, using xgettext +command, in order to create a portable object template +(`centos-art.sh.pot') file for them. +

+

With the `centos-art.sh.pot' file up to date, the +centos-art command removes the temporal list of files sotred +inside `/tmp' directory and checks the current language of your +user's session to create a portable object file for it, in the +location `$CLI_LANG/$CLI_LANG.po'. +

+

The CLI_LANG variable discribes the locale language used to +output messages inside centos-art command. The locale +language used inside centos-art command is taken from the +LANG environment variable. The CLI_LANG variable has the +`LL_CC' format, where `LL' is a language code from the +ISO-639 standard, and `CC' a country code from the ISO-3166 +standard. +

+

The LANG environment variable is set when you do log in to your +system. If you are using a graphical session, change language to your +native language and do login. That would set and exoprt the LANG +environment variable to the correct value. On the other side, if you +are using a text session edit your `~/.bash_profile' file to set +and export the LANG environment variable to your native locale +as defines the locale -a command output; do logout, and do +login again. +

+

At this point, the LANG environment variable has the appropriate +value you need, in order to translate centos-art.sh messages +to your native language (the one set in LANG environment +variable). +

+

With the `$CLI_LANG/$CLI_LANG.po' file up to date, the +centos-art opens it for you to update translation strings. +The centos-art command uses the value of EDITOR +environment variable to determine your favorite text editor. If no +value is defined on EDITOR, the `/usr/bin/vim' text editor +is used as default. +

+

When you finishd PO file edition and quit text editor, the +centos-art command creates the related machine object in the +location `$CLI_LANG/LC_MESSAGES/$TEXTDOMAIN.mo'. +

+

At this point, all translations you made in the PO file should be +available to your language when runing centos-art.sh script. +

+

In order to make the centos-art.sh internationalization, the +centos-art.sh script was modified as described in the +gettext info documentation (info gettext). You +can find such modifications in the following files: +

+ + - +

2.66.3 Usage

- +
+
`centos-art locale --edit'
+

Use this command to translate command-line interface output messages +in the current system locale you are using (as specified in LANG +environment variable). +

+
`centos-art locale --list'
+

Use this command to see the command-line interface locale report. +

+
- +

2.66.4 See also

- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_71.html b/Manual/repository-html/repository_71.html index 9c4f761..5d7fc51 100644 --- a/Manual/repository-html/repository_71.html +++ b/Manual/repository-html/repository_71.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.67 The trunk/Scripts/Bash/Cli/Functions/Path Directory +CentOS Artwork Repository: 2.67 The trunk/Scripts/Bash/Cli/Functions/Manual Directory - - + + @@ -55,370 +55,53 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.67 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory

- - - -

2.67.1 Goals

- -

This section exists to organize files related to path -functiontionality. The path functionality standardizes -movement, syncronization, branching, tagging, and general file -maintainance inside the repository. -

- - -

2.67.2 Description

- -

"CentOS like trees, has roots, trunk, branches, leaves and -flowers. Day by day they work together in freedom, ruled by the laws -of nature and open standards, to show the beauty of its existence." -

- - -

2.67.2.1 Repository layout

- -

The repository layout describes organization of files and directories -inside the repository. The repository layout provides the standard -backend required for automation scripts to work correctly. If such -layout changes unexpectedly, automation scripts may confuse themselves -and stop doing what we expect from them to do. -

-

As convenction, inside CentOS Artwork Repository, we organize files -and directories related to CentOS corporate visual identity under -three top level directories named: `trunk/', `branches/', -and `tags/'. -

-

The `trunk/' directory (see section The `trunk' Directory) organizes the main -development line of CentOS corporate visual identity. Inside -`trunk/' directory structure, the CentOS corporate visual -identity concepts are implemented using directories. There is one -directory level for each relevant concept inside the repository. The -`trunk/' directory structure is mainly used to perform -development tasks related to CentOS corporate visual identity. -

-

The `branches/' directory () oranizes -parallel development lines to `trunk/' directory. The -`branches/' directory is used to set points in time where -develpment lines are devided one from another taking separte and -idependent lives that share a common past from the point they were -devided on. The `branches/' directory is mainly used to perform -quality assurance tasks related to CentOS corporate visual identity. -

-

The `tags/' directory (see section The `tags' Directory) organizes parallel frozen -lines to `branches/' directory. The parallel frozen lines are -immutable, nothing change inside them once they has been created. The -`tags/' directory is mainly used to publish final releases of -CentOS corporate visual identity. -

-

The CentOS Artwork Repository layout is firmly grounded on a -Subversion base. Subversion (http://subversion.tigris.org) is a -version control system, which allows you to keep old versions of files -and directories (usually source code), keep a log of who, when, and -why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a -single copy of the master sources. This copy is called the source -"repository"; it contains all the information to permit extracting -previous versions of those files at any time. -

- - -

2.67.2.2 Repository name convenctions

- -

Repository name convenctions help us to maintain consistency of names -inside the repository. -

-

Repository name convenctions are applied to files and directories -inside the repository layout. As convenction, inside the repository -layout, file names are all written in lowercase -(`01-welcome.png', `splash.png', `anaconda_header.png', -etc.) and directory names are all written capitalized (e.g., -`Identity', `Themes', `Motifs', `TreeFlower', -etc.). -

-

Repository name convenctions are implemented inside the -cli_getRepoName function of `centos-art.sh' script. With -cli_getRepoName function we reduce the amount of commands and -convenctions to remember, concentrating them in just one single place -to look for fixes and improvements. -

- - -

2.67.2.3 Repository work flow

- -

Repository work flow describes the steps and time intervals used to -produce CentOS corporate visual identity inside CentOS Artwork -Repository. -

-

To illustrate repository work flow let's consider themes' development -cycle. -

-

Initially, we start working themes on their trunk development line -(e.g., `trunk/Identity/Themes/Motifs/TreeFlower/'), here we -organize information that cannot be produced automatically (i.e., -background images, concepts, color information, screenshots, etc.). -

-

Later, when theme trunk development line is considered "ready" for -implementation (e.g., all required backgrounds have been designed), -we create a branch for it (e.g., -`branches/Identity/Themes/Motifs/TreeFlower/1/'). Once the -branch has been created, we forget that branch and continue working -the trunk development line while others (e.g., an artwork quality -assurance team) test the new branch for tunning it up. -

-

Once the branch has been tunned up, and considered "ready" for -release, it is freezed under `tags/' directory (e.g., -`tags/Identity/Themes/Motifs/TreeFower/1.0/') for packagers, -webmasters, promoters, and anyone who needs images from that CentOS -theme the tag was created for. -

-

Both branches and tags, inside CentOS Artwork Repository, use -numerical values to identify themselves under the same location. -Branches start at one (i.e., `1') and increment one unit for each -branch created from the same trunk development line. Tags start at -zero (i.e., `0') and increment one unit for each tag created from -the same branch development line. -

-
Convenction

Convenction

Do not freeze trunk development lines using tags -directly. If you think you need to freeze a trunk development line, -create a branch for it and then freeze that branch instead. -

- -

The trunk development line may introduce problems we cannot see -immediatly. Certainly, the high changable nature of trunk development -line complicates finding and fixing such problems. On the other hand, -the branched development lines provide a more predictable area where -only fixes/corrections to current content are commited up to -repository. -

-

If others find and fix bugs inside the branched development line, we -could merge such changes/experiences back to trunk development line -(not visversa) in order for future branches, created from trunk, to -benefit. -

-

Time intervals used to create branches and tags may vary, just as -different needs may arrive. For example, consider the release schema -of CentOS distribution: one major release every 2 years, security -updates every 6 months, support for 7 years long. Each time a CentOS -distribution is released, specially if it is a major release, there is -a theme need in order to cover CentOS distribution artwork -requirements. At this point, is where CentOS Artwork Repository comes -up to scene. -

-

Before releasing a new major release of CentOS distribution we create -a branch for one of several theme development lines available inside -the CentOS Artwork Repository, perform quality assurance on it, and -later, freeze that branch using tags. Once a the theme branch has been -frozen (under `tags/' directory), CentOS Packagers (the persons -whom build CentOS distribution) can use that frozen branch as source -location to fulfill CentOS distribution artwork needs. The same -applies to CentOS Webmasters (the persons whom build CentOS websites), -and any other visual manifestation required by the project. -

- + -

2.67.2.4 Parallel directories

+

2.67 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory

-

Inside CentOS Artwork Repository, parallel directories are simple -directory entries built from a common parent directory and placed in a -location different to that, the common parent directory is placed on. -Parallel directories are useful to create branches, tags, -translations, documentation, pre-rendering configuration script, and -similar directory structures. -

-

Parallel directories take their structure from one unique parent -directory. Inside CentOS Artwork Repository, this unique parent -directory is under `trunk/Identity' location. The -`trunk/Identity' location must be considered the reference for -whatever information you plan to create inside the repository. -

-

In some circumstances, parallel directories may be created removing -uncommon information from their paths. Uncommon path information -refers to those directory levels in the path which are not common for -other parallel directories. For example, when rendering -`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory -structure, the `centos-art.sh' script removes the -`Motifs/TreeFlower/' directory levels from path, in order to -build the parallel directory used to retrived translations, and -pre-rendering configuration scripts required by render -functionality. -

-

Another example of parallel directory is the documentation structure -created by manual functionality. This time, -`centos-art.sh' script uses parallel directory information with -uncommon directory levels to build the documentation entry required by -Texinfo documentation system, inside the repository. -

-

Othertimes, parallel directories may add uncommon information to their -paths. This is the case we use to create branches and tags. When we -create branches and tags, a numerical identifier is added to parallel -directory structure path. The place where the numerical identifier is -set on is relevant to corporate visual identity structure and should -be carefully considered where it will be. -

-

When one parent directory changes, all their related parallel -directories need to be changed too. This is required in order for -parallel directories to retain their relation with the parent -directory structure. In the other hand, parallel directories should -never be modified under no reason but to satisfy the relation to their -parent directory structure. Liberal change of parallel directories -may suppresses the conceptual idea they were initially created for; -and certainly, things may stop working the way they should do. -

-

2.67.2.5 Syncronizing path information

+

2.67.1 Goals

-

Parallel directories are very useful to keep repository organized but -introduce some complications. For instance, consider what would -happen to functionalities like manual (`trunk Scripts Bash -Functions Manual') that rely on parent directory structures to create -documentation entries (using parallel directory structures) if one of -those parent directory structures suddenly changes after the -documentation entry has been already created for it? -

-

In such cases, functionalities like manual may confuse -themselves if path information is not updated to reflect the relation -with its parent directory. Such functionalities work with parent -directory structure as reference; if a parent directory changes, the -functionalities dont't even note it because they work with the last -parent directory structure available in the repository, no matter what -it is. -

-

In the specific case of documentation (the manual -functionality), the problem mentioned above provokes that older parent -directories, already documented, remain inside documentation directory -structures as long as you get your hands into the documentation -directory structure (`trunk/Manuals') and change what must be -changed to match the new parent directory structure. -

-

There is no immediate way for manual, and similar -functionalities that use parent directories as reference, to know when -and how directory movements take place inside the repository. Such -information is available only when the file movement itself takes -place inside the repository. So, is there, at the moment of moving -files, when we need to syncronize parallel directories with their -unique parent directory structure. -

-
Warning

Warning

There is not support for URL reference inside -`centos-art.sh' script. The `centos-art.sh' script is -designed to work with local files inside the working copy only. -

+ -

As CentOS Artwork Repository is built over a version control system, -file movements inside the repository are considered repository -changes. In order for these repository changes to be versioned, we -need to, firstly, add changes into the version control system, commit -them, and later, perform movement actions using version control system -commands. This configuration makes possible for everyone to know about -changes details inside the repository; and if needed, revert or update -them back to a previous revision. -

-

Finally, once all path information has been corrected, it is time to -take care of information inside the files. For instance, considere -what would happen if you make a reference to a documentation node, and -later the documentation node you refere to is deleted. That would make -Texinfo to produce error messages at export time. So, the -`centos-art.sh' script needs to know when such changes happen, in -a way they could be noted and handled without producing errors. -

-

2.67.2.6 What is the right place to store it?

+

2.67.2 Description

+ + -

Occasionly, you may find that new corporate visual identity components -need to be added to the repository. If that is your case, the first -question you need to ask yourself, before start to create directories -blindly all over, is: What is the right place to store it? -

-

The CentOS Community different free support vains (see: -http://wiki.centos.org/GettingHelp) are the best place to find -answers to your question, but going there with hands empty is not good -idea. It may give the impression you don't really care about. Instead, -consider the following suggestions to find your own comprehension and -so, make your propositions based on it. -

-

When we are looking for the correct place to store new files, to bear -in mind the corporate visual identity structure used inside the CentOS -Artwork Repository (see section The `trunk/Identity' Directory) would be probaly the best -advice we could offer, the rest is just matter of choosing appropriate -names. To illustrate this desition process let's consider the -`trunk/Identity/Themes/Motifs/TreeFlower' directory as example. -It is the trunk development line of TreeFlower artistic motif. -Artistic motifs are considered part of themes, which in turn are -considered part of CentOS corporate visual identity. -

-

When building parent directory structures, you may find that reaching -an acceptable location may take some time, and as it uses to happen -most of time; once you've find it, that may be not a definite -solution. There are many concepts that you need to play with, in -order to find a result that match the conceptual idea you try to -implement in the new directory location. To know which these concepts -are, split the location in words and read its documentation entry from -less specific to more specific. -

-

For example, the `trunk/Identity/Themes/Motifs/TreeFlower' -location evolved through several months of contant work and there is -no certain it won't change in the future, even it fixes quite well the -concept we are trying to implement. The concepts used in -`trunk/Identity/Themes/Distro/Motifs/TreeFlower' location are -described in the following commands, respectively: -

-
centos-art manual --read=turnk/
-centos-art manual --read=turnk/Identity/
-centos-art manual --read=turnk/Identity/Themes/
-centos-art manual --read=turnk/Identity/Themes/Motifs/
-centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
-
-

Other location concepts can be found similary as we did above, just -change the location we used above by the one you are trying to know -concepts for. -

2.67.3 Usage

-
-
centos-art path --copy='SRC' --to='DST'
-
-

Copy `SRC' to `DST' and schedule `DST' for -addition (with history). In this command, `SRC' and `DST' -are both working copy (WC) entries. -

-
-
centos-art path --delete='SRC'
-
-

Delete `DST'. In order for this command to work the file or -directory you intend to delete should be under version control first. -In this command, `SRC' is a working copy (WC) entry. -

-
-
+

2.67.4 See also

- - -
2.60 The `trunk/Scripts/Bash' Directory   -
@@ -426,12 +109,12 @@ In this command, `SRC' is a working copy (WC) entry. - - + +
[ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_72.html b/Manual/repository-html/repository_72.html index 6e43961..5166f1e 100644 --- a/Manual/repository-html/repository_72.html +++ b/Manual/repository-html/repository_72.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.68 The trunk/Scripts/Bash/Cli/Functions/Render Directory +CentOS Artwork Repository: 2.68 The trunk/Scripts/Bash/Cli/Functions/Path Directory - - + + @@ -60,762 +60,378 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] - + -

2.68 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory

+

2.68 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory

-

The render functionality exists to produce both identity and -translation files on different levels of information (i.e., different -languages, release numbers, architectures, etc.). -

-

The render functionality relies on "renderable directory -structures" to produce files. Renderable directory structures can be -either "identity directory structures" or "translation directory -structures" with special directories inside. -

-

2.68.1 Renderable identity directory structures

- -

Renderable identity directory structures are the starting point of -identity rendition. Whenever we want to render a component of CentOS -corporate visual identity, we need to point `centos-art.sh' to a -renderable identity directory structure. If such renderable identity -directory structure doesn't exist, then it is good time to create it. -

-

Inside the working copy, one renderable identity directory structures -represents one visual manifestation of CentOS corporate visual -identity, or said differently, each visual manifestation of CentOS -corporate visual identity should have one renderable identity -directory structure. -

-

Inside renderable identity directory structures, `centos-art.sh' -can render both image-based and text-based files. Specification of -whether a renderable identity directory structure produces image-based -or text-based content is a configuration action that takes place in -the pre-rendition configuration script of that renderable identity -directory structure. -

-

Inside renderable identity directory structures, content production is -organized in different configurations. A content production -configuration is a unique combination of the components that make an -identity directory structure renderable. One content production -configuration does one thing only (e.g., to produce untranslated -images), but it can be extended (e.g., adding translation files) to -achieve different needs (e.g., to produce translated images). +

2.68.1 Goals

+ +

This section exists to organize files related to path +functiontionality. The path functionality standardizes +movement, syncronization, branching, tagging, and general file +maintainance inside the repository.

-

2.68.1.1 Design template without translation

+

2.68.2 Description

-

The design template without translation configuration is based on a -renderable identity directory structure with an empty translation -directory structure. In this configuration, one design template -produces one untranslated file. Both design templates and final -untranslated files share the same file name, but they differ one -another in file-type and file-extension. +

"CentOS like trees, has roots, trunk, branches, leaves and +flowers. Day by day they work together in freedom, ruled by the laws +of nature and open standards, to show the beauty of its existence."

-

For example, to produce images without translations (there is no much -use in producing text-based files without translations), consider the -following configuration: -

-
-
One renderable identity directory structure:
-
-

In this example we used `Identity/Path/To/Dir' as the identity -component we want to produce untranslated images for. Identity -components can be either under `trunk/' or `branches/' -directory structure. -

-

The identity component (i.e., `Identity/Path/To/Dir', in this -case) is also the bond component we use to connect the identity -directory structures with their respective auxiliar directories (i.e., -translation directory structres and pre-rendition configuration -structures). The bond component is the path convenction that -`centos-art.sh' uses to know where to look for related -translations, configuration scripts and whatever auxiliar thing a -renderable directory structure may need to have. -

-
      | The bond component
-      |----------------->|
-trunk/Identity/Path/To/Dir  <-- Renderable identity directory structure.
-|-- Tpl                     <-- Design template directory.
-|   `-- file.svg            <-- Design template file.
-`-- Img                     <-- Directory used to store final files.
-    `-- file.png            <-- Final image-based file produced from
-                                design template file.
-
-

Inside design template directory, design template files are based on -SVG (Scalable Vector Graphics) and use the extension -.svg. Design template files can be organized using several -directory levels to create a simple but extensible configuration, -specially if translated images are not required. -

-

In order for SVG (Scalable Vector Graphics) files to be -considered "design template" files, they should be placed under the -design template directory and to have set a CENTOSARTWORK -object id inside. -

-

The CENTOSARTWORK word itself is a convenction name we use to -define which object/design area, inside a design template, the -`centos-art.sh' script will use to export as -PNG (Portable Network Graphic) image at rendition time. -Whithout such object id specification, the `centos-art.sh' script -cannot know what object/design area you (as designer) want to export -as PNG (Portable Network Graphic) image file. -

-
info

Note

At rendition time, the content of `Img/' directory -structure is produced by `centos-art.sh' automatically. -

-

When a renderable identity directory structure is configured to -produce image-based content, `centos-art.sh' produces -PNG (Portable Network Graphics) files with the .png -extension. Once the base image format has been produced, it is -possible for `centos-art.sh' to use it in order to automatically -create other image formats that may be needed (-- Removed(pxref:trunk Scripts -Bash Functions Render Config) --). -

-

Inside the working copy, you can find an example of "design template -without translation" configuration at `trunk/Identity/Models/'. + +

2.68.2.1 Repository layout

+ +

The repository layout describes organization of files and directories +inside the repository. The repository layout provides the standard +backend required for automation scripts to work correctly. If such +layout changes unexpectedly, automation scripts may confuse themselves +and stop doing what we expect from them to do. +

+

As convenction, inside CentOS Artwork Repository, we organize files +and directories related to CentOS corporate visual identity under +three top level directories named: `trunk/', `branches/', +and `tags/'. +

+

The `trunk/' directory (see section The `trunk' Directory) organizes the main +development line of CentOS corporate visual identity. Inside +`trunk/' directory structure, the CentOS corporate visual +identity concepts are implemented using directories. There is one +directory level for each relevant concept inside the repository. The +`trunk/' directory structure is mainly used to perform +development tasks related to CentOS corporate visual identity. +

+

The `branches/' directory () oranizes +parallel development lines to `trunk/' directory. The +`branches/' directory is used to set points in time where +develpment lines are devided one from another taking separte and +idependent lives that share a common past from the point they were +devided on. The `branches/' directory is mainly used to perform +quality assurance tasks related to CentOS corporate visual identity. +

+

The `tags/' directory (see section The `tags' Directory) organizes parallel frozen +lines to `branches/' directory. The parallel frozen lines are +immutable, nothing change inside them once they has been created. The +`tags/' directory is mainly used to publish final releases of +CentOS corporate visual identity. +

+

The CentOS Artwork Repository layout is firmly grounded on a +Subversion base. Subversion (http://subversion.tigris.org) is a +version control system, which allows you to keep old versions of files +and directories (usually source code), keep a log of who, when, and +why changes occurred, etc., like CVS, RCS or SCCS. Subversion keeps a +single copy of the master sources. This copy is called the source +"repository"; it contains all the information to permit extracting +previous versions of those files at any time.

-

See section The `trunk/Identity' Directory, for more information. + + +

2.68.2.2 Repository name convenctions

+ +

Repository name convenctions help us to maintain consistency of names +inside the repository.

-
-
One translation directory structure:
-
-

In order for an identity entry to be considered an identity renderable -directory structure, it should have a translation entry. The content -of the translation entry is relevant to determine how to process the -identity renderable directory entry. -

-

If the translation entry is empty (i.e., there is no file inside it), -`centos-art.sh' interprets the identity renderable directory -structure as a "design templates without translation" configuration. -

-
                   | The bond component
-                   |----------------->|
-trunk/Translations/Identity/Path/To/Dir
-`-- (empty)
-
-

If the translation entry is not empty, `centos-art.sh' can -interpret the identity renderable directory structure as one of the -following configurations: "design template with translation -(one-to-one)" or "design template with translation (optimized)". -Which one of these configurations is used depends on the value -assigned to the matching list (MATCHINGLIST) variable in the -pre-rendition configuration script of the renderable identity -directory structure we are producing images for. -

-

If the matching list variable is empty (as it is by default), then -"design template with translation (one-to-one)" configuration is -used. In this configuration it is required that both design templates -and translation files have the same file names. This way, one -translation files is applied to one design template, to produce -one translated image. -

-

If the matching list variable is not empty (because you redefine it in -the pre-rendition configuration script), then "design template with -translation (optimized)" configuration is used instead. In this -configuration, design templates and translation files don't need to -have the same names since such name relationship between them is -specified in the matching list properly. -

-

-- Removed(xref:trunk Translations) --, for more information. +

Repository name convenctions are applied to files and directories +inside the repository layout. As convenction, inside the repository +layout, file names are all written in lowercase +(`01-welcome.png', `splash.png', `anaconda_header.png', +etc.) and directory names are all written capitalized (e.g., +`Identity', `Themes', `Motifs', `TreeFlower', +etc.).

-
-
One pre-rendition configuration script:
-
-

In order to make an identity directory structure renderable, a -pre-rendition configuration script should exist for it. The -pre-rendition configuration script specifies what type of rendition -does `centos-art.sh' will perform over the identity directory -structure and how does it do that. -

-
                                           | The bond component
-                                           |----------------->|
-trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-
-

In this configuration the pre-rendition configuration script -(`render.conf.sh') would look like the following: +

Repository name convenctions are implemented inside the +cli_getRepoName function of `centos-art.sh' script. With +cli_getRepoName function we reduce the amount of commands and +convenctions to remember, concentrating them in just one single place +to look for fixes and improvements.

-
function render_loadConfig {
 
-    # Define rendition actions.
-    ACTIONS[0]='BASE:renderImage'
+
+
 2.68.2.3 Repository work flow 

+
+
Repository work flow describes the steps and time intervals used to
+produce CentOS corporate visual identity inside CentOS Artwork
+Repository.  
+

+
To illustrate repository work flow let's consider themes' development
+cycle. 
+

+
Initially, we start working themes on their trunk development line
+(e.g., `trunk/Identity/Themes/Motifs/TreeFlower/'), here we
+organize information that cannot be produced automatically (i.e.,
+background images, concepts, color information, screenshots, etc.).
+

+
Later, when theme trunk development line is considered "ready" for
+implementation (e.g.,  all required backgrounds have been designed),
+we create a branch for it (e.g.,
+`branches/Identity/Themes/Motifs/TreeFlower/1/').  Once the
+branch has been created, we forget that branch and continue working
+the trunk development line while others (e.g., an artwork quality
+assurance team) test the new branch for tunning it up. 
+

+
Once the branch has been tunned up, and considered "ready" for
+release, it is freezed under `tags/' directory (e.g.,
+`tags/Identity/Themes/Motifs/TreeFower/1.0/') for packagers,
+webmasters, promoters, and anyone who needs images from that CentOS
+theme the tag was created for.
+

+
Both branches and tags, inside CentOS Artwork Repository, use
+numerical values to identify themselves under the same location.
+Branches start at one (i.e., `1') and increment one unit for each
+branch created from the same trunk development line.  Tags start at
+zero (i.e., `0') and increment one unit for each tag created from
+the same branch development line.
+

+
Convenction
Convenction
 Do not freeze trunk development lines using tags
+directly.  If you think you need to freeze a trunk development line,
+create a branch for it and then freeze that branch instead.
+

 
-}
-
-

Since translation directory structure is empty, `centos-art.sh' -assumes a "design template without translation" configuration to -produce untranslated images. -

-

To produce untranslated images, `centos-art.sh' takes one design -template and creates one temporal instance from it. Later, -`centos-art.sh' uses the temporal design template instance as -source file to export the final untranslated image. The action of -exporting images from SVG (Scalable Vector Graphics) to -PNG (Portable Network Graphics) is possible thanks to -Inkscape's command-line interface and the CENTOSARTWORK object -id we previously set inside design templates. -

-
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
--------------------------------------------------
-0 | Execute centos-art.sh on renderable identity directory structure.
---v----------------------------------------------
-trunk/Identity/Path/To/Dir/Tpl/file.svg
--------------------------------------------------
-1 | Create instance from design template.
---v----------------------------------------------
-/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
--------------------------------------------------
-2 | Render untranslated image from design template instance.
---v----------------------------------------------
-trunk/Identity/NewDir/Img/file.png
--------------------------------------------------
-3 | Remove design template instance.
-
-

Finally, when the untranslated image has been created, the temporal -design template instance is removed. At this point, -`centos-art.sh' takes the next design template and repeats the -whole production flow once again (design template by design template), -until all design templates be processed. -

-

-- Removed(xref:trunk Scripts Bash Functions Render Config) --, for more -information. -

-
+

The trunk development line may introduce problems we cannot see +immediatly. Certainly, the high changable nature of trunk development +line complicates finding and fixing such problems. On the other hand, +the branched development lines provide a more predictable area where +only fixes/corrections to current content are commited up to +repository. +

+

If others find and fix bugs inside the branched development line, we +could merge such changes/experiences back to trunk development line +(not visversa) in order for future branches, created from trunk, to +benefit. +

+

Time intervals used to create branches and tags may vary, just as +different needs may arrive. For example, consider the release schema +of CentOS distribution: one major release every 2 years, security +updates every 6 months, support for 7 years long. Each time a CentOS +distribution is released, specially if it is a major release, there is +a theme need in order to cover CentOS distribution artwork +requirements. At this point, is where CentOS Artwork Repository comes +up to scene. +

+

Before releasing a new major release of CentOS distribution we create +a branch for one of several theme development lines available inside +the CentOS Artwork Repository, perform quality assurance on it, and +later, freeze that branch using tags. Once a the theme branch has been +frozen (under `tags/' directory), CentOS Packagers (the persons +whom build CentOS distribution) can use that frozen branch as source +location to fulfill CentOS distribution artwork needs. The same +applies to CentOS Webmasters (the persons whom build CentOS websites), +and any other visual manifestation required by the project. +

+ +

2.68.2.4 Parallel directories

+ +

Inside CentOS Artwork Repository, parallel directories are simple +directory entries built from a common parent directory and placed in a +location different to that, the common parent directory is placed on. +Parallel directories are useful to create branches, tags, +translations, documentation, pre-rendering configuration script, and +similar directory structures. +

+

Parallel directories take their structure from one unique parent +directory. Inside CentOS Artwork Repository, this unique parent +directory is under `trunk/Identity' location. The +`trunk/Identity' location must be considered the reference for +whatever information you plan to create inside the repository. +

+

In some circumstances, parallel directories may be created removing +uncommon information from their paths. Uncommon path information +refers to those directory levels in the path which are not common for +other parallel directories. For example, when rendering +`trunk/Identity/Themes/Motifs/TreeFlower/Distro' directory +structure, the `centos-art.sh' script removes the +`Motifs/TreeFlower/' directory levels from path, in order to +build the parallel directory used to retrived translations, and +pre-rendering configuration scripts required by render +functionality. +

+

Another example of parallel directory is the documentation structure +created by manual functionality. This time, +`centos-art.sh' script uses parallel directory information with +uncommon directory levels to build the documentation entry required by +Texinfo documentation system, inside the repository. +

+

Othertimes, parallel directories may add uncommon information to their +paths. This is the case we use to create branches and tags. When we +create branches and tags, a numerical identifier is added to parallel +directory structure path. The place where the numerical identifier is +set on is relevant to corporate visual identity structure and should +be carefully considered where it will be. +

+

When one parent directory changes, all their related parallel +directories need to be changed too. This is required in order for +parallel directories to retain their relation with the parent +directory structure. In the other hand, parallel directories should +never be modified under no reason but to satisfy the relation to their +parent directory structure. Liberal change of parallel directories +may suppresses the conceptual idea they were initially created for; +and certainly, things may stop working the way they should do. +

- -

2.68.1.2 Design template with translation (one-to-one)

- -

Producing untranslated images is fine in many cases, but not always. -Sometimes it is required to produce images in different languages and -that is something that untrasnlated image production cannot achieve. -However, if we fill its empty translation entry with translation files -(one for each design template) we extend the production flow from -untranslated image production to translated image production. -

-

In order for `centos-art.sh' to produce images correctly, each -design template should have one translation file and each translation -file should have one design template. Otherwise, if there is a -missing design template or a missing translation file, -`centos-art.sh' will not produce the final image related to the -missing component. -

-

In order for `centos-art.sh' to know which is the relation -between translation files and design templates the translation -directory structure is taken as reference. For example, the -`trunk/Translations/Identity/Path/To/Dir/file.sed' translation -file does match `trunk/Identity/Path/To/Dir/Tpl/file.svg' design -template, but it doesn't match -`trunk/Identity/Path/To/Dir/File.svg' or -`trunk/Identity/Path/To/Dir/Tpl/File.svg' or -`trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg' design -templates. -

-

The pre-rendition configuration script used to produce untranslated -images is the same we use to produce translated images. There is no -need to modify it. So, as we are using the same pre-rendition -configuration script, we can say that translated image production is -somehow an extended/improved version of untranslated image production. -

-
info

Note

If we use no translation file in the translation entry -(i.e., an empty directory), `centos-art.sh' assumes the -untranslated image production. If we fill the translation entry with -translation files, `centos-art.sh' assumes the translated image -production. + +

2.68.2.5 Syncronizing path information

+ +

Parallel directories are very useful to keep repository organized but +introduce some complications. For instance, consider what would +happen to functionalities like manual (`trunk Scripts Bash +Functions Manual') that rely on parent directory structures to create +documentation entries (using parallel directory structures) if one of +those parent directory structures suddenly changes after the +documentation entry has been already created for it? +

+

In such cases, functionalities like manual may confuse +themselves if path information is not updated to reflect the relation +with its parent directory. Such functionalities work with parent +directory structure as reference; if a parent directory changes, the +functionalities dont't even note it because they work with the last +parent directory structure available in the repository, no matter what +it is. +

+

In the specific case of documentation (the manual +functionality), the problem mentioned above provokes that older parent +directories, already documented, remain inside documentation directory +structures as long as you get your hands into the documentation +directory structure (`trunk/Manuals') and change what must be +changed to match the new parent directory structure. +

+

There is no immediate way for manual, and similar +functionalities that use parent directories as reference, to know when +and how directory movements take place inside the repository. Such +information is available only when the file movement itself takes +place inside the repository. So, is there, at the moment of moving +files, when we need to syncronize parallel directories with their +unique parent directory structure. +

+
Warning

Warning

There is not support for URL reference inside +`centos-art.sh' script. The `centos-art.sh' script is +designed to work with local files inside the working copy only.

-

To produce final images, `centos-art.sh' applies one translation -file to one design template and produce a translated design template -instance. Later, `centos-art.sh' uses the translated template -instance to produce the translated image. Finally, when the translated -image has been produced, `centos-art.sh' removes the translated -design template instance. This production flow is repeated for each -translation file available in the translatio entry. -

-
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
--------------------------------------------------
-0 | Execute centos-art.sh on directory structure.
---v----------------------------------------------
-trunk/Translations/Identity/Path/To/Dir/file.sed
--------------------------------------------------
-1 | Apply translation to design template.
---v----------------------------------------------
-trunk/Identity/Path/To/Dir/Tpl/file.svg
--------------------------------------------------
-2 | Create design template instance.
---v----------------------------------------------
-/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
--------------------------------------------------
-3 | Render PNG image from template instance.
---v----------------------------------------------
-trunk/Identity/NewDir/Img/file.png
--------------------------------------------------
-4 | Remove design template instance.
-
- - -

2.68.1.3 Design template with translation (optimized)

- -

Producing translated images satisfies almost all our production images -needs, but there is still a pitfall in them. In order to produce -translated images as in the "one-to-one" configuration describes -previously, it is required that one translation file has one design -template. That's useful in many cases, but what would happen if we -need to apply many different translation files to the same design -template? Should we have to duplicate the same design template file -for each translation file, in order to satisfy the "one-to-one" -relation? What if we need to assign translation files to design -templates arbitrarily? -

-

Certenly, that's something the "one-to-one" configuration cannot -handle. So, that's why we had to "optimize" it. The optimized -configuration consists on using a matching list (MATCHINGLIST) -variable that specifies the relationship between translation files and -design templates in an arbitrary way. Using such matching list between -translation files and design templates let us use as many assignment -combinations as translation files and design templates we are working -with. -

-

The MATCHINGLIST variable is set in the pre-rendition -configuration script of the component we want to produce images for. -By default, the MATCHINGLIST variable is empty which means no -matching list is used. Otherwise, if MATCHINGLIST variable has a -value different to empty value then, `centos-art.sh' interprets -the matching list in order to know how translation files are applied -to design templates. -

-

For example, consider the following configuration: +

As CentOS Artwork Repository is built over a version control system, +file movements inside the repository are considered repository +changes. In order for these repository changes to be versioned, we +need to, firstly, add changes into the version control system, commit +them, and later, perform movement actions using version control system +commands. This configuration makes possible for everyone to know about +changes details inside the repository; and if needed, revert or update +them back to a previous revision.

-
-
One entry under `trunk/Identity/':
-
-

In this configuration we want to produce three images using a -paragraph-based style, controlled by `paragraph.svg' design -template; and one image using a list-based style, controlled by -`list.svg' design template. -

-
trunk/Identity/Path/To/Dir
-|-- Tpl
-|   |-- paragraph.svg
-|   `-- list.svg
-`-- Img
-    |-- 01-welcome.png
-    |-- 02-donate.png
-    |-- 03-docs.png
-    `-- 04-support.png
-
-
-
One entry under `trunk/Translations/':
-
-

In order to produce translated images we need to have one translation -file for each translated image we want to produce. Notice how -translation names do match final image file names, but how translation -names do not match design template names. When we use matching list -there is no need for translation files to match the names of design -templates, such name relation is set inside the matching list itself. -

-
trunk/Translations/Identity/Path/To/Dir
-|-- 01-welcome.sed
-|-- 02-donate.sed
-|-- 03-docs.sed
-`-- 04-support.sed
-
-
-
One entry under `trunk/trunk/Scripts/Bash/Functions/Render/Config/':
-
-

In order to produce different translated images using specific design -templates, we need to specify the relation between translation files -and design templates in a way that `centos-art.sh' could know -exactly what translation file to apply to what design template. This -relation between translation files and design templates is set using -the matching list MATCHINGLIST variable inside the pre-rendition -configuration script of the component we want to produce images for. -

-
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
-`-- render.conf.sh
-
-

In this configuration the pre-rendition configuration script -(`render.conf.sh') would look like the following: +

Finally, once all path information has been corrected, it is time to +take care of information inside the files. For instance, considere +what would happen if you make a reference to a documentation node, and +later the documentation node you refere to is deleted. That would make +Texinfo to produce error messages at export time. So, the +`centos-art.sh' script needs to know when such changes happen, in +a way they could be noted and handled without producing errors.

-
function render_loadConfig {
-
-    # Define rendition actions.
-    ACTIONS[0]='BASE:renderImage'
 
-    # Define matching list.
-    MATCHINGLIST="\
-    paragraph.svg:\
-        01-welcome.sed\
-        02-donate.sed\
-        04-support.sed
-    list.svg:\
-        03-docs.sed
-    "
-
-}
+
+
 2.68.2.6 What is the right place to store it? 

+
+
Occasionly, you may find that new corporate visual identity components
+need to be added to the repository. If that is your case, the first
+question you need to ask yourself, before start to create directories
+blindly all over, is: What is the right place to store it?
+

+
The CentOS Community different free support vains (see:
+http://wiki.centos.org/GettingHelp) are the best place to find
+answers to your question, but going there with hands empty is not good
+idea. It may give the impression you don't really care about. Instead,
+consider the following suggestions to find your own comprehension and
+so, make your propositions based on it.
+

+
When we are looking for the correct place to store new files, to bear
+in mind the corporate visual identity structure used inside the CentOS
+Artwork Repository (see section The `trunk/Identity' Directory) would be probaly the best
+advice we could offer, the rest is just matter of choosing appropriate
+names.  To illustrate this desition process let's consider the
+`trunk/Identity/Themes/Motifs/TreeFlower' directory as example.
+It is the trunk development line of TreeFlower artistic motif.
+Artistic motifs are considered part of themes, which in turn are
+considered part of CentOS corporate visual identity.
+

+
When building parent directory structures, you may find that reaching
+an acceptable location may take some time, and as it uses to happen
+most of time; once you've find it, that may be not a definite
+solution.  There are many concepts that you need to play with, in
+order to find a result that match the conceptual idea you try to
+implement in the new directory location. To know which these concepts
+are, split the location in words and read its documentation entry from
+less specific to more specific.
+

+
For example, the `trunk/Identity/Themes/Motifs/TreeFlower'
+location evolved through several months of contant work and there is
+no certain it won't change in the future, even it fixes quite well the
+concept we are trying to implement.  The concepts used in
+`trunk/Identity/Themes/Distro/Motifs/TreeFlower' location are
+described in the following commands, respectively:
+

+
centos-art manual --read=turnk/
+centos-art manual --read=turnk/Identity/
+centos-art manual --read=turnk/Identity/Themes/
+centos-art manual --read=turnk/Identity/Themes/Motifs/
+centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/
 

-
As result, `centos-art.sh' will produce `01-welcome.png',
-`02-donate.png' and `04-support.png' using the
-paragraph-based design template, but `03-docs.png' using the
-list-based design template.
-
-
+

Other location concepts can be found similary as we did above, just +change the location we used above by the one you are trying to know +concepts for. +

+ +

2.68.3 Usage

- -

2.68.1.4 Design template with translation (optimized+flexibility)

- -

In the production models we've seen so far, there are design templates -to produce untranslated images and translation files which combiend -with design templates produce translated images. That may seems like -all our needs are covered, doesn't it? Well, it almost does. -

-

Generally, we use design templates to define how final images will -look like. Generally, each renderable directory structure has one -`Tpl/' directory where we organize design templates for that -identity component. So, we can say that there is only one unique -design template definition for each identity component; or what is the -same, said differently, identity components can be produced in one way -only, the way its own design template directory specifies. This is -not enough for theme production. It is a limitation, indeed. -

-

Initially, to create one theme, we created one renderable directory -structure for each theme component. When we found ourselves with many -themes, and components inside them, it was obvious that the same -design model was duplicated inside each theme. As design models were -independently one another, if we changed one theme's design model, -that change was useless to other themes. So, in order to reuse design -model changes, we unified design models into one common directory -structure. -

-

With design models unified in a common structure, another problem rose -up. As design models also had the visual style of theme components, -there was no difference between themes, so there was no apparent need -to have an independent theme directory structure for each different -theme. So, it was also needed to separate visual styles from design -models. -

-

At this point there are two independent worklines: one directory -structure to store design models (the final image characteristics -[i.e., dimensions, translation markers, etc.]) and one directory -structure to store visual styles (the final image visual style [i.e., -the image look and feel]). So, it is possible to handle both -different design models and different visual styles independtly one -another and later create combinations among them using -`centos-art.sh'. -

-

For example, consider the following configuration: -

-
One entry under `trunk/Identity/Themes/Models/':
+
centos-art path --copy='SRC' --to='DST'
-

The design model entry exists to organize design model files (similar -to design templates). Both design models and design templates are very -similar; they both should have the CENTOSARTWORK export id -present to identify the exportation area, translation marks, etc. -However, design models do use dynamic backgrounds inclusion while -design templates don't. -

-
                        THEMEMODEL | | The bond component
-                             |<----| |--------------------->|
-trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
-|-- paragraph.svg
-`-- list.svg
-
-

Inisde design models, dynamic backgrounds are required in order for -different artistic motifs to reuse common design models. Firstly, in -order to create dynamic backgrounds inside design models, we import a -bitmap to cover design model's background and later, update design -model's path information to replace fixed values to dynamic values. +

Copy `SRC' to `DST' and schedule `DST' for +addition (with history). In this command, `SRC' and `DST' +are both working copy (WC) entries.

-
One entry under `trunk/Identity/Themes/Motifs/':
-
-

The artistic motif entry defines the visual style we want to produce -images for, only. Final images (i.e., those built from combining both -design models and artistic motif backrounds) are not stored here, but -under branches directory structure. In the artistic motif entry, we -only define those images that cannot be produced automatically by -`centos-art.sh' (e.g., Backgrounds, Color information, -Screenshots, etc.). -

-
                  Artistic motif name | | Artistic motif backgrounds
-                             |<-------| |-------->|
-trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
-|-- Img
-|   |-- Png
-|   |   |-- 510x300.png
-|   |   `-- 510x300-final.png
-|   `-- Jpg
-|       |-- 510x300.jpg
-|       `-- 510x300-final.jpg
-|-- Tpl
-|   `-- 510x300.svg
-`-- Xcf
-    `-- 510x300.xcf
-
-
-
One entry under `trunk/Translations/':
-
-

The translation entry specifies, by means of translation files, the -language-specific information we want to produce image for. When we -create the translation entry we don't use the name of neither design -model nor artistic motif, just the design model component we want to -produce images for. -

-
                                   | The bond component
-                                   |--------------------->|
-trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
-`-- 5
-    |-- en
-    |   |-- 01-welcome.sed
-    |   |-- 02-donate.sed
-    |   `-- 03-docs.sed
-    `-- es
-        |-- 01-welcome.sed
-        |-- 02-donate.sed
-        `-- 03-docs.sed
-
-
-
One entry under `trunk/Scripts/Bash/Functions/Render/Config/':
+
centos-art path --delete='SRC'
-

There is one pre-rendition configuration script for each theme -component. So, each time a theme component is rendered, its -pre-rendition configuration script is evaluated to teach -`centos-art.sh' how to render the component. +

Delete `DST'. In order for this command to work the file or +directory you intend to delete should be under version control first. +In this command, `SRC' is a working copy (WC) entry.

-
trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
-`-- render.conf.sh
-
-

In this configuration the pre-rendition configuration script -(`render.conf.sh') would look like the following: -

-
function render_loadConfig {
-
-    # Define rendition actions.
-    ACTIONS[0]='BASE:renderImage'
-
-    # Define matching list.
-    MATCHINGLIST="\
-    paragraph.svg:\
-        01-welcome.sed\
-        02-donate.sed
-    list.svg:\
-        03-docs.sed
-        "
-
-    # Deifne theme model.
-    THEMEMODEL='Default'
-
-}
-
+
-

The production flow of "optimize+flexibility" configuration… -

- -

2.68.2 Renderable translation directory structures

- -

Translation directory structures are auxiliar structures of renderable -identity directory structures. There is one translation directory -structure for each renderable identity directory structure. Inside -translation directory structures we organize translation files used by -renderable identity directory structures that produce translated -images. Renderable identity directory structures that produce -untranslated images don't use translation files, but they do use a -translation directory structure, an empty translation directory -structure, to be precise. -

-

In order to aliviate production of translation file, we made -translation directory structures renderable adding a template -(`Tpl/') directory structure to handle common content inside -translation files. This way, we work on translation templates and -later use `centos-art.sh' to produce specific translation files -(based on translation templates) for different information (e.g., -languages, release numbers, architectures, etc.). -

-

If for some reason, translation files get far from translation -templates and translation templates become incovenient to produce such -translation files then, care should be taken to avoid replacing the -content of translation files with the content of translation templates -when `centos-art.sh' is executed to produce translation files -from translation templates. -

-

Inside renderable translation directory structures, -`centos-art.sh' can produce text-based files only. -

- - -

2.68.3 Copying renderable directory structures

- -

A renderable layout is formed by design models, design images, -pre-rendition configuration scripts and translations files. This way, -when we say to duplicate rendition stuff we are saying to duplicate -these four directory structures (i.e., design models, design images, -pre-rendition configuration scripts, and related translations files). -

-

When we duplicate directories, inside `trunk/Identity' directory -structure, we need to be aware of renderable layout described above -and the source location used to perform the duplication action. The -source location is relevant to centos-art.sh script in order to -determine the required auxiliar information inside directory -structures that need to be copied too (otherwise we may end up with -orphan directory structures unable to be rendered, due the absence of -required information). -

-

In order for a renderable directory structure to be valid, the new -directory structure copied should match the following conditions: -

-
    -
  1. To have a unique directory structure under -`trunk/Identity', organized by any one of the above -organizational designs above. - -
  2. To have a unique directory structure under -`trunk/Translations' to store translation files. - -
  3. To have a unique directory structure under -`trunk/Scripts/Bash/Functions/Render/Config' to set pre-rendition -configuration script. -
- -

As convenction, the render_doCopy function uses -`trunk/Identity' directory structure as source location. Once -the `trunk/Identity' directory structure has been specified and -verified, the related path information is built from it and copied -automatically to the new location specified by FLAG_TO variable. -

-

Design templates + No translation: -

-

Command: -- centos-art render -copy=trunk/Identity/Path/To/Dir -to=trunk/Identity/NewPath/To/Dir -

-

Sources: -- trunk/Identity/Path/To/Dir -- trunk/Translations/Identity/Path/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir -

-

Targets: -- trunk/Identity/NewPath/To/Dir -- trunk/Translations/Identity/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir -

-

Renderable layout 2: -

-

Command: -- centos-art render -copy=trunk/Identity/Themes/Motifs/TreeFlower \ - -to=trunk/Identity/Themes/Motifs/NewPath/To/Dir -

-

Sources: -- trunk/Identity/Themes/Motifs/TreeFlower -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/TreeFlower -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower -

-

Targets: -- trunk/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Translations/Identity/Themes -- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes -- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir -

-

Notice that design models are not included in source or target -locations. This is intentional. In "Renderable layout 2", design -models live by their own, they just exist, they are there, available -for any artistic motif to use. By default `Themes/Models/Default' -design model directory structure is used, but other design models -directory structures (under Themes/Models/) can be created and used -changing the value of THEMEMODEL variable inside the pre-rendition -configuration script of the artistic motif source location you want to -produce. -

-

Notice how translations and pre-rendition configuration scripts may -both be equal in source and target. This is because such structures -are common to all artistic motifs (the default values to use when no -specific values are provided). -

-

- The common directory structures are not copied or deleted. We cannot - copy a directory structure to itself. -

-

- The common directory structures represent the default value to use - when no specific translations and/or pre-rendition configuration - script are provided inside source location. -

-

- The specific directory structures, if present, are both copiable and - removable. This is, when you perform a copy or delete action from - source, that source specific auxiliar directories are transfered in - the copy action to a new location (that specified by FLAG_TO - variable). -

-

- When translations and/or pre-rendition configuration scripts are - found inside the source directory structure, the centos-art.sh - script loads common auxiliar directories first and later specific - auxiliar directories. This way, identity rendition of source - locations can be customized idividually over the base of common - default values. -

-

- The specific auxiliar directories are optional. -

-

- The common auxiliar directories should be present always. This is, - in order to provide the information required by render functionality - (i.e., to make it functional in the more basic level of its - existence). -

-

Notice how the duplication process is done from `trunk/Identity' on, -not the oposite. If you try to duplicate a translation structure (or -similar auxiliar directory structures like pre-rendition configuration -scripts), the `trunk/Identity' for that translation is not created. -This limitation is impossed by the fact that many `trunk/Identity' -directory structures may reuse/share the same translation directory -structure. We cannot delete one translation (or similar) directory -structures while a related `trunk/Identity/' directory structure is -still in need of it. -

-

The `render_doCopy' functionality does duplicate directory structures -directly involved in rendition process only. Once such directories -have been duplicated, the functionality stops thereat. -

- -

2.68.4 Usage

- - - - - -

2.68.5 See also

+ +

2.68.4 See also

+ + +
2.61 The `trunk/Scripts/Bash' Directory   +
- - + + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]

- This document was generated on March, 6 2011 using texi2html 1.76. + This document was generated on March, 8 2011 using texi2html 1.76.
diff --git a/Manual/repository-html/repository_73.html b/Manual/repository-html/repository_73.html index 7b95bb9..cf68082 100644 --- a/Manual/repository-html/repository_73.html +++ b/Manual/repository-html/repository_73.html @@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. --> - + -CentOS Artwork Repository: 2.69 The trunk/Scripts/Bash/Cli/Functions/Render/Config Directory +CentOS Artwork Repository: 2.69 The trunk/Scripts/Bash/Cli/Functions/Render Directory - - + + @@ -55,233 +55,767 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.69 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory

- - + -

2.69.1 Goals

+

2.69 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory

-

The `trunk/Scripts/Bash/Config' directory exists to oraganize -pre-rendering configuration scripts. +

The render functionality exists to produce both identity and +translation files on different levels of information (i.e., different +languages, release numbers, architectures, etc.). +

+

The render functionality relies on "renderable directory +structures" to produce files. Renderable directory structures can be +either "identity directory structures" or "translation directory +structures" with special directories inside.

-

2.69.2 Description

+

2.69.1 Renderable identity directory structures

-

Pre-rendering configuration scripts let you customize the way -centos-art.sh script renders identity and translation -repository entries. Pre-rendering configuration scripts are -`render.conf.sh' files with render_loadConfig function -definition inside. +

Renderable identity directory structures are the starting point of +identity rendition. Whenever we want to render a component of CentOS +corporate visual identity, we need to point `centos-art.sh' to a +renderable identity directory structure. If such renderable identity +directory structure doesn't exist, then it is good time to create it. +

+

Inside the working copy, one renderable identity directory structures +represents one visual manifestation of CentOS corporate visual +identity, or said differently, each visual manifestation of CentOS +corporate visual identity should have one renderable identity +directory structure.

-

There is one `render.conf.sh' file for each pre-rendering -configuration entry. Pre-rendering configuration entries can be based -both on identity and translation repository entires. Pre-rendering -configuration entries are required for each identity entry, but not -for translation entries. +

Inside renderable identity directory structures, `centos-art.sh' +can render both image-based and text-based files. Specification of +whether a renderable identity directory structure produces image-based +or text-based content is a configuration action that takes place in +the pre-rendition configuration script of that renderable identity +directory structure. +

+

Inside renderable identity directory structures, content production is +organized in different configurations. A content production +configuration is a unique combination of the components that make an +identity directory structure renderable. One content production +configuration does one thing only (e.g., to produce untranslated +images), but it can be extended (e.g., adding translation files) to +achieve different needs (e.g., to produce translated images).

-

2.69.2.1 The `render.conf.sh' identity model

- -

Inside CentOS Artwork Repository, we consider identity entries to all -directories under `trunk/Identity' directory. Identity entries can be -image-based or text-based. When you render image-based identity -entries you need to use image-based pre-rendering configuration -scripts. Likewise, when you render text-based identity entries you -need to use text-based pre-rendering configuration scripts. +

2.69.1.1 Design template without translation

+ +

The design template without translation configuration is based on a +renderable identity directory structure with an empty translation +directory structure. In this configuration, one design template +produces one untranslated file. Both design templates and final +untranslated files share the same file name, but they differ one +another in file-type and file-extension. +

+

For example, to produce images without translations (there is no much +use in producing text-based files without translations), consider the +following configuration: +

+
+
One renderable identity directory structure:
+
+

In this example we used `Identity/Path/To/Dir' as the identity +component we want to produce untranslated images for. Identity +components can be either under `trunk/' or `branches/' +directory structure. +

+

The identity component (i.e., `Identity/Path/To/Dir', in this +case) is also the bond component we use to connect the identity +directory structures with their respective auxiliar directories (i.e., +translation directory structres and pre-rendition configuration +structures). The bond component is the path convenction that +`centos-art.sh' uses to know where to look for related +translations, configuration scripts and whatever auxiliar thing a +renderable directory structure may need to have. +

+
      | The bond component
+      |----------------->|
+trunk/Identity/Path/To/Dir  <-- Renderable identity directory structure.
+|-- Tpl                     <-- Design template directory.
+|   `-- file.svg            <-- Design template file.
+`-- Img                     <-- Directory used to store final files.
+    `-- file.png            <-- Final image-based file produced from
+                                design template file.
+
+

Inside design template directory, design template files are based on +SVG (Scalable Vector Graphics) and use the extension +.svg. Design template files can be organized using several +directory levels to create a simple but extensible configuration, +specially if translated images are not required. +

+

In order for SVG (Scalable Vector Graphics) files to be +considered "design template" files, they should be placed under the +design template directory and to have set a CENTOSARTWORK +object id inside.

-

Inside identity pre-rendering configuration scripts, image-based -pre-rendering configuration scripts look like the following: +

The CENTOSARTWORK word itself is a convenction name we use to +define which object/design area, inside a design template, the +`centos-art.sh' script will use to export as +PNG (Portable Network Graphic) image at rendition time. +Whithout such object id specification, the `centos-art.sh' script +cannot know what object/design area you (as designer) want to export +as PNG (Portable Network Graphic) image file.

-
#!/bin/bash
+
info
Note
 At rendition time, the content of `Img/' directory
+structure is produced by `centos-art.sh' automatically.
+

 
-function render_loadConfig {
+
When a renderable identity directory structure is configured to
+produce image-based content, `centos-art.sh' produces
+PNG (Portable Network Graphics) files with the .png
+extension. Once the base image format has been produced, it is
+possible for `centos-art.sh' to use it in order to automatically
+create other image formats that may be needed (-- Removed(pxref:trunk Scripts
+Bash Functions Render Config) --).
+

+
Inside the working copy, you can find an example of "design template
+without translation" configuration at `trunk/Identity/Models/'.
+

+
See section The `trunk/Identity' Directory, for more information.
+

+
+
One translation directory structure:
+
+

In order for an identity entry to be considered an identity renderable +directory structure, it should have a translation entry. The content +of the translation entry is relevant to determine how to process the +identity renderable directory entry. +

+

If the translation entry is empty (i.e., there is no file inside it), +`centos-art.sh' interprets the identity renderable directory +structure as a "design templates without translation" configuration. +

+
                   | The bond component
+                   |----------------->|
+trunk/Translations/Identity/Path/To/Dir
+`-- (empty)
+
+

If the translation entry is not empty, `centos-art.sh' can +interpret the identity renderable directory structure as one of the +following configurations: "design template with translation +(one-to-one)" or "design template with translation (optimized)". +Which one of these configurations is used depends on the value +assigned to the matching list (MATCHINGLIST) variable in the +pre-rendition configuration script of the renderable identity +directory structure we are producing images for. +

+

If the matching list variable is empty (as it is by default), then +"design template with translation (one-to-one)" configuration is +used. In this configuration it is required that both design templates +and translation files have the same file names. This way, one +translation files is applied to one design template, to produce +one translated image. +

+

If the matching list variable is not empty (because you redefine it in +the pre-rendition configuration script), then "design template with +translation (optimized)" configuration is used instead. In this +configuration, design templates and translation files don't need to +have the same names since such name relationship between them is +specified in the matching list properly. +

+

-- Removed(xref:trunk Translations) --, for more information. +

+
+
One pre-rendition configuration script:
+
+

In order to make an identity directory structure renderable, a +pre-rendition configuration script should exist for it. The +pre-rendition configuration script specifies what type of rendition +does `centos-art.sh' will perform over the identity directory +structure and how does it do that. +

+
                                           | The bond component
+                                           |----------------->|
+trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
+
+

In this configuration the pre-rendition configuration script +(`render.conf.sh') would look like the following: +

+
function render_loadConfig {
 
-    # Define rendering actions.
+    # Define rendition actions.
     ACTIONS[0]='BASE:renderImage'
-    ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
 
 }
-

Inside identity pre-rendering configuration scripts, text-based -pre-rendering configuration scripts look like the following: +

Since translation directory structure is empty, `centos-art.sh' +assumes a "design template without translation" configuration to +produce untranslated images.

-
#!/bin/bash
-
-function render_loadConfig {
-
-    # Define rendering actions.
-    ACTIONS[0]='BASE:renderText'
-    ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
-
-}
+
To produce untranslated images, `centos-art.sh' takes one design
+template and creates one temporal instance from it.  Later,
+`centos-art.sh' uses the temporal design template instance as
+source file to export the final untranslated image. The action of
+exporting images from SVG (Scalable Vector Graphics) to
+PNG (Portable Network Graphics) is possible thanks to
+Inkscape's command-line interface and the CENTOSARTWORK object
+id we previously set inside design templates.
+

+
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
+-------------------------------------------------
+0 | Execute centos-art.sh on renderable identity directory structure.
+--v----------------------------------------------
+trunk/Identity/Path/To/Dir/Tpl/file.svg
+-------------------------------------------------
+1 | Create instance from design template.
+--v----------------------------------------------
+/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
+-------------------------------------------------
+2 | Render untranslated image from design template instance.
+--v----------------------------------------------
+trunk/Identity/NewDir/Img/file.png
+-------------------------------------------------
+3 | Remove design template instance.
 

-
When using identity pre-rendering configuration scripts, you can
-extend both image-based and text-based pre-rendering configuration
-scripts using image-based and text-based post-rendering actions,
-respectively. 
+
Finally, when the untranslated image has been created, the temporal
+design template instance is removed. At this point,
+`centos-art.sh' takes the next design template and repeats the
+whole production flow once again (design template by design template),
+until all design templates be processed.
 

+
-- Removed(xref:trunk Scripts Bash Functions Render Config) --, for more
+information.
+
+
+ -

2.69.2.2 The `render.conf.sh' translation model

+

2.69.1.2 Design template with translation (one-to-one)

+ +

Producing untranslated images is fine in many cases, but not always. +Sometimes it is required to produce images in different languages and +that is something that untrasnlated image production cannot achieve. +However, if we fill its empty translation entry with translation files +(one for each design template) we extend the production flow from +untranslated image production to translated image production. +

+

In order for `centos-art.sh' to produce images correctly, each +design template should have one translation file and each translation +file should have one design template. Otherwise, if there is a +missing design template or a missing translation file, +`centos-art.sh' will not produce the final image related to the +missing component. +

+

In order for `centos-art.sh' to know which is the relation +between translation files and design templates the translation +directory structure is taken as reference. For example, the +`trunk/Translations/Identity/Path/To/Dir/file.sed' translation +file does match `trunk/Identity/Path/To/Dir/Tpl/file.svg' design +template, but it doesn't match +`trunk/Identity/Path/To/Dir/File.svg' or +`trunk/Identity/Path/To/Dir/Tpl/File.svg' or +`trunk/Identity/Path/To/Dir/Tpl/SubDir/file.svg' design +templates. +

+

The pre-rendition configuration script used to produce untranslated +images is the same we use to produce translated images. There is no +need to modify it. So, as we are using the same pre-rendition +configuration script, we can say that translated image production is +somehow an extended/improved version of untranslated image production. +

+
info

Note

If we use no translation file in the translation entry +(i.e., an empty directory), `centos-art.sh' assumes the +untranslated image production. If we fill the translation entry with +translation files, `centos-art.sh' assumes the translated image +production. +

-

Translation pre-rendering configuration scripts take precedence before -default translation rendering action. Translation pre-rendering -actions are useful when default translation rendering action do not -fit itself to translation entry rendering requirements. +

To produce final images, `centos-art.sh' applies one translation +file to one design template and produce a translated design template +instance. Later, `centos-art.sh' uses the translated template +instance to produce the translated image. Finally, when the translated +image has been produced, `centos-art.sh' removes the translated +design template instance. This production flow is repeated for each +translation file available in the translatio entry.

+
centos-art.sh render --identity=trunk/Identity/Path/To/Dir
+-------------------------------------------------
+0 | Execute centos-art.sh on directory structure.
+--v----------------------------------------------
+trunk/Translations/Identity/Path/To/Dir/file.sed
+-------------------------------------------------
+1 | Apply translation to design template.
+--v----------------------------------------------
+trunk/Identity/Path/To/Dir/Tpl/file.svg
+-------------------------------------------------
+2 | Create design template instance.
+--v----------------------------------------------
+/tmp/centos-art.sh-a07e824a-5953-4c21-90ae-f5e8e9781f5f-file.svg
+-------------------------------------------------
+3 | Render PNG image from template instance.
+--v----------------------------------------------
+trunk/Identity/NewDir/Img/file.png
+-------------------------------------------------
+4 | Remove design template instance.
+
-

2.69.2.3 The `render.conf.sh' rendering actions

- -

Inside both image-based and text-based identity pre-rendering -configuration scripts, we use the `ACTIONS' array variable to -define the way centos-art.sh script performs identity -rendering. Identity rendering is organized by one `BASE' action, -and optional `POST' and `LAST' rendering actions. -

-

The `BASE' action specifies what kind of rendering does the -centos-art.sh script will perform with the files related to -the pre-rendering configuration script. The `BASE' action is -required. Possible values to `BASE' action are either -`renderImage' or `renderText' only. -

-

To specify the `BASE' action you need to set the `BASE:' -string followed by one of the possible values. For example, if you -want to render images, consider the following definition of -`BASE' action: -

-
ACTIONS[0]='BASE:renderImage'
+
 2.69.1.3 Design template with translation (optimized) 

+
+
Producing translated images satisfies almost all our production images
+needs, but there is still a pitfall in them. In order to produce
+translated images as in the "one-to-one" configuration describes
+previously, it is required that one translation file has one design
+template. That's useful in many cases, but what would happen if we
+need to apply many different translation files to the same design
+template?  Should we have to duplicate the same design template file
+for each translation file, in order to satisfy the "one-to-one"
+relation? What if we need to assign translation files to design
+templates arbitrarily?
+

+
Certenly, that's something the "one-to-one" configuration cannot
+handle.  So, that's why we had to "optimize" it. The optimized
+configuration consists on using a matching list (MATCHINGLIST)
+variable that specifies the relationship between translation files and
+design templates in an arbitrary way. Using such matching list between
+translation files and design templates let us use as many assignment
+combinations as translation files and design templates we are working
+with.
+

+
The MATCHINGLIST variable is set in the pre-rendition
+configuration script of the component we want to produce images for.
+By default, the MATCHINGLIST variable is empty which means no
+matching list is used. Otherwise, if MATCHINGLIST variable has a
+value different to empty value then, `centos-art.sh' interprets
+the matching list in order to know how translation files are applied
+to design templates.
+

+
For example, consider the following configuration:
+

+

+
 One entry under `trunk/Identity/':

+

+
In this configuration we want to produce three images using a
+paragraph-based style, controlled by `paragraph.svg' design
+template; and one image using a list-based style, controlled by
+`list.svg' design template.
+

+
trunk/Identity/Path/To/Dir
+|-- Tpl
+|   |-- paragraph.svg
+|   `-- list.svg
+`-- Img
+    |-- 01-welcome.png
+    |-- 02-donate.png
+    |-- 03-docs.png
+    `-- 04-support.png
 

-
Only one `BASE' action must be specified. If more than one
-`BASE' action is specified, the last one is used. If no
-`BASE' action is specified at all, an error is triggered and the
-centos-art.sh script ends its execution.
-

-
The `POST' action specifies which action to apply for
-each file rendered (at the rendering time). This action is optional.
-You can set many different `POST' actions to apply many different
-actions over the same already rendered file. Possible values to
-`POST' action are `renderFormats', `renderSyslinux',
-`renderGrub', etc. 
-

-
To specify the `POST' action, you need to use set the
-`POST:' followed by the function name of the action you want to
-perform.  The exact form depends on your needs. For example, consider
-the following example to produce `xpm', `jpg', and
-`tif' images, based on already rendered `png' image, and
-also organize the produced files in directories named as their own
-extensions:
-

-
ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
+

+
 One entry under `trunk/Translations/':

+

+
In order to produce translated images we need to have one translation
+file for each translated image we want to produce. Notice how
+translation names do match final image file names, but how translation
+names do not match design template names. When we use matching list
+there is no need for translation files to match the names of design
+templates, such name relation is set inside the matching list itself.
+

+
trunk/Translations/Identity/Path/To/Dir
+|-- 01-welcome.sed
+|-- 02-donate.sed
+|-- 03-docs.sed
+`-- 04-support.sed
 

-
In the previous example, file organization takes place at the moment
-of rendering, just after producing the `png' base file and before
-going to the next file in the list of files to render. If you don't
-want to organized the produced files in directories named as their own
-extensions, just remove the `POST:groupByFormat' action line:
-

-
ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+

+
 One entry under `trunk/trunk/Scripts/Bash/Functions/Render/Config/':

+

+
In order to produce different translated images using specific design
+templates, we need to specify the relation between translation files
+and design templates in a way that `centos-art.sh' could know
+exactly what translation file to apply to what design template. This
+relation between translation files and design templates is set using
+the matching list MATCHINGLIST variable inside the pre-rendition
+configuration script of the component we want to produce images for.  
+

+
trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+`-- render.conf.sh
 

-
The `LAST' action specifies which actions to apply once the last
-file in the list of files to process has been rendered. The
-`LAST' action is optional. Possible values for `LAST'
-actions may be `groupByFormat', `renderGdmTgz', etc.
-

-
info
Note
 -- Removed(xref:trunk Scripts Bash Functions Render) --, to know more
-about possible values for `BASE', `POST' and `LAST'
-action definitions.
-

-
-
To specify the `LAST' action, you need to set the `LAST:'
-string followed by the function name of the action you want to
-perform.  For example, consider the following example if you want to
-render all files first and organize them later:
+
In this configuration the pre-rendition configuration script
+(`render.conf.sh') would look like the following:
 

-
ACTIONS[0]='BASE:renderImage'
-ACTIONS[1]='POST:renderFormats: xpm jpg tif'
-ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
+
function render_loadConfig {
+
+    # Define rendition actions.
+    ACTIONS[0]='BASE:renderImage'
+
+    # Define matching list.
+    MATCHINGLIST="\
+    paragraph.svg:\
+        01-welcome.sed\
+        02-donate.sed\
+        04-support.sed
+    list.svg:\
+        03-docs.sed
+    "
+
+}
 

+
As result, `centos-art.sh' will produce `01-welcome.png',
+`02-donate.png' and `04-support.png' using the
+paragraph-based design template, but `03-docs.png' using the
+list-based design template.
+

+

+
 
 
-
 2.69.3 Usage 

+
 2.69.1.4 Design template with translation (optimized+flexibility) 

 
-
Use the following commands to administer both identity and translation
-pre-rendering configuration scripts:
+
In the production models we've seen so far, there are design templates
+to produce untranslated images and translation files which combiend
+with design templates produce translated images. That may seems like
+all our needs are covered, doesn't it? Well, it almost does.
+

+
Generally, we use design templates to define how final images will
+look like. Generally, each renderable directory structure has one
+`Tpl/' directory where we organize design templates for that
+identity component. So, we can say that there is only one unique
+design template definition for each identity component; or what is the
+same, said differently, identity components can be produced in one way
+only, the way its own design template directory specifies.  This is
+not enough for theme production. It is a limitation, indeed.
+

+
Initially, to create one theme, we created one renderable directory
+structure for each theme component. When we found ourselves with many
+themes, and components inside them, it was obvious that the same
+design model was duplicated inside each theme. As design models were
+independently one another, if we changed one theme's design model,
+that change was useless to other themes. So, in order to reuse design
+model changes, we unified design models into one common directory
+structure.
+

+
With design models unified in a common structure, another problem rose
+up. As design models also had the visual style of theme components,
+there was no difference between themes, so there was no apparent need
+to have an independent theme directory structure for each different
+theme.  So, it was also needed to separate visual styles from design
+models.
+

+
At this point there are two independent worklines: one directory
+structure to store design models (the final image characteristics
+[i.e., dimensions, translation markers, etc.]) and one directory
+structure to store visual styles (the final image visual style [i.e.,
+the image look and feel]).  So, it is possible to handle both
+different design models and different visual styles independtly one
+another and later create combinations among them using
+`centos-art.sh'. 
+

+
For example, consider the following configuration:
 

 

-
 `centos-art config --create='path/to/dir/''

+
 One entry under `trunk/Identity/Themes/Models/':

 

-
Use this command to create `path/to/dir' related pre-rendering
-configuration script.
+
The design model entry exists to organize design model files (similar
+to design templates). Both design models and design templates are very
+similar; they both should have the CENTOSARTWORK export id
+present to identify the exportation area, translation marks, etc.
+However, design models do use dynamic backgrounds inclusion while
+design templates don't.
+

+
                        THEMEMODEL | | The bond component
+                             |<----| |--------------------->|
+trunk/Identity/Themes/Models/Default/Distro/Anaconda/Progress/
+|-- paragraph.svg
+`-- list.svg
+

+
Inisde design models, dynamic backgrounds are required in order for
+different artistic motifs to reuse common design models. Firstly, in
+order to create dynamic backgrounds inside design models, we import a
+bitmap to cover design model's background and later, update design
+model's path information to replace fixed values to dynamic values.
 

 

-
 `centos-art config --edit='path/to/dir/''

+
 One entry under `trunk/Identity/Themes/Motifs/':

 

-
Use this command to edit `path/to/dir' related pre-rendering
-configuration script.  
+
The artistic motif entry defines the visual style we want to produce
+images for, only. Final images (i.e., those built from combining both
+design models and artistic motif backrounds) are not stored here, but
+under branches directory structure. In the artistic motif entry, we
+only define those images that cannot be produced automatically by
+`centos-art.sh' (e.g., Backgrounds, Color information,
+Screenshots, etc.).
 

+
                  Artistic motif name | | Artistic motif backgrounds
+                             |<-------| |-------->|
+trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds/
+|-- Img
+|   |-- Png
+|   |   |-- 510x300.png
+|   |   `-- 510x300-final.png
+|   `-- Jpg
+|       |-- 510x300.jpg
+|       `-- 510x300-final.jpg
+|-- Tpl
+|   `-- 510x300.svg
+`-- Xcf
+    `-- 510x300.xcf
+

 

-
 `centos-art config --read='path/to/dir/''

+
 One entry under `trunk/Translations/':

 

-
Use this command to read `path/to/dir' related pre-rendering
-configuration script.  
+
The translation entry specifies, by means of translation files, the
+language-specific information we want to produce image for. When we
+create the translation entry we don't use the name of neither design
+model nor artistic motif, just the design model component we want to
+produce images for.
 

+
                                   | The bond component
+                                   |--------------------->|
+trunk/Translations/Identity/Themes/Distro/Anaconda/Progress/
+`-- 5
+    |-- en
+    |   |-- 01-welcome.sed
+    |   |-- 02-donate.sed
+    |   `-- 03-docs.sed
+    `-- es
+        |-- 01-welcome.sed
+        |-- 02-donate.sed
+        `-- 03-docs.sed
+

 

-
 `centos-art config --remove='path/to/dir/''

+
 One entry under `trunk/Scripts/Bash/Functions/Render/Config/':

 

-
Use this command to remove `path/to/dir' related pre-rendering
-configuration script.
+
There is one pre-rendition configuration script for each theme
+component. So, each time a theme component is rendered, its
+pre-rendition configuration script is evaluated to teach
+`centos-art.sh' how to render the component.
 

-

+
trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Distro/Anaconda/Progress/
+`-- render.conf.sh
+

+
In this configuration the pre-rendition configuration script
+(`render.conf.sh') would look like the following:
+

+
function render_loadConfig {
+
+    # Define rendition actions.
+    ACTIONS[0]='BASE:renderImage'
+
+    # Define matching list.
+    MATCHINGLIST="\
+    paragraph.svg:\
+        01-welcome.sed\
+        02-donate.sed
+    list.svg:\
+        03-docs.sed
+        "
+
+    # Deifne theme model.
+    THEMEMODEL='Default'
+
+}
+

 

 
-
In the commands above, `path/to/dir' refers to one renderable
-directory path under `trunk/Identity' or
-`trunk/Translations' structures only. 
+
The production flow of "optimize+flexibility" configuration…
 

-
 
-
 2.69.4 See also 

+
 2.69.2 Renderable translation directory structures 

+
+
Translation directory structures are auxiliar structures of renderable
+identity directory structures. There is one translation directory
+structure for each renderable identity directory structure.  Inside
+translation directory structures we organize translation files used by
+renderable identity directory structures that produce translated
+images. Renderable identity directory structures that produce
+untranslated images don't use translation files, but they do use a
+translation directory structure, an empty translation directory
+structure, to be precise.
+

+
In order to aliviate production of translation file, we made
+translation directory structures renderable adding a template
+(`Tpl/') directory structure to handle common content inside
+translation files.  This way, we work on translation templates and
+later use `centos-art.sh' to produce specific translation files
+(based on translation templates) for different information (e.g.,
+languages, release numbers, architectures, etc.).  
+

+
If for some reason, translation files get far from translation
+templates and translation templates become incovenient to produce such
+translation files then, care should be taken to avoid replacing the
+content of translation files with the content of translation templates
+when `centos-art.sh' is executed to produce translation files
+from translation templates.
+

+
Inside renderable translation directory structures,
+`centos-art.sh' can produce text-based files only.
+

+
+
+
 2.69.3 Copying renderable directory structures 

+
+
A renderable layout is formed by design models, design images,
+pre-rendition configuration scripts and translations files. This way,
+when we say to duplicate rendition stuff we are saying to duplicate
+these four directory structures (i.e., design models, design images,
+pre-rendition configuration scripts, and related translations files).
+

+
When we duplicate directories, inside `trunk/Identity' directory
+structure, we need to be aware of renderable layout described above
+and the source location used to perform the duplication action.  The
+source location is relevant to centos-art.sh script in order to
+determine the required auxiliar information inside directory
+structures that need to be copied too (otherwise we may end up with
+orphan directory structures unable to be rendered, due the absence of
+required information).
+

+
In order for a renderable directory structure to be valid, the new
+directory structure copied should match the following conditions:
+

+
    
+
  1.  To have a unique directory structure under
+`trunk/Identity', organized by any one of the above
+organizational designs above.
+
+
  2.  To have a unique directory structure under
+`trunk/Translations' to store translation files.
+
+
  3.  To have a unique directory structure under
+`trunk/Scripts/Bash/Functions/Render/Config' to set pre-rendition
+configuration script.
+

+
+
As convenction, the render_doCopy function uses
+`trunk/Identity' directory structure as source location.  Once
+the `trunk/Identity' directory structure has been specified and
+verified, the related path information is built from it and copied
+automatically to the new location specified by FLAG_TO variable.
+

+
Design templates + No translation:
+

+
Command:
+- centos-art render -copy=trunk/Identity/Path/To/Dir -to=trunk/Identity/NewPath/To/Dir
+

+
Sources:
+- trunk/Identity/Path/To/Dir
+- trunk/Translations/Identity/Path/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Path/To/Dir
+

+
Targets:
+- trunk/Identity/NewPath/To/Dir
+- trunk/Translations/Identity/NewPath/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/NewPath/To/Dir
+

+
Renderable layout 2:
+

+
Command:
+- centos-art render -copy=trunk/Identity/Themes/Motifs/TreeFlower \
+                    -to=trunk/Identity/Themes/Motifs/NewPath/To/Dir
+

+
Sources:
+- trunk/Identity/Themes/Motifs/TreeFlower
+- trunk/Translations/Identity/Themes
+- trunk/Translations/Identity/Themes/Motifs/TreeFlower
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/TreeFlower
+

+
Targets:
+- trunk/Identity/Themes/Motifs/NewPath/To/Dir
+- trunk/Translations/Identity/Themes
+- trunk/Translations/Identity/Themes/Motifs/NewPath/To/Dir
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes
+- trunk/Scripts/Bash/Functions/Render/Config/Identity/Themes/Motifs/NewPath/To/Dir
+

+
Notice that design models are not included in source or target
+locations. This is intentional. In "Renderable layout 2", design
+models live by their own, they just exist, they are there, available
+for any artistic motif to use. By default `Themes/Models/Default'
+design model directory structure is used, but other design models
+directory structures (under Themes/Models/) can be created and used
+changing the value of THEMEMODEL variable inside the pre-rendition
+configuration script of the artistic motif source location you want to
+produce.
+

+
Notice how translations and pre-rendition configuration scripts may
+both be equal in source and target. This is because such structures
+are common to all artistic motifs (the default values to use when no
+specific values are provided).
+

+
- The common directory structures are not copied or deleted. We cannot
+  copy a directory structure to itself.
+

+
- The common directory structures represent the default value to use
+  when no specific translations and/or pre-rendition configuration
+  script are provided inside source location.
+

+
- The specific directory structures, if present, are both copiable and
+  removable. This is, when you perform a copy or delete action from
+  source, that source specific auxiliar directories are transfered in
+  the copy action to a new location (that specified by FLAG_TO
+  variable).
+

+
- When translations and/or pre-rendition configuration scripts are
+  found inside the source directory structure, the centos-art.sh
+  script loads common auxiliar directories first and later specific
+  auxiliar directories.  This way, identity rendition of source
+  locations can be customized idividually over the base of common
+  default values.
+

+
- The specific auxiliar directories are optional.
+

+
- The common auxiliar directories should be present always. This is,
+  in order to provide the information required by render functionality
+  (i.e., to make it functional in the more basic level of its
+  existence).
+

+
Notice how the duplication process is done from `trunk/Identity' on,
+not the oposite. If you try to duplicate a translation structure (or
+similar auxiliar directory structures like pre-rendition configuration
+scripts), the `trunk/Identity' for that translation is not created.
+This limitation is impossed by the fact that many `trunk/Identity'
+directory structures may reuse/share the same translation directory
+structure. We cannot delete one translation (or similar) directory
+structures while a related `trunk/Identity/' directory structure is
+still in need of it.
+

+
The `render_doCopy' functionality does duplicate directory structures
+directly involved in rendition process only. Once such directories
+have been duplicated, the functionality stops thereat. 
+

+
+
+
 2.69.4 Usage 

+
+
    
+
  •  ...
+

+
+
+
+
 2.69.5 See also 

 
-
-
-
2.60 The `trunk/Scripts/Bash' Directory  
-

 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_74.html b/Manual/repository-html/repository_74.html
index 6b2cb3d..7f5e97f 100644
--- a/Manual/repository-html/repository_74.html
+++ b/Manual/repository-html/repository_74.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.70 The trunk/Scripts/Bash/Cli/Functions/Shell Directory
+CentOS Artwork Repository: 2.70 The trunk/Scripts/Bash/Cli/Functions/Render/Config Directory
 
-
-
+
+
 
 
 
@@ -55,223 +55,233 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 2.70 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory 

+
+
+
 2.70 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory 

 
 
-
+
 
 2.70.1 Goals 

 
-
This section exists to organize files related to shell
-functionality of `centos-art.sh' script.
+
The `trunk/Scripts/Bash/Config' directory exists to oraganize
+pre-rendering configuration scripts.
 

 
-
+
 
 2.70.2 Description 

 
-
The shell functionality of `centos-art.sh' script helps
-you to maintain bash scripts inside repository. For example, suppose
-you've created many functionalities for `centos-art.sh' script,
-and you want to use a common copyright and license note for
-consistency in all your script files. If you have a bunch of files,
-doing this one by one wouldn't be a big deal. In contrast, if the
-amount of files grows, updating the copyright and license note for all
-of them would be a task rather tedious. The shell functionality
-exists to solve maintainance tasks just as the one previously
-mentioned.
+
Pre-rendering configuration scripts let you customize the way
+centos-art.sh script renders identity and translation
+repository entries.  Pre-rendering configuration scripts are
+`render.conf.sh' files with render_loadConfig function
+definition inside. 
+

+
There is one `render.conf.sh' file for each pre-rendering
+configuration entry. Pre-rendering configuration entries can be based
+both on identity and translation repository entires.  Pre-rendering
+configuration entries are required for each identity entry, but not
+for translation entries. 
 

-
When you use shell functionality to update copyright inside
-script files, it is required that your script files contain (at least)
-the following top commentary structure:
+
+
+
 2.70.2.1 The `render.conf.sh' identity model 

+
+
Inside CentOS Artwork Repository, we consider identity entries to all
+directories under `trunk/Identity' directory. Identity entries can be
+image-based or text-based. When you render image-based identity
+entries you need to use image-based pre-rendering configuration
+scripts. Likewise, when you render text-based identity entries you
+need to use text-based pre-rendering configuration scripts.
 

-

-
 1| #!/bin/bash
- 2| #
- 3| # doSomething.sh -- The function description goes here.
- 4| # 
- 5| # Copyright
- 6| #
- 7| # ...
- 8| #
- 9| # ----------------------------------------------------------------------
-10| # $Id$
-11| # ----------------------------------------------------------------------
-12|
-13| function doSomething {
-14|     
-15| }
+
Inside identity pre-rendering configuration scripts, image-based
+pre-rendering configuration scripts look like the following:
+

+
#!/bin/bash
+
+function render_loadConfig {
+
+    # Define rendering actions.
+    ACTIONS[0]='BASE:renderImage'
+    ACTIONS[1]='POST:renderFormats: tif xpm pdf ppm'
+
+}
 

-
Figure 2.4: The functions script base comment structure
-
+
Inside identity pre-rendering configuration scripts, text-based
+pre-rendering configuration scripts look like the following:
 

-
Relevant lines in the above structure are lines from 5 to 9.
-Everything else in the file is left immutable.
+
#!/bin/bash
+
+function render_loadConfig {
+
+    # Define rendering actions.
+    ACTIONS[0]='BASE:renderText'
+    ACTIONS[1]='POST:formatText: --width=70 --uniform-spacing'
+
+}
+

+
When using identity pre-rendering configuration scripts, you can
+extend both image-based and text-based pre-rendering configuration
+scripts using image-based and text-based post-rendering actions,
+respectively. 
 

-
When you are updating copyright through shell
-functionality,  the `centos-art.sh' script replaces everything
-in-between line 5 --the first one matching `^# Copyright .+$'
-string-- and line 9--the first long dash separator matching `^#
--+$'-- with the content of copyright template instance.
+
+
+
 2.70.2.2 The `render.conf.sh' translation model 

+
+
Translation pre-rendering configuration scripts take precedence before
+default translation rendering action. Translation pre-rendering
+actions are useful when default translation rendering action do not
+fit itself to translation entry rendering requirements.
 

-
Caution
Caution
 Be sure to add the long dash separator that matches
-`^# -+$' regular expression before the function
-definition. Otherwise, if the `Copyright' line is present but no
-long dash separator exists, `centos-art.sh' will remove anything
-in-between the `Copyright' line and the end of file. This way you
-may lost your function definitions entirely.
-

 
-
The copyright template instance is created from one copyright template
-stored in the `Config/tpl_forCopyright.sed' file.  The template
-instance is created once, and later removed when no longer needed. At
-this moment, when template instance is created, the
-`centos-art.sh' script takes advantage of automation in order to
-set copyright full name and date dynamically.
+
+
 2.70.2.3 The `render.conf.sh' rendering actions 

+
+
Inside both image-based and text-based identity pre-rendering
+configuration scripts, we use the `ACTIONS' array variable to
+define the way centos-art.sh script performs identity
+rendering.  Identity rendering is organized by one `BASE' action,
+and optional `POST' and `LAST' rendering actions.
 

-
When you use shell functionality to update copyright, the first
-thing `shell' functionality does is requesting copyright
-information to user, and later, if values were left empty (i.e., no
-value was typed before pressing RET key), the `shell'
-functionality uses its own default values.
+
The `BASE' action specifies what kind of rendering does the
+centos-art.sh script will perform with the files related to
+the pre-rendering configuration script. The `BASE' action is
+required. Possible values to `BASE' action are either
+`renderImage' or `renderText' only.
 

-
When shell functionality uses its own default values, the final
-copyright note looks like the following:
+
To specify the `BASE' action you need to set the `BASE:'
+string followed by one of the possible values. For example, if you
+want to render images, consider the following definition of
+`BASE' action:
 

-

-
 1| #!/bin/bash
- 2| #
- 3| # doSomthing.sh -- The function description goes here.
- 4| #
- 5| # Copyright (C) 2003, 2010 The CentOS Project
- 6| # 
- 7| # This program is free software; you can redistribute it and/or modify
- 8| # it under the terms of the GNU General Public License as published by
- 9| # the Free Software Foundation; either version 2 of the License, or
-10| # (at your option) any later version.
-11| # 
-12| # This program is distributed in the hope that it will be useful, but
-13| # WITHOUT ANY WARRANTY; without even the implied warranty of
-14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-15| # General Public License for more details.
-16| #
-17| # You should have received a copy of the GNU General Public License
-18| # along with this program; if not, write to the Free Software
-19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
-20| # USA.
-21| #
-22| # ----------------------------------------------------------------------
-23| # $Id$
-24| # ----------------------------------------------------------------------
-25|
-26| function doSomething {
-27|
-28| }
+
ACTIONS[0]='BASE:renderImage'
 

-
Figure 2.5: The function script comment example
-
+
Only one `BASE' action must be specified. If more than one
+`BASE' action is specified, the last one is used. If no
+`BASE' action is specified at all, an error is triggered and the
+centos-art.sh script ends its execution.
 

-
Relevant lines in the above structure are lines from 5 to 22.  Pay
-attention how the copyright line was built, and how the license was
-added into the top comment where previously was just three dots.
-Everything else in the file was left immutable. 
+
The `POST' action specifies which action to apply for
+each file rendered (at the rendering time). This action is optional.
+You can set many different `POST' actions to apply many different
+actions over the same already rendered file. Possible values to
+`POST' action are `renderFormats', `renderSyslinux',
+`renderGrub', etc. 
 

-
To change copyright information (i.e., full name or year information),
-run the shell functionality over the root directory containing
-the script files you want to update copyright in and enter the
-appropriate information when it be requested. You can run the
-shell functionality as many times as you need to.
+
To specify the `POST' action, you need to use set the
+`POST:' followed by the function name of the action you want to
+perform.  The exact form depends on your needs. For example, consider
+the following example to produce `xpm', `jpg', and
+`tif' images, based on already rendered `png' image, and
+also organize the produced files in directories named as their own
+extensions:
 

-
To change copyright license (i.e., the text in-between lines 7 and
-20), you need to edit the `Config/tpl_forCopyright.sed' file, set
-the appropriate information, and run the shell functionality
-once again for changes to take effect over the files you specify.
-

-
Important
Important
 The `centos-art.sh' script is released as: 
+
ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='POST:groupByFormat: png xpm jpg tif'
+

+
In the previous example, file organization takes place at the moment
+of rendering, just after producing the `png' base file and before
+going to the next file in the list of files to render. If you don't
+want to organized the produced files in directories named as their own
+extensions, just remove the `POST:groupByFormat' action line:
 

-
GNU GENERAL PUBLIC LICENSE
-Version 2, June 1991
-
-Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
 

-
Do not change the license information under which `centos-art.sh'
-script is released. Instead, if you think a different license must be
-used, please share your reasons at CentOS Developers mailing list.
+
The `LAST' action specifies which actions to apply once the last
+file in the list of files to process has been rendered. The
+`LAST' action is optional. Possible values for `LAST'
+actions may be `groupByFormat', `renderGdmTgz', etc.
+

+
info
Note
 -- Removed(xref:trunk Scripts Bash Functions Render) --, to know more
+about possible values for `BASE', `POST' and `LAST'
+action definitions.
 

 
+
To specify the `LAST' action, you need to set the `LAST:'
+string followed by the function name of the action you want to
+perform.  For example, consider the following example if you want to
+render all files first and organize them later:
+

+
ACTIONS[0]='BASE:renderImage'
+ACTIONS[1]='POST:renderFormats: xpm jpg tif'
+ACTIONS[2]='LAST:groupByformat: png xpm jpg tif'
+

 
-
+
 
 2.70.3 Usage 

 
+
Use the following commands to administer both identity and translation
+pre-rendering configuration scripts:
+

 

-
 centos-art sh --update-copyright='path/to/dir'

-
 centos-art sh --update-copyright='path/to/dir' --filter='regex'

-
Use these commands to update copyright information in `.sh' files
-under `path/to/dir' directory. 
-

-

-
-
When you provide `--filter='regex'' argument, the list of files
-to process is reduced as specified in `regex' regular expression.
-Inside `centos-art.sh' script, the `regex' regular
-expression is used in combination with find command to look
-for files matching the regular expression path pattern.
+
 `centos-art config --create='path/to/dir/''

+

+
Use this command to create `path/to/dir' related pre-rendering
+configuration script.
 

-
Warning
Warning
 In order for `regex' regular expression to match
-a file, the `regex' regular expresion must match the whole file
-path not just the file name. 
-

-
-
For example, if you want to match all `render.conf.sh' files
-inside `path/to/dir', use the .+/render.conf regular
-expression.  Later, `centos-art.sh' script uses this value inside
-^$REGEX\.sh$ expression in order to build the final regular
-expression (i.e., ^.+/render.conf\.sh$) that is evaluated
-against available file paths inside the list of files to process.
+

+
 `centos-art config --edit='path/to/dir/''

+

+
Use this command to edit `path/to/dir' related pre-rendering
+configuration script.  
+

+

+
 `centos-art config --read='path/to/dir/''

+

+
Use this command to read `path/to/dir' related pre-rendering
+configuration script.  
 

-
Exceptionally, when you provide `--filter='regex'' in the way
-that `regex', appended to `path/to/dir/' (i.e.
-`path/to/dir/regex'), matches a regular file; the
-`centos-art.sh' script uses the file matching as only file in the
-list of files to process. 
+

+
 `centos-art config --remove='path/to/dir/''

+

+
Use this command to remove `path/to/dir' related pre-rendering
+configuration script.
 

+

+
 
-
+
In the commands above, `path/to/dir' refers to one renderable
+directory path under `trunk/Identity' or
+`trunk/Translations' structures only. 
+

+
+
 
 2.70.4 See also 

 
 
-
2.60 The `trunk/Scripts/Bash' Directory  
+
2.61 The `trunk/Scripts/Bash' Directory  
 

 

 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_75.html b/Manual/repository-html/repository_75.html
index ef8685e..1da7cd9 100644
--- a/Manual/repository-html/repository_75.html
+++ b/Manual/repository-html/repository_75.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.71 The trunk/Scripts/Bash/Cli/Functions/Svg Directory
+CentOS Artwork Repository: 2.71 The trunk/Scripts/Bash/Cli/Functions/Shell Directory
 
-
-
+
+
 
 
 
@@ -55,207 +55,175 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 2.71 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory 

+
+
+
 2.71 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory 

 
 
-
+
 
 2.71.1 Goals 

 
-
This section exists to organize files related to svg
+
This section exists to organize files related to shell
 functionality of `centos-art.sh' script.
 

 
-
+
 
 2.71.2 Description 

 
-
The svg functionality of `centos-art.sh' script helps you
-to maintain scalable vector graphics (SVG) inside repository. For
-example, suppose you've been working in CentOS default design models
-under `trunk/Identity/Themes/Models/', and you want to set common
-metadata to all of them, and later remove all unused SVG defintions
-from `*.svg' files. Doing so file by file may be a tedious task,
-so the `centos-art.sh' script provides the svg
-functionality to aid you maintain such actions.
-

-
-
-
-
 2.71.2.1 Metadata maintainance 

-
-
The metadata used is defined by Inkscape 0.46 using the SVG standard
-markup. The `centos-art.sh' script replaces everything
-in-between <metadata and </metadata> tags with a
-predefined metadata template we've set for this purpose.
-

-
The metadata template was created using the metadata information of a
-file which, using Inkscape 0.46, all metadata fields were set. This
-created a complete markup representation of how SVG metadata would
-look like. Later, we replaced every single static value with a
-translation marker in the form `=SOMETEXT=', where
-SOMETEXT is the name of its main opening tag. Later, we
-transform the metadata template into a sed replacement set of commads
-escaping new lines at the end of each line.
+
The shell functionality of `centos-art.sh' script helps
+you to maintain bash scripts inside repository. For example, suppose
+you've created many functionalities for `centos-art.sh' script,
+and you want to use a common copyright and license note for
+consistency in all your script files. If you have a bunch of files,
+doing this one by one wouldn't be a big deal. In contrast, if the
+amount of files grows, updating the copyright and license note for all
+of them would be a task rather tedious. The shell functionality
+exists to solve maintainance tasks just as the one previously
+mentioned.
 

-
With metadata template in place, the `centos-art.sh' script uses
-it to create a metadata template instance for the file being processed
-currently.  The metadata template instance contains the metadata
-portion of sed replacement commands with translation markers already
-traduced.  In this action, instance creation, is where we take
-advantage of automation and generate metadata values like title, date,
-keywords, source, identifier, and relation dynamically, based on the
-file path `centos-art.sh' script is currently creating metadata
-information for.
+
When you use shell functionality to update copyright inside
+script files, it is required that your script files contain (at least)
+the following top commentary structure:
 

-
With metadata template instance in place, the `centos-art.sh'
-script uses it to replace real values inside all `.svg' files
-under the current location you're running the `centos-art.sh'
-script on.  Default behaviour is to ask user to enter each metadatum
-required, one by one. If user leaves metadatum empty, by pressing
-RET key, `centos-art.sh' uses its default value.
+

+
 1| #!/bin/bash
+ 2| #
+ 3| # doSomething.sh -- The function description goes here.
+ 4| # 
+ 5| # Copyright
+ 6| #
+ 7| # ...
+ 8| #
+ 9| # ----------------------------------------------------------------------
+10| # $Id$
+11| # ----------------------------------------------------------------------
+12|
+13| function doSomething {
+14|     
+15| }
+

+
Figure 2.4: The functions script base comment structure
+
 

-
The `centos-art.sh' script modifies the following metadata:
+
Relevant lines in the above structure are lines from 5 to 9.
+Everything else in the file is left immutable.
 

-

-
 `Title'

-
Name by which this document is formally known. If no value is set
-here, `centos-art.sh' script uses the file name as title.
+
When you are updating copyright through shell
+functionality,  the `centos-art.sh' script replaces everything
+in-between line 5 --the first one matching `^# Copyright .+$'
+string-- and line 9--the first long dash separator matching `^#
+-+$'-- with the content of copyright template instance.
 

-

-
 `Date'

-
Date associated with the creation of this document (YYYY-MM-DD). If no
-value is set here, `centos-art.sh' script uses the current date
-information as in date +%Y-%m-%d.
-

-

-
 `Creator'

-
Name of entity primarily responsible for making the content of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
-

-

-
 `Rights'

-
Name of entity with rights to the intellectual Property of this
-document. If no value is set here, `centos-art.sh' script uses
-the string `The CentOS Project'.
-

-

-
 `Publisher'

-
Name of entity responsible for making this document available. If no
-value is set here, `centos-art.sh' script uses the string
-`The CentOS Project'.
-

-

-
 `Identifier'

-
Unique URI to reference this document. If no value is set here,
-`centos-art.sh' script uses the current file path to build the
-related url that points to current file location inside repository
-central server.
+
Caution
Caution
 Be sure to add the long dash separator that matches
+`^# -+$' regular expression before the function
+definition. Otherwise, if the `Copyright' line is present but no
+long dash separator exists, `centos-art.sh' will remove anything
+in-between the `Copyright' line and the end of file. This way you
+may lost your function definitions entirely.
+

+
+
The copyright template instance is created from one copyright template
+stored in the `Config/tpl_forCopyright.sed' file.  The template
+instance is created once, and later removed when no longer needed. At
+this moment, when template instance is created, the
+`centos-art.sh' script takes advantage of automation in order to
+set copyright full name and date dynamically.
 

-

-
 `Source'

-
Unique URI to reference the source of this document. If no value is
-set here, `centos-art.sh' script uses current file path to build
-the related url that points to current file location inside repository
-central server.
+
When you use shell functionality to update copyright, the first
+thing `shell' functionality does is requesting copyright
+information to user, and later, if values were left empty (i.e., no
+value was typed before pressing RET key), the `shell'
+functionality uses its own default values.
 

-

-
 `Relation'

-
Unique URI to a related document. If no value is set here,
-`centos-art.sh' script uses current file path to build the
-related url that points to current file location inside repository
-central server.
+
When shell functionality uses its own default values, the final
+copyright note looks like the following:
 

-

-
 `Language'

-
Two-letter language tag with optional subtags for the language of this
-document. (e.g. `en-GB'). If no value is set here,
-`centos-art.sh' script uses the current locale information as in
-cli_getCurrentLocale function.
+

+
 1| #!/bin/bash
+ 2| #
+ 3| # doSomthing.sh -- The function description goes here.
+ 4| #
+ 5| # Copyright (C) 2003, 2010 The CentOS Project
+ 6| # 
+ 7| # This program is free software; you can redistribute it and/or modify
+ 8| # it under the terms of the GNU General Public License as published by
+ 9| # the Free Software Foundation; either version 2 of the License, or
+10| # (at your option) any later version.
+11| # 
+12| # This program is distributed in the hope that it will be useful, but
+13| # WITHOUT ANY WARRANTY; without even the implied warranty of
+14| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+15| # General Public License for more details.
+16| #
+17| # You should have received a copy of the GNU General Public License
+18| # along with this program; if not, write to the Free Software
+19| # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+20| # USA.
+21| #
+22| # ----------------------------------------------------------------------
+23| # $Id$
+24| # ----------------------------------------------------------------------
+25|
+26| function doSomething {
+27|
+28| }
+

+
Figure 2.5: The function script comment example
+
 

-

-
 `Keywords'

-
The topic of this document as comma-separated key words, prhases, or
-classifications. If no value is set here, `centos-art.sh' script
-uses file path to build 
+
Relevant lines in the above structure are lines from 5 to 22.  Pay
+attention how the copyright line was built, and how the license was
+added into the top comment where previously was just three dots.
+Everything else in the file was left immutable. 
 

-

-
 `Coverage'

-
Extent or scope of this document. If no value is set here,
-`centos-art.sh' script uses the string `The CentOS Project'.
+
To change copyright information (i.e., full name or year information),
+run the shell functionality over the root directory containing
+the script files you want to update copyright in and enter the
+appropriate information when it be requested. You can run the
+shell functionality as many times as you need to.
 

-

-
 `Description'

-
Description about the document. If no value is set here,
-`centos-art.sh' script uses uses empty value as default.
+
To change copyright license (i.e., the text in-between lines 7 and
+20), you need to edit the `Config/tpl_forCopyright.sed' file, set
+the appropriate information, and run the shell functionality
+once again for changes to take effect over the files you specify.
 

-

-
 `Contributors'

-
People that contributes in the creation/maintainance of the document.
-If no value is set here, `centos-art.sh' script uses uses empty
-value as default.
-

-

-
-
The `License' metadatum is not set as a choise, by now. It is
-fixed Creative Common Attribution Share-Alike 3.0 License. This is done in order to
-grant license consistency among all SVG files we manage inside CentOS
-Artwork Repository.
+
Important
Important
 The `centos-art.sh' script is released as: 
 

-
+
GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991
 
-
-
 2.71.2.2 Unused definitions 

+Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+

+
Do not change the license information under which `centos-art.sh'
+script is released. Instead, if you think a different license must be
+used, please share your reasons at CentOS Developers mailing list.
+

 
-
Many of the no-longer-used gradients, patterns, and markers (more
-precisely, those which you edited manually) remain in the
-corresponding palettes and can be reused for new objects. However if
-you want to optimize your document, use the `Vacuum Defs' command
-in `File' menu. It will remove any gradients, patterns, or
-markers which are not used by anything in the document, making the
-file smaller. 
-

-
If you have one or two couple of files, removing unused definitions
-using the graphical interface may be enough to you.  In contrast, if
-you have dozens or even houndreds of scalable vector graphics files to
-maintain it is not a fun task to use the graphical interface to remove
-unused definitions editing those files one by one.
-

-
To remove unused definitions from several scalable vector graphics
-files, the `centos-art.sh' script uses Inkscape command-line
-interface, specifically with the `--vaccum-defs' option.
-

 
-
+
 
 2.71.3 Usage 

 
 

-
 centos-art svg --update-metadata='path/to/dir'

-
 centos-art svg --update-metadata='path/to/dir' --filter='regex'

-
Use these commands to update metadata information to `.svg' files
-under `path/to/dir' directory.
-

-

-
 centos-art svg --vacuum-defs='path/to/dir'

-
 centos-art svg --vacuum-defs='path/to/dir' --filter='regex'

-
Use these commands to remove unused definitions inside `.svg'
-files under `path/to/dir' directory. 
+
 centos-art sh --update-copyright='path/to/dir'

+
 centos-art sh --update-copyright='path/to/dir' --filter='regex'

+
Use these commands to update copyright information in `.sh' files
+under `path/to/dir' directory. 
 

 

 
@@ -270,12 +238,12 @@ a file, the `regex' regular expresion must match the whole file
 path not just the file name. 
 

 
-
For example, if you want to match all `summary.svg' files inside
-`path/to/dir', use the .+/summary regular expression.
-Later, `centos-art.sh' script uses this value inside
-^$REGEX\.svg$ expression in order to build the final regular
-expression (i.e., ^.+/summary\.svg$) that is evaluated against
-available file paths inside the list of files to process.
+
For example, if you want to match all `render.conf.sh' files
+inside `path/to/dir', use the .+/render.conf regular
+expression.  Later, `centos-art.sh' script uses this value inside
+^$REGEX\.sh$ expression in order to build the final regular
+expression (i.e., ^.+/render.conf\.sh$) that is evaluated
+against available file paths inside the list of files to process.
 

 
Exceptionally, when you provide `--filter='regex'' in the way
 that `regex', appended to `path/to/dir/' (i.e.
@@ -284,26 +252,26 @@ that `regex', appended to `path/to/dir/' (i.e.
 list of files to process. 
 

 
-
+
 
 2.71.4 See also 

 
 
-
2.60 The `trunk/Scripts/Bash' Directory  
+
2.61 The `trunk/Scripts/Bash' Directory  
 

 

 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_76.html b/Manual/repository-html/repository_76.html
index 853a830..6e8a4f5 100644
--- a/Manual/repository-html/repository_76.html
+++ b/Manual/repository-html/repository_76.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.72 The trunk/Scripts/Bash/Cli/Functions/Verify Directory
+CentOS Artwork Repository: 2.72 The trunk/Scripts/Bash/Cli/Functions/Svg Directory
 
-
-
+
+
 
 
 
@@ -55,302 +55,255 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 2.72 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory 

+
+
+
 2.72 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory 

 
 
-
+
 
 2.72.1 Goals 

 
-
This section exists to organize files related to `centos-art.sh'
-script `verify' functionality.  The `verify'
-functionality of `centos-art.sh' script helps you to verify the
-workstation configuration you are planning to use as host for your
-working copy of CentOS Artwork Repository.
+
This section exists to organize files related to svg
+functionality of `centos-art.sh' script.
 

 
-
+
 
 2.72.2 Description 

 
-
The first time you download CentOS Artwork Repository you need to
-configure your workstation in order to use `centos-art.sh'
-script.  These preliminar configurations are based mainly on auxiliar
-RPM packages installation, symbolic links creations, and environment
-variables definitions.  The `verify' functionality of
-`centos-art.sh' script guides you through this preliminar
-configuration process.  
-

-
If this is the first time you run `centos-art.sh' script, the
-appropriate way to use its `verify' functionality is not using
-the `centos-art.sh' script directly, but the absolute path to
-centos-art.sh script instead (i.e.,
-`~/artwork/trunk/Scripts/Bash/centos-art.sh').  This is necessary
-because `centos-art' symbolic link, under `~/bin/'
-directory, has not been created yet.
-

-
-
-
 2.72.2.1 Packages 

-
-
Installation of auxiliar RPM packages provides the software required
-to manipulate files inside the repository (e.g., image files,
-documentation files, translation files, script files, etc.). Most of
-RPM packages centos-art.sh script uses are shipped with
-CentOS distribution, and can be installed from CentOS base repository.
-The only exception is `inkscape', the package we use to
-manipulate SVG files.  The `inkscape' package is not inside
-CentOS distribution so it needs to be installed from third party
-repositories.
-

-
info
Note
 Configuration of third party repositories inside CentOS
-distribution is described in CentOS wiki, specifically in the
-following URL:
-http://wiki.centos.org/AdditionalResources/Repositories
-

-
-
Before installing packages, the `centos-art.sh' script uses
-sudo to request root privileges to execute yum
-installation functionality.  If your user isn't defined as a
-privileged user--at least to run yum commands-- inside
-`/etc/sudoers' configuration file, you will not be able to
-perform package installation tasks as set in `centos-art.sh'
-script `verify' functionality. 
-

-
Setting sudo privileges to users is an administrative task you have to
-do by yourself. If you don't have experience with sudo
-command, please read its man page running the command: man
-sudo. This reading will be very useful, and with some practice, you
-will be able to configure your users to have sudo
-privileges.
-

-
-
-
 2.72.2.2 Links 

-
-
Creation of symbolic links helps us to alternate between different
-implementations of `centos-art.sh' script-line (e.g.,
-`centos-art.sh', for Bash implementation; `centos-art.py',
-for Python implementation; `centos-art.pl', for Perl
-implementation; and so on for other implementations). The
-`centos-art.sh' script-line definition takes place inside your
-personal binary (`~/bin/') directory in order to make the script
-implementation --the one that `centos-art' links to-- available
-to PATH environment variable.
-

-
Creation of symbolic links helps us to reuse components from repository
-working copy. For example, color information files maintained inside
-your working copy must never be duplicated inside program-specific
-configuration directories that uses them in your workstation (e.g.,
-Gimp, Inkscape, etc.).  Instead, a symbolic link must be created for
-each one of them, from program-specific configuration directories to
-files in the working copy.  In this configuration, when someone
-commits changes to color information files up to central repository,
-they--the changes committed-- will be immediatly available to your
-programs the next time you update your working copy --the place
-inside your workstation those color information files are stored--.
-

-
Creation of symbolic links helps us to make `centos-art.sh'
-script functionalities available outside `trunk/' repository
-directory structure, but at its same level in repository tree. This is
-useful if you need to use the "render" functionality of
-centos-art.sh under `branches/' repository directory
-structure as you usually do inside `trunk/' repository directory
-structure. As consequence of this configuration, automation scripts
-cannot be branched under `branches/Scripts' directory structure.
+
The svg functionality of `centos-art.sh' script helps you
+to maintain scalable vector graphics (SVG) inside repository. For
+example, suppose you've been working in CentOS default design models
+under `trunk/Identity/Themes/Models/', and you want to set common
+metadata to all of them, and later remove all unused SVG defintions
+from `*.svg' files. Doing so file by file may be a tedious task,
+so the `centos-art.sh' script provides the svg
+functionality to aid you maintain such actions.
 

+
 
-
-
 2.72.2.3 Environment variables 

-
-
Definition of environemnt variables helps us to set default values to
-our user session life. The user session environment variable defintion
-takes place in the user's `~/.bash_profile' file.  The
-`verify' functionality of `centos-art.sh' script doesn't
-modify your `~/.bash_profile' file.  
-

-
The `verify' functionality of `centos-art.sh' script
-evaluates the following environment variables:
+
+
 2.72.2.1 Metadata maintainance 

+
+
The metadata used is defined by Inkscape 0.46 using the SVG standard
+markup. The `centos-art.sh' script replaces everything
+in-between <metadata and </metadata> tags with a
+predefined metadata template we've set for this purpose.
+

+
The metadata template was created using the metadata information of a
+file which, using Inkscape 0.46, all metadata fields were set. This
+created a complete markup representation of how SVG metadata would
+look like. Later, we replaced every single static value with a
+translation marker in the form `=SOMETEXT=', where
+SOMETEXT is the name of its main opening tag. Later, we
+transform the metadata template into a sed replacement set of commads
+escaping new lines at the end of each line.
+

+
With metadata template in place, the `centos-art.sh' script uses
+it to create a metadata template instance for the file being processed
+currently.  The metadata template instance contains the metadata
+portion of sed replacement commands with translation markers already
+traduced.  In this action, instance creation, is where we take
+advantage of automation and generate metadata values like title, date,
+keywords, source, identifier, and relation dynamically, based on the
+file path `centos-art.sh' script is currently creating metadata
+information for.
+

+
With metadata template instance in place, the `centos-art.sh'
+script uses it to replace real values inside all `.svg' files
+under the current location you're running the `centos-art.sh'
+script on.  Default behaviour is to ask user to enter each metadatum
+required, one by one. If user leaves metadatum empty, by pressing
+RET key, `centos-art.sh' uses its default value.
+

+
The `centos-art.sh' script modifies the following metadata:
 

 

-
 EDITOR

-
Default text editor. 
-

-
The `centos-art.sh' script uses default text EDITOR to edit
-pre-commit subversion messages, translation files, configuration
-files, script files, and similar text-based files.
-

-
If EDITOR environment variable is not set, `centos-art.sh'
-script uses `/usr/bin/vim' as default text editor. Otherwise, the
-following values are recognized by `centos-art.sh' script:
+
 `Title'

+
Name by which this document is formally known. If no value is set
+here, `centos-art.sh' script uses the file name as title.
 

-
    
-
  •  `/usr/bin/vim'
-
  •  `/usr/bin/emacs'
-
  •  `/usr/bin/nano'
-

-
-
If no one of these values is set in EDITOR environment variable,
-`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
+

+
 `Date'

+
Date associated with the creation of this document (YYYY-MM-DD). If no
+value is set here, `centos-art.sh' script uses the current date
+information as in date +%Y-%m-%d.
 

 

-
 TEXTDOMAIN

-

-
Default domain used to retrieve translated messages.  This variable is
-set in `initFunctions.sh' and shouldn't be changed.
+
 `Creator'

+
Name of entity primarily responsible for making the content of this
+document. If no value is set here, `centos-art.sh' script uses
+the string `The CentOS Project'.
 

 

-
 TEXTDOMAINDIR

-

-
Default directory used to retrieve translated messages.  This variable
-is set in `initFunctions.sh' and shouldn't be changed.
+
 `Rights'

+
Name of entity with rights to the intellectual Property of this
+document. If no value is set here, `centos-art.sh' script uses
+the string `The CentOS Project'.
 

 

-
 LANG

-

-
Default locale information.
+
 `Publisher'

+
Name of entity responsible for making this document available. If no
+value is set here, `centos-art.sh' script uses the string
+`The CentOS Project'.
 

-
This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-`Language' step; or once installed using the
-system-config-language tool.
+

+
 `Identifier'

+
Unique URI to reference this document. If no value is set here,
+`centos-art.sh' script uses the current file path to build the
+related url that points to current file location inside repository
+central server.
 

-
The `centos-art.sh' script uses the LANG environment
-variable to know in which language the script messages are printed
-out.
+

+
 `Source'

+
Unique URI to reference the source of this document. If no value is
+set here, `centos-art.sh' script uses current file path to build
+the related url that points to current file location inside repository
+central server.
 

 

-
 TZ

-

-
Default time zone representation.
+
 `Relation'

+
Unique URI to a related document. If no value is set here,
+`centos-art.sh' script uses current file path to build the
+related url that points to current file location inside repository
+central server.
 

-
This variable is initially set in the configuration process of CentOS
-distribution installer (i.e., Anaconda), specifically in the
-`Date and time' step; or once installed using the
-system-config-date tool.
+

+
 `Language'

+
Two-letter language tag with optional subtags for the language of this
+document. (e.g. `en-GB'). If no value is set here,
+`centos-art.sh' script uses the current locale information as in
+cli_getCurrentLocale function.
 

-
The `centos-art.sh' script doesn't use the TZ environment
-variable information at all. Instead, this variable is used by the
-system shell to show the time information according to your phisical
-location on planet Earth.  
+

+
 `Keywords'

+
The topic of this document as comma-separated key words, prhases, or
+classifications. If no value is set here, `centos-art.sh' script
+uses file path to build 
 

-
Inside your computer, the time information is firstly set in the BIOS
-clock (which may need correction), and later in the configuration
-process of CentOS distribution installer (or later, by any of the
-related configuration tools inside CentOS distribution).  Generally,
-setting time information is a straight-forward task and configuration
-tools available do cover most relevant location. However, if you need
-a time precision not provided by the configuration tools available
-inside CentOS distribution then, using TZ variable may be
-necessary.
+

+
 `Coverage'

+
Extent or scope of this document. If no value is set here,
+`centos-art.sh' script uses the string `The CentOS Project'.
 

-
Convenction
Convenction
 In order to keep changes syncronized between
-central repository and its working copies: configure both repository
-server and workstations (i.e., the place where each working copy is
-set on) to use Coordinated Universal Time (UTC) as base time
-representation.  Later, correct the time information for your specific
-location using time zone correction.
-

-
-
The format of TZ environment variable is described in
-`tzset(3)' manual page.
+

+
 `Description'

+
Description about the document. If no value is set here,
+`centos-art.sh' script uses uses empty value as default.
 

 

+
 `Contributors'

+
People that contributes in the creation/maintainance of the document.
+If no value is set here, `centos-art.sh' script uses uses empty
+value as default.
+

 

 
+
The `License' metadatum is not set as a choise, by now. It is
+fixed Creative Common Attribution Share-Alike 3.0 License. This is done in order to
+grant license consistency among all SVG files we manage inside CentOS
+Artwork Repository.
+

+
 
-
-
 2.72.3 Usage 

+
+
 2.72.2.2 Unused definitions 

 
-

-
 centos-art verify --packages

-

-
Verify required packages your workstation needs in order to run the
-`centos-art.sh' script correctly.  If there are missing packages,
-the `centos-art.sh' script asks you to confirm their
-installation. When installing packages, the `centos-art.sh'
-script uses the yum application in order to achieve the
-task.
-

-
In case all packages required by `centos-art.sh' script are
-already installed in your workstation, the message `The required
-packages are already installed.' is output for you to know. 
-

-

-
 centos-art verify --links

-

-
Verify required links your workstation needs in order to run the
-centos-art command correctly.  If any required link is missing, the
-centos-art.sh script asks you to confirm their installation.
-To install required links, the centos-art.sh script uses the
-ln command.
-

-
In case all links required by `centos-art.sh' script are already
-created in your workstation, the message `The required links are
-already installed.' is output for you to know. 
+
Many of the no-longer-used gradients, patterns, and markers (more
+precisely, those which you edited manually) remain in the
+corresponding palettes and can be reused for new objects. However if
+you want to optimize your document, use the `Vacuum Defs' command
+in `File' menu. It will remove any gradients, patterns, or
+markers which are not used by anything in the document, making the
+file smaller. 
 

-
In case a regular file exists with the same name of a required link,
-the `centos-art.sh' script outputs the `Already exists as
-regular file.' message when listing required links that will be
-installed. Of course, as there is already a regular file where must be
-a link, no link is created. In such cases the `centos-art.sh'
-script will fall into a continue installation request for that missing
-link.  To end this continue request you can answer `No', or
-remove the existent regular file to let `centos-art.sh' script
-install the link on its place.
+
If you have one or two couple of files, removing unused definitions
+using the graphical interface may be enough to you.  In contrast, if
+you have dozens or even houndreds of scalable vector graphics files to
+maintain it is not a fun task to use the graphical interface to remove
+unused definitions editing those files one by one.
 

-

-
 centos-art verify --environment

-
 centos-art verify --environment --filter='regex'

-

-
Output a brief description of environment variables used by
-`centos-art.sh' script. 
+
To remove unused definitions from several scalable vector graphics
+files, the `centos-art.sh' script uses Inkscape command-line
+interface, specifically with the `--vaccum-defs' option.
 

-
If `--filter' option is provided, output is reduced as defined in
-the `regex' regular expression value. If `--filter' option
-is specified but `regex' value is not, the `centos-art.sh'
-script outputs information as if `--filter' option had not been
-provided at all.  
+
+
+
 2.72.3 Usage 

+
+

+
 centos-art svg --update-metadata='path/to/dir'

+
 centos-art svg --update-metadata='path/to/dir' --filter='regex'

+
Use these commands to update metadata information to `.svg' files
+under `path/to/dir' directory.
 

 

+
 centos-art svg --vacuum-defs='path/to/dir'

+
 centos-art svg --vacuum-defs='path/to/dir' --filter='regex'

+
Use these commands to remove unused definitions inside `.svg'
+files under `path/to/dir' directory. 
+

 

 
+
When you provide `--filter='regex'' argument, the list of files
+to process is reduced as specified in `regex' regular expression.
+Inside `centos-art.sh' script, the `regex' regular
+expression is used in combination with find command to look
+for files matching the regular expression path pattern.
+

+
Warning
Warning
 In order for `regex' regular expression to match
+a file, the `regex' regular expresion must match the whole file
+path not just the file name. 
+

 
-
+
For example, if you want to match all `summary.svg' files inside
+`path/to/dir', use the .+/summary regular expression.
+Later, `centos-art.sh' script uses this value inside
+^$REGEX\.svg$ expression in order to build the final regular
+expression (i.e., ^.+/summary\.svg$) that is evaluated against
+available file paths inside the list of files to process.
+

+
Exceptionally, when you provide `--filter='regex'' in the way
+that `regex', appended to `path/to/dir/' (i.e.
+`path/to/dir/regex'), matches a regular file; the
+`centos-art.sh' script uses the file matching as only file in the
+list of files to process. 
+

+
+
 
 2.72.4 See also 

 
 
-
2.60 The `trunk/Scripts/Bash' Directory  
+
2.61 The `trunk/Scripts/Bash' Directory  
 

 

 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_77.html b/Manual/repository-html/repository_77.html
index 6f0dc60..bc32670 100644
--- a/Manual/repository-html/repository_77.html
+++ b/Manual/repository-html/repository_77.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: 2.73 The trunk/Scripts/Python Directory
+CentOS Artwork Repository: 2.73 The trunk/Scripts/Bash/Cli/Functions/Verify Directory
 
-
-
+
+
 
 
 
@@ -55,69 +55,302 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 2.73 The `trunk/Scripts/Python' Directory 

+
+
+
 2.73 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory 

 
 
-
+
 
 2.73.1 Goals 

 
-
    
-
  •  ...
-

-
+
This section exists to organize files related to `centos-art.sh'
+script `verify' functionality.  The `verify'
+functionality of `centos-art.sh' script helps you to verify the
+workstation configuration you are planning to use as host for your
+working copy of CentOS Artwork Repository.
+

 
-
+
 
 2.73.2 Description 

 
-
    
-
  •  ...
-

+
The first time you download CentOS Artwork Repository you need to
+configure your workstation in order to use `centos-art.sh'
+script.  These preliminar configurations are based mainly on auxiliar
+RPM packages installation, symbolic links creations, and environment
+variables definitions.  The `verify' functionality of
+`centos-art.sh' script guides you through this preliminar
+configuration process.  
+

+
If this is the first time you run `centos-art.sh' script, the
+appropriate way to use its `verify' functionality is not using
+the `centos-art.sh' script directly, but the absolute path to
+centos-art.sh script instead (i.e.,
+`~/artwork/trunk/Scripts/Bash/centos-art.sh').  This is necessary
+because `centos-art' symbolic link, under `~/bin/'
+directory, has not been created yet.
+

 
+
+
 2.73.2.1 Packages 

 
-
-
 2.73.3 Usage 

+
Installation of auxiliar RPM packages provides the software required
+to manipulate files inside the repository (e.g., image files,
+documentation files, translation files, script files, etc.). Most of
+RPM packages centos-art.sh script uses are shipped with
+CentOS distribution, and can be installed from CentOS base repository.
+The only exception is `inkscape', the package we use to
+manipulate SVG files.  The `inkscape' package is not inside
+CentOS distribution so it needs to be installed from third party
+repositories.
+

+
info
Note
 Configuration of third party repositories inside CentOS
+distribution is described in CentOS wiki, specifically in the
+following URL:
+http://wiki.centos.org/AdditionalResources/Repositories
+

 
+
Before installing packages, the `centos-art.sh' script uses
+sudo to request root privileges to execute yum
+installation functionality.  If your user isn't defined as a
+privileged user--at least to run yum commands-- inside
+`/etc/sudoers' configuration file, you will not be able to
+perform package installation tasks as set in `centos-art.sh'
+script `verify' functionality. 
+

+
Setting sudo privileges to users is an administrative task you have to
+do by yourself. If you don't have experience with sudo
+command, please read its man page running the command: man
+sudo. This reading will be very useful, and with some practice, you
+will be able to configure your users to have sudo
+privileges.
+

+
+
+
 2.73.2.2 Links 

+
+
Creation of symbolic links helps us to alternate between different
+implementations of `centos-art.sh' script-line (e.g.,
+`centos-art.sh', for Bash implementation; `centos-art.py',
+for Python implementation; `centos-art.pl', for Perl
+implementation; and so on for other implementations). The
+`centos-art.sh' script-line definition takes place inside your
+personal binary (`~/bin/') directory in order to make the script
+implementation --the one that `centos-art' links to-- available
+to PATH environment variable.
+

+
Creation of symbolic links helps us to reuse components from repository
+working copy. For example, color information files maintained inside
+your working copy must never be duplicated inside program-specific
+configuration directories that uses them in your workstation (e.g.,
+Gimp, Inkscape, etc.).  Instead, a symbolic link must be created for
+each one of them, from program-specific configuration directories to
+files in the working copy.  In this configuration, when someone
+commits changes to color information files up to central repository,
+they--the changes committed-- will be immediatly available to your
+programs the next time you update your working copy --the place
+inside your workstation those color information files are stored--.
+

+
Creation of symbolic links helps us to make `centos-art.sh'
+script functionalities available outside `trunk/' repository
+directory structure, but at its same level in repository tree. This is
+useful if you need to use the "render" functionality of
+centos-art.sh under `branches/' repository directory
+structure as you usually do inside `trunk/' repository directory
+structure. As consequence of this configuration, automation scripts
+cannot be branched under `branches/Scripts' directory structure.
+

+
+
+
 2.73.2.3 Environment variables 

+
+
Definition of environemnt variables helps us to set default values to
+our user session life. The user session environment variable defintion
+takes place in the user's `~/.bash_profile' file.  The
+`verify' functionality of `centos-art.sh' script doesn't
+modify your `~/.bash_profile' file.  
+

+
The `verify' functionality of `centos-art.sh' script
+evaluates the following environment variables:
+

+

+
 EDITOR

+
Default text editor. 
+

+
The `centos-art.sh' script uses default text EDITOR to edit
+pre-commit subversion messages, translation files, configuration
+files, script files, and similar text-based files.
+

+
If EDITOR environment variable is not set, `centos-art.sh'
+script uses `/usr/bin/vim' as default text editor. Otherwise, the
+following values are recognized by `centos-art.sh' script:
+

 
    
-
  •  ...
+
  •  `/usr/bin/vim'
+
  •  `/usr/bin/emacs'
+
  •  `/usr/bin/nano'
 

 
+
If no one of these values is set in EDITOR environment variable,
+`centos-art.sh' uses `/usr/bin/vim' text editor by default. 
+

+

+
 TEXTDOMAIN

+

+
Default domain used to retrieve translated messages.  This variable is
+set in `initFunctions.sh' and shouldn't be changed.
+

+

+
 TEXTDOMAINDIR

+

+
Default directory used to retrieve translated messages.  This variable
+is set in `initFunctions.sh' and shouldn't be changed.
+

+

+
 LANG

+

+
Default locale information.
+

+
This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+`Language' step; or once installed using the
+system-config-language tool.
+

+
The `centos-art.sh' script uses the LANG environment
+variable to know in which language the script messages are printed
+out.
+

+

+
 TZ

+

+
Default time zone representation.
+

+
This variable is initially set in the configuration process of CentOS
+distribution installer (i.e., Anaconda), specifically in the
+`Date and time' step; or once installed using the
+system-config-date tool.
+

+
The `centos-art.sh' script doesn't use the TZ environment
+variable information at all. Instead, this variable is used by the
+system shell to show the time information according to your phisical
+location on planet Earth.  
+

+
Inside your computer, the time information is firstly set in the BIOS
+clock (which may need correction), and later in the configuration
+process of CentOS distribution installer (or later, by any of the
+related configuration tools inside CentOS distribution).  Generally,
+setting time information is a straight-forward task and configuration
+tools available do cover most relevant location. However, if you need
+a time precision not provided by the configuration tools available
+inside CentOS distribution then, using TZ variable may be
+necessary.
+

+
Convenction
Convenction
 In order to keep changes syncronized between
+central repository and its working copies: configure both repository
+server and workstations (i.e., the place where each working copy is
+set on) to use Coordinated Universal Time (UTC) as base time
+representation.  Later, correct the time information for your specific
+location using time zone correction.
+

 
-
-
 2.73.4 See also 

+
The format of TZ environment variable is described in
+`tzset(3)' manual page.
+

+

+

+
+
+
+
 2.73.3 Usage 

 
+

+
 centos-art verify --packages

+

+
Verify required packages your workstation needs in order to run the
+`centos-art.sh' script correctly.  If there are missing packages,
+the `centos-art.sh' script asks you to confirm their
+installation. When installing packages, the `centos-art.sh'
+script uses the yum application in order to achieve the
+task.
+

+
In case all packages required by `centos-art.sh' script are
+already installed in your workstation, the message `The required
+packages are already installed.' is output for you to know. 
+

+

+
 centos-art verify --links

+

+
Verify required links your workstation needs in order to run the
+centos-art command correctly.  If any required link is missing, the
+centos-art.sh script asks you to confirm their installation.
+To install required links, the centos-art.sh script uses the
+ln command.
+

+
In case all links required by `centos-art.sh' script are already
+created in your workstation, the message `The required links are
+already installed.' is output for you to know. 
+

+
In case a regular file exists with the same name of a required link,
+the `centos-art.sh' script outputs the `Already exists as
+regular file.' message when listing required links that will be
+installed. Of course, as there is already a regular file where must be
+a link, no link is created. In such cases the `centos-art.sh'
+script will fall into a continue installation request for that missing
+link.  To end this continue request you can answer `No', or
+remove the existent regular file to let `centos-art.sh' script
+install the link on its place.
+

+

+
 centos-art verify --environment

+
 centos-art verify --environment --filter='regex'

+

+
Output a brief description of environment variables used by
+`centos-art.sh' script. 
+

+
If `--filter' option is provided, output is reduced as defined in
+the `regex' regular expression value. If `--filter' option
+is specified but `regex' value is not, the `centos-art.sh'
+script outputs information as if `--filter' option had not been
+provided at all.  
+

+

+

 
 
+
+
 2.73.4 See also 

 
+
+
+
2.61 The `trunk/Scripts/Bash' Directory  
+

 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_78.html b/Manual/repository-html/repository_78.html
index 765258a..168740c 100644
--- a/Manual/repository-html/repository_78.html
+++ b/Manual/repository-html/repository_78.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: Index
+CentOS Artwork Repository: 2.74 The trunk/Scripts/Python Directory
 
-
-
+
+
 
 
 
@@ -55,174 +55,69 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
-
+
+
-
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 Index 

-
Jump to:   D
-   
-F
-   
-H
-   
-I
-   
-M
-   
-R
-   
-T
-   
-U
-   
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Index Entry Section
 
D
Document convenctions1.1 Document Convenctions
 
F
Feedback1.2 Send in Your Feedback
Filesystem branches2.1 The `branches' Directory
Filesystem tags2.2 The `tags' Directory
Filesystem trunk2.3 The `trunk' Directory
Filesystem trunk Identity2.4 The `trunk/Identity' Directory
Filesystem trunk Identity Brands2.5 The `trunk/Identity/Brands' Directory
Filesystem trunk Identity Fonts2.6 The `trunk/Identity/Fonts' Directory
Filesystem trunk Identity Icons2.7 The `trunk/Identity/Icons' Directory
Filesystem trunk Identity Isolinux2.8 The `trunk/Identity/Isolinux' Directory
Filesystem trunk Identity Models2.9 The `trunk/Identity/Models' Directory
Filesystem trunk Identity Models Css2.10 The `trunk/Identity/Models/Css' Directory
Filesystem trunk Identity Models Html2.11 The `trunk/Identity/Models/Html' Directory
Filesystem trunk Identity Models Img Promo Web2.12 The `trunk/Identity/Models/Img/Promo/Web' Directory
Filesystem trunk Identity Models Tpl2.13 The `trunk/Identity/Models/Tpl' Directory
Filesystem trunk Identity Models Tpl Brands2.14 The `trunk/Identity/Models/Tpl/Brands' Directory
Filesystem trunk Identity Models Tpl Promo Web2.15 The `trunk/Identity/Models/Tpl/Promo/Web' Directory
Filesystem trunk Identity Models Xcf2.16 The `trunk/Identity/Models/Xcf' Directory
Filesystem trunk Identity Release2.17 The `trunk/Identity/Release' Directory
Filesystem trunk Identity Themes2.18 The `trunk/Identity/Themes' Directory
Filesystem trunk Identity Themes Models2.19 The `trunk/Identity/Themes/Models' Directory
Filesystem trunk Identity Themes Models Alternative2.20 The `trunk/Identity/Themes/Models/Alternative' Directory
Filesystem trunk Identity Themes Models Default2.21 The `trunk/Identity/Themes/Models/Default' Directory
Filesystem trunk Identity Themes Models Default Concept2.22 The `trunk/Identity/Themes/Models/Default/Concept' Directory
Filesystem trunk Identity Themes Models Default Distro2.23 The `trunk/Identity/Themes/Models/Default/Distro' Directory
Filesystem trunk Identity Themes Models Default Distro Anaconda2.24 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory
Filesystem trunk Identity Themes Models Default Distro Firstboot2.25 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory
Filesystem trunk Identity Themes Models Default Distro Gdm2.26 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory
Filesystem trunk Identity Themes Models Default Distro Grub2.27 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory
Filesystem trunk Identity Themes Models Default Distro Gsplash2.28 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory
Filesystem trunk Identity Themes Models Default Distro Kdm2.29 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory
Filesystem trunk Identity Themes Models Default Distro Ksplash2.30 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory
Filesystem trunk Identity Themes Models Default Distro Rhgb2.31 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory
Filesystem trunk Identity Themes Models Default Distro Syslinux2.32 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory
Filesystem trunk Identity Themes Models Default Promo2.33 The `trunk/Identity/Themes/Models/Default/Promo' Directory
Filesystem trunk Identity Themes Models Default Web2.34 The `trunk/Identity/Themes/Models/Default/Web' Directory
Filesystem trunk Identity Themes Motifs2.35 The `trunk/Identity/Themes/Motifs' Directory
Filesystem trunk Identity Themes Motifs Flame2.36 The `trunk/Identity/Themes/Motifs/Flame' Directory
Filesystem trunk Identity Themes Motifs Modern2.37 The `trunk/Identity/Themes/Motifs/Modern' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds2.38 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Img2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Tpl2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Xcf2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory
Filesystem trunk Identity Themes Motifs Modern Distro Anaconda Progress2.42 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory
Filesystem trunk Identity Themes Motifs Modern Palettes2.43 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory
Filesystem trunk Identity Themes Motifs TreeFlower2.44 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory
Filesystem trunk Identity Themes Motifs TreeFlower Backgrounds2.45 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory
Filesystem trunk Identity Widgets2.46 The `trunk/Identity/Widgets' Directory
Filesystem trunk Locales2.47 The `trunk/Locales' Directory
Filesystem trunk Locales Identity2.48 The `trunk/Locales/Identity' Directory
Filesystem trunk Locales Identity Brands2.49 The `trunk/Locales/Identity/Brands' Directory
Filesystem trunk Locales Identity Brands Tpl2.50 The `trunk/Locales/Identity/Brands/Tpl' Directory
Filesystem trunk Locales Identity Fonts2.51 The `trunk/Locales/Identity/Fonts' Directory
Filesystem trunk Locales Identity Models2.52 The `trunk/Locales/Identity/Models' Directory
Filesystem trunk Locales Identity Release2.53 The `trunk/Locales/Identity/Release' Directory
Filesystem trunk Locales Identity Themes2.54 The `trunk/Locales/Identity/Themes' Directory
Filesystem trunk Locales Identity Themes Backgrounds2.55 The `trunk/Locales/Identity/Themes/Backgrounds' Directory
Filesystem trunk Locales Identity Themes Distro Anaconda Progress2.56 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory
Filesystem trunk Locales Identity Widgets2.57 The `trunk/Locales/Identity/Widgets' Directory
Filesystem trunk Manuals2.58 The `trunk/Manuals' Directory
Filesystem trunk Scripts2.59 The `trunk/Scripts' Directory
Filesystem trunk Scripts Bash2.60 The `trunk/Scripts/Bash' Directory
Filesystem trunk Scripts Bash Cli2.61 The `trunk/Scripts/Bash/Cli' Directory
Filesystem trunk Scripts Bash Cli Functions2.62 The `trunk/Scripts/Bash/Cli/Functions' Directory
Filesystem trunk Scripts Bash Cli Functions Help2.63 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory
Filesystem trunk Scripts Bash Cli Functions Html2.64 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory
Filesystem trunk Scripts Bash Cli Functions Locale2.65 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory
Filesystem trunk Scripts Bash Cli Functions Manual2.66 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory
Filesystem trunk Scripts Bash Cli Functions Path2.67 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory
Filesystem trunk Scripts Bash Cli Functions Render2.68 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory
Filesystem trunk Scripts Bash Cli Functions Render Config2.69 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory
Filesystem trunk Scripts Bash Cli Functions Shell2.70 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory
Filesystem trunk Scripts Bash Cli Functions Svg2.71 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory
Filesystem trunk Scripts Bash Cli Functions Verify2.72 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory
Filesystem trunk Scripts Python2.73 The `trunk/Scripts/Python' Directory
 
H
How to render brands' translation files2.49.3 Usage
How to render fonts' translation files2.51.3 Usage
 
I
Introduction1. Introduction
 
M
Metadata maintainance2.71.2 Description
 
R
Repository file system2. Repository File System
 
T
Translation brands file names2.49.2.1 Conventional file names
Translation brands file names2.49.2.2 Numeric file names
 
U
Unused definitions2.71.2.1 Metadata maintainance
 

-
Jump to:   D
-   
-F
-   
-H
-   
-I
-   
-M
-   
-R
-   
-T
-   
-U
-   
-

+
+
+
 2.74 The `trunk/Scripts/Python' Directory 

+
+
+
+
 2.74.1 Goals 

+
+
    
+
  •  ...
+

+
+
+
+
 2.74.2 Description 

+
+
    
+
  •  ...
+

+
+
+
+
 2.74.3 Usage 

+
+
    
+
  •  ...
+

+
+
+
+
 2.74.4 See also 

+
+
+
+
 
 
 
-
-
+
+
-
-
+
+
[ < ][ > ]
[ < ][ > ]
    
 [ << ][ Up ][ >> ][ Up ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_79.html b/Manual/repository-html/repository_79.html
index f9124d0..220a7bb 100644
--- a/Manual/repository-html/repository_79.html
+++ b/Manual/repository-html/repository_79.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
 
-CentOS Artwork Repository: List of Figures
+CentOS Artwork Repository: Index
 
-
-
+
+
 
 
 
@@ -55,49 +55,175 @@ ul.toc {list-style: none}
 
 
 
-
-
+
+
-
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ << ]
 [ Up ][ >> ][ >> ]
    
    
    
    
 [Top]
 [Contents][Index][Index]
 [ ? ]
 

-
-
-
 List of Figures 

-

-
Figure 2.1
The functionalities initialization environment.
-

-
Figure 2.2
The actions initialization environment.
-

-
Figure 2.3
The cli_commitRepoChanges function output.
-

-
Figure 2.4
The functions script base comment structure
-

-
Figure 2.5
The function script comment example
-

-

+
+
+
 Index 

+
Jump to:   D
+   
+F
+   
+H
+   
+I
+   
+M
+   
+R
+   
+T
+   
+U
+   
+

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Index Entry Section
 
D
Document convenctions1.1 Document Convenctions
 
F
Feedback1.2 Send in Your Feedback
Filesystem branches2.1 The `branches' Directory
Filesystem tags2.2 The `tags' Directory
Filesystem trunk2.3 The `trunk' Directory
Filesystem trunk Identity2.4 The `trunk/Identity' Directory
Filesystem trunk Identity Brands2.5 The `trunk/Identity/Brands' Directory
Filesystem trunk Identity Fonts2.6 The `trunk/Identity/Fonts' Directory
Filesystem trunk Identity Icons2.7 The `trunk/Identity/Icons' Directory
Filesystem trunk Identity Isolinux2.8 The `trunk/Identity/Isolinux' Directory
Filesystem trunk Identity Models2.9 The `trunk/Identity/Models' Directory
Filesystem trunk Identity Models Css2.10 The `trunk/Identity/Models/Css' Directory
Filesystem trunk Identity Models Html2.11 The `trunk/Identity/Models/Html' Directory
Filesystem trunk Identity Models Img Promo Web2.12 The `trunk/Identity/Models/Img/Promo/Web' Directory
Filesystem trunk Identity Models Tpl2.13 The `trunk/Identity/Models/Tpl' Directory
Filesystem trunk Identity Models Tpl Brands2.14 The `trunk/Identity/Models/Tpl/Brands' Directory
Filesystem trunk Identity Models Tpl Promo Web2.15 The `trunk/Identity/Models/Tpl/Promo/Web' Directory
Filesystem trunk Identity Models Xcf2.16 The `trunk/Identity/Models/Xcf' Directory
Filesystem trunk Identity Release2.17 The `trunk/Identity/Release' Directory
Filesystem trunk Identity Themes2.18 The `trunk/Identity/Themes' Directory
Filesystem trunk Identity Themes Models2.19 The `trunk/Identity/Themes/Models' Directory
Filesystem trunk Identity Themes Models Alternative2.20 The `trunk/Identity/Themes/Models/Alternative' Directory
Filesystem trunk Identity Themes Models Default2.21 The `trunk/Identity/Themes/Models/Default' Directory
Filesystem trunk Identity Themes Models Default Concept2.22 The `trunk/Identity/Themes/Models/Default/Concept' Directory
Filesystem trunk Identity Themes Models Default Distro2.23 The `trunk/Identity/Themes/Models/Default/Distro' Directory
Filesystem trunk Identity Themes Models Default Distro Anaconda2.24 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory
Filesystem trunk Identity Themes Models Default Distro Firstboot2.25 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory
Filesystem trunk Identity Themes Models Default Distro Gdm2.26 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory
Filesystem trunk Identity Themes Models Default Distro Grub2.27 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory
Filesystem trunk Identity Themes Models Default Distro Gsplash2.28 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory
Filesystem trunk Identity Themes Models Default Distro Kdm2.29 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory
Filesystem trunk Identity Themes Models Default Distro Ksplash2.30 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory
Filesystem trunk Identity Themes Models Default Distro Rhgb2.31 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory
Filesystem trunk Identity Themes Models Default Distro Syslinux2.32 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory
Filesystem trunk Identity Themes Models Default Promo2.33 The `trunk/Identity/Themes/Models/Default/Promo' Directory
Filesystem trunk Identity Themes Models Default Web2.34 The `trunk/Identity/Themes/Models/Default/Web' Directory
Filesystem trunk Identity Themes Motifs2.35 The `trunk/Identity/Themes/Motifs' Directory
Filesystem trunk Identity Themes Motifs Flame2.36 The `trunk/Identity/Themes/Motifs/Flame' Directory
Filesystem trunk Identity Themes Motifs Modern2.37 The `trunk/Identity/Themes/Motifs/Modern' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds2.38 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Img2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Tpl2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory
Filesystem trunk Identity Themes Motifs Modern Backgrounds Xcf2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory
Filesystem trunk Identity Themes Motifs Modern Distro Anaconda Progress2.42 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory
Filesystem trunk Identity Themes Motifs Modern Palettes2.43 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory
Filesystem trunk Identity Themes Motifs TreeFlower2.44 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory
Filesystem trunk Identity Themes Motifs TreeFlower Backgrounds2.45 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory
Filesystem trunk Identity Widgets2.46 The `trunk/Identity/Widgets' Directory
Filesystem trunk Locales2.47 The `trunk/Locales' Directory
Filesystem trunk Locales Identity2.48 The `trunk/Locales/Identity' Directory
Filesystem trunk Locales Identity Brands2.49 The `trunk/Locales/Identity/Brands' Directory
Filesystem trunk Locales Identity Brands Tpl2.50 The `trunk/Locales/Identity/Brands/Tpl' Directory
Filesystem trunk Locales Identity Fonts2.51 The `trunk/Locales/Identity/Fonts' Directory
Filesystem trunk Locales Identity Models2.52 The `trunk/Locales/Identity/Models' Directory
Filesystem trunk Locales Identity Release2.53 The `trunk/Locales/Identity/Release' Directory
Filesystem trunk Locales Identity Themes2.54 The `trunk/Locales/Identity/Themes' Directory
Filesystem trunk Locales Identity Themes Backgrounds2.55 The `trunk/Locales/Identity/Themes/Backgrounds' Directory
Filesystem trunk Locales Identity Themes Distro Anaconda Progress2.56 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory
Filesystem trunk Locales Identity Widgets2.57 The `trunk/Locales/Identity/Widgets' Directory
Filesystem trunk Manual2.58 The `trunk/Manual' Directory
Filesystem trunk Manuals2.59 The `trunk/Manuals' Directory
Filesystem trunk Scripts2.60 The `trunk/Scripts' Directory
Filesystem trunk Scripts Bash2.61 The `trunk/Scripts/Bash' Directory
Filesystem trunk Scripts Bash Cli2.62 The `trunk/Scripts/Bash/Cli' Directory
Filesystem trunk Scripts Bash Cli Functions2.63 The `trunk/Scripts/Bash/Cli/Functions' Directory
Filesystem trunk Scripts Bash Cli Functions Help2.64 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory
Filesystem trunk Scripts Bash Cli Functions Html2.65 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory
Filesystem trunk Scripts Bash Cli Functions Locale2.66 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory
Filesystem trunk Scripts Bash Cli Functions Manual2.67 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory
Filesystem trunk Scripts Bash Cli Functions Path2.68 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory
Filesystem trunk Scripts Bash Cli Functions Render2.69 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory
Filesystem trunk Scripts Bash Cli Functions Render Config2.70 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory
Filesystem trunk Scripts Bash Cli Functions Shell2.71 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory
Filesystem trunk Scripts Bash Cli Functions Svg2.72 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory
Filesystem trunk Scripts Bash Cli Functions Verify2.73 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory
Filesystem trunk Scripts Python2.74 The `trunk/Scripts/Python' Directory
 
H
How to render brands' translation files2.49.3 Usage
How to render fonts' translation files2.51.3 Usage
 
I
Introduction1. Introduction
 
M
Metadata maintainance2.72.2 Description
 
R
Repository file system2. Repository File System
 
T
Translation brands file names2.49.2.1 Conventional file names
Translation brands file names2.49.2.2 Numeric file names
 
U
Unused definitions2.72.2.1 Metadata maintainance
 

+
Jump to:   D
+   
+F
+   
+H
+   
+I
+   
+M
+   
+R
+   
+T
+   
+U
+   
+

 
 
 
-
-
+
+
-
+
-
+
[ < ][ > ]
[ < ][ > ]
    [ << ][ << ]
 [ Up ][ >> ][ >> ]
 

 

  
-  This document was generated on March, 6 2011 using texi2html 1.76.
+  This document was generated on March, 8 2011 using texi2html 1.76.
  
  

 
diff --git a/Manual/repository-html/repository_8.html b/Manual/repository-html/repository_8.html
index fce5b09..6997704 100644
--- a/Manual/repository-html/repository_8.html
+++ b/Manual/repository-html/repository_8.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
+
+
+
+CentOS Artwork Repository: List of Figures
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
[ < ][ > ]   [ << ][ Up ][ >> ]            [Top][Contents][Index][ ? ]

+
+
+
 List of Figures 

+

+
Figure 2.1
The functionalities initialization environment.
+

+
Figure 2.2
The actions initialization environment.
+

+
Figure 2.3
The cli_commitRepoChanges function output.
+

+
Figure 2.4
The functions script base comment structure
+

+
Figure 2.5
The function script comment example
+

+

+
+
+
+
+
+
+
+
+
+
[ < ][ > ]   [ << ][ Up ][ >> ]

+

+ 
+  This document was generated on March, 8 2011 using texi2html 1.76.
+ 
+ 

+
+

+
+
diff --git a/Manual/repository-html/repository_9.html b/Manual/repository-html/repository_9.html
index aff06b1..47b25f2 100644
--- a/Manual/repository-html/repository_9.html
+++ b/Manual/repository-html/repository_9.html
@@ -12,7 +12,7 @@ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
 copy of the license is included in the section entitled GNU Free
 Documentation License.  
 -->
-
+
 
-
+
 
-
+
 
-
+