From ed9de5f94f2262b5bab8f4af2ad4a309aa6afa21 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Mar 23 2011 02:51:53 +0000 Subject: Update documentation manual. --- diff --git a/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi b/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi index f457bc2..462961b 100644 --- a/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi +++ b/Manual/Directories/trunk/Identity/Themes/Motifs/Flame.texi @@ -17,7 +17,8 @@ to reduce the time used to produce new artistic motifs, because of its ``randomly generated'' nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the @file{centos-art.sh} script -(@pxref{Directories trunk Scripts Bash}) inside the CentOS Artwork Repository. +(@pxref{Directories trunk Scripts}) inside the CentOS Artwork +Repository. To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we diff --git a/Manual/Directories/trunk/Scripts.texi b/Manual/Directories/trunk/Scripts.texi index 3d12353..b6e024e 100644 --- a/Manual/Directories/trunk/Scripts.texi +++ b/Manual/Directories/trunk/Scripts.texi @@ -48,7 +48,7 @@ As convenction, the @file{centos-art.sh} command-line arguments have the following format: @verbatim -centos-art arg1 --arg2=val2 --arg3=val3 +centos-art function path/to/dir --options @end verbatim In the above example, @samp{centos-art} is the command you use to @@ -71,7 +71,7 @@ functionality can be loaded at one script execution I.e., you run +----------------------------------------------------------------------+ | [centos@host]$ centos-art function --action='value' --option='value' | +----------------------------------------------------------------------+ -| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh | +| ~/bin/centos-art --> ~/artwork/trunk/Scripts/centos-art.sh | +---v-----------------------------------------v------------------------+ | centos-art.sh | +---v---------------------------------v---+ @@ -105,36 +105,36 @@ variables and functions defined inside function environment. | cli_getFunctions | +---v------------------------------v---+ . | function1 | . -. +---v----------------------v---+ . -. . | function1_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function1_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . . +------------------------------+ . . | function2 | . -. +---v----------------------v---+ . -. . | function2_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function2_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . . +------------------------------+ . . | function3 | . -. +---v----------------------v---+ . -. . | function3_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function3_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . ........................................ @end verbatim @@ -151,7 +151,7 @@ Functions) ---). @menu * Directories trunk Scripts:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- -@comment --- Removed(* Directories trunk Scripts Bash Locale::) --- +@comment --- Removed(* Directories trunk Scripts Functions::) --- +@comment --- Removed(* Directories trunk Scripts Locale::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions.texi b/Manual/Directories/trunk/Scripts/Functions.texi index 8192afa..17fa889 100755 --- a/Manual/Directories/trunk/Scripts/Functions.texi +++ b/Manual/Directories/trunk/Scripts/Functions.texi @@ -1203,20 +1203,20 @@ The following specific functions of @file{centos-art.sh} script, are available for you to use: @menu -@comment --- Removed(* Directories trunk Scripts Bash Functions Html::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Locale::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Manual::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Path::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Render::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Render Config::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Shell::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Svg::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Verify::) --- +@comment --- Removed(* Directories trunk Scripts Functions Html::) --- +@comment --- Removed(* Directories trunk Scripts Functions Locale::) --- +@comment --- Removed(* Directories trunk Scripts Functions Manual::) --- +@comment --- Removed(* Directories trunk Scripts Functions Path::) --- +@comment --- Removed(* Directories trunk Scripts Functions Render::) --- +@comment --- Removed(* Directories trunk Scripts Functions Render Config::) --- +@comment --- Removed(* Directories trunk Scripts Functions Shell::) --- +@comment --- Removed(* Directories trunk Scripts Functions Svg::) --- +@comment --- Removed(* Directories trunk Scripts Functions Verify::) --- @end menu @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Locale::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Locale::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Path.texi b/Manual/Directories/trunk/Scripts/Functions/Path.texi index 78bee64..ec6ed9d 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Path.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Path.texi @@ -322,6 +322,6 @@ In this command, @file{SRC} is a working copy (WC) entry. @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Functions::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Render.texi b/Manual/Directories/trunk/Scripts/Functions/Render.texi index c03bf78..19a2717 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render.texi @@ -732,5 +732,5 @@ have been duplicated, the functionality stops thereat. @subsection See also @menu -@comment --- Removed(* Directories trunk Scripts Bash Functions Render Config::) --- +@comment --- Removed(* Directories trunk Scripts Functions Render Config::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi b/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi index c0fe2e1..06a0521 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Render/Config.texi @@ -186,7 +186,7 @@ directory path under @file{trunk/Identity} or @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- -@comment --- Removed(* Directories trunk Scripts Bash Functions Render::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Functions::) --- +@comment --- Removed(* Directories trunk Scripts Functions Render::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Shell.texi b/Manual/Directories/trunk/Scripts/Functions/Shell.texi index 395bf4a..4dd6571 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Shell.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Shell.texi @@ -179,6 +179,6 @@ list of files to process. @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Functions::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Svg.texi b/Manual/Directories/trunk/Scripts/Functions/Svg.texi index 12b4c7e..38847f5 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Svg.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Svg.texi @@ -187,6 +187,6 @@ list of files to process. @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Functions::) --- @end menu diff --git a/Manual/Directories/trunk/Scripts/Functions/Verify.texi b/Manual/Directories/trunk/Scripts/Functions/Verify.texi index e5e0eb4..ca4d1c5 100644 --- a/Manual/Directories/trunk/Scripts/Functions/Verify.texi +++ b/Manual/Directories/trunk/Scripts/Functions/Verify.texi @@ -240,6 +240,6 @@ provided at all. @subsection See also @menu -* Directories trunk Scripts Bash:: -@comment --- Removed(* Directories trunk Scripts Bash Functions::) --- +* Directories trunk Scripts:: +@comment --- Removed(* Directories trunk Scripts Functions::) --- @end menu diff --git a/Manual/Introduction/chapter-intro.texi b/Manual/Introduction/chapter-intro.texi index a6ab816..148c82f 100644 --- a/Manual/Introduction/chapter-intro.texi +++ b/Manual/Introduction/chapter-intro.texi @@ -1,13 +1,11 @@ -Welcome to @command{centos-art.sh} script manual. +Welcome to CentOS Artwork Repository Manual. -The @command{centos-art.sh} manual contains information on how to use -the @command{centos-art.sh} script to help you achieve high production -levels when you work on The CentOS Project Corporate Visual Identity -inside the CentOS Artwork Repository -(@url{https://projects.centos.org/svn/artwork/}). If you are looking -for a comprehensive, task-oriented guide for understanding how The -CentOS Project corporate visual identity is produced, this is the -manual for you. +The CentOS Artwork Repository Manual describes how The CentOS Project +Corporate Visual Identity is organized and produced inside the CentOS +Artwork Repository (@url{https://projects.centos.org/svn/artwork/}). +If you are looking for a comprehensive, task-oriented guide for +understanding how The CentOS Project Corporate Visual Identity is +produced, this is the manual for you. This manual discusses the following intermedite topics: @@ -26,10 +24,13 @@ related conceptual ideas it is based on. This manual uses Texinfo as base documentation system. The Texinfo documentation structure is controlled by the @code{help} functionality -of @command{centos-art.sh} script. +of @command{centos-art.sh} script. Through this functionality you can +create documentation sections for each directory structure inside the +repository and edit those already created, as well. @xref{Directories +trunk Scripts Functions Help}, for more information on how to use the +@command{help} functionality of @command{centos-art.sh} script. 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 find help. - diff --git a/Manual/repository-html/repository.html b/Manual/repository-html/repository.html index 4296dcb..40427a7 100644 --- a/Manual/repository-html/repository.html +++ b/Manual/repository-html/repository.html @@ -59,7 +59,7 @@ ul.toc {list-style: none} - +
[Top] [Contents][Index][Index] [ ? ]

CentOS Artwork Repository

@@ -81,9 +81,9 @@ Documentation License. 2. The Repository Directories   -Index   +Index   -List of Figures   +List of Figures   @@ -94,7 +94,7 @@ Documentation License. - +
[Top] [Contents][Index][Index] [ ? ]

diff --git a/Manual/repository-html/repository_1.html b/Manual/repository-html/repository_1.html index 371028e..e1c9b2d 100644 --- a/Manual/repository-html/repository_1.html +++ b/Manual/repository-html/repository_1.html @@ -67,23 +67,21 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ]

1. Introduction

-

Welcome to centos-art.sh script manual. +

Welcome to CentOS Artwork Repository Manual.

-

The centos-art.sh manual contains information on how to use -the centos-art.sh script to help you achieve high production -levels when you work on The CentOS Project Corporate Visual Identity -inside the CentOS Artwork Repository -(https://projects.centos.org/svn/artwork/). If you are looking -for a comprehensive, task-oriented guide for understanding how The -CentOS Project corporate visual identity is produced, this is the -manual for you. +

The CentOS Artwork Repository Manual describes how The CentOS Project +Corporate Visual Identity is organized and produced inside the CentOS +Artwork Repository (https://projects.centos.org/svn/artwork/). +If you are looking for a comprehensive, task-oriented guide for +understanding how The CentOS Project Corporate Visual Identity is +produced, this is the manual for you.

This manual discusses the following intermedite topics:

@@ -102,14 +100,16 @@ related conceptual ideas it is based on.

This manual uses Texinfo as base documentation system. The Texinfo documentation structure is controlled by the help functionality -of centos-art.sh script. +of centos-art.sh script. Through this functionality you can +create documentation sections for each directory structure inside the +repository and edit those already created, as well. See section The `trunk/Scripts/Functions/Help' Directory, for more information on how to use the +help functionality of centos-art.sh script.

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 (http://wiki.centos.org/Help) for a list of different places you can find help.

- diff --git a/Manual/repository-html/repository_10.html b/Manual/repository-html/repository_10.html index a7e83f6..6e3f375 100644 --- a/Manual/repository-html/repository_10.html +++ b/Manual/repository-html/repository_10.html @@ -60,14 +60,14 @@ ul.toc {list-style: none} - + - +
1.1 History  
  [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
@@ -117,7 +117,7 @@ image rendition, documenting directory structures, translating content, etc.). If you can't resist the idea of automating repeatable tasks, then take a look here.

-

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

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

Locales
@@ -156,7 +156,7 @@ sections described above.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_11.html b/Manual/repository-html/repository_11.html index 8fca8c8..1cd4a25 100644 --- a/Manual/repository-html/repository_11.html +++ b/Manual/repository-html/repository_11.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -250,7 +250,7 @@ the following command:

Warning

Warning

If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared it for using The CentOS Artwork Repository yet. -See section The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory, for more +See section The `trunk/Scripts/Functions/Verify' Directory, for more information.

@@ -298,7 +298,7 @@ Artwork Repository. Such descriptions have been added to just one single command, as fast as your machine can be able to handle it.

-

See section The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory, for more +

See section The `trunk/Scripts/Functions/Identity' Directory, for more information about the identity functionality of centos-art command-line interface.

@@ -320,7 +320,7 @@ ideas we've used as base to build The CentOS Artwork Repository.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_12.html b/Manual/repository-html/repository_12.html index d763a02..fb57d7c 100644 --- a/Manual/repository-html/repository_12.html +++ b/Manual/repository-html/repository_12.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_13.html b/Manual/repository-html/repository_13.html index 20249d8..0e1aaa2 100644 --- a/Manual/repository-html/repository_13.html +++ b/Manual/repository-html/repository_13.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_14.html b/Manual/repository-html/repository_14.html index c5797ec..4c59ad1 100644 --- a/Manual/repository-html/repository_14.html +++ b/Manual/repository-html/repository_14.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -168,7 +168,7 @@ improve this section with your reasons.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_15.html b/Manual/repository-html/repository_15.html index 8754e17..f08caab 100644 --- a/Manual/repository-html/repository_15.html +++ b/Manual/repository-html/repository_15.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_16.html b/Manual/repository-html/repository_16.html index 8b225ab..8a3acd0 100644 --- a/Manual/repository-html/repository_16.html +++ b/Manual/repository-html/repository_16.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_17.html b/Manual/repository-html/repository_17.html index 7507705..78c8585 100644 --- a/Manual/repository-html/repository_17.html +++ b/Manual/repository-html/repository_17.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -113,7 +113,7 @@ to build artworks.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_18.html b/Manual/repository-html/repository_18.html index 9d0ec44..46f3a62 100644 --- a/Manual/repository-html/repository_18.html +++ b/Manual/repository-html/repository_18.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -109,7 +109,7 @@ to HTML design models.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_19.html b/Manual/repository-html/repository_19.html index 54f6495..929e656 100644 --- a/Manual/repository-html/repository_19.html +++ b/Manual/repository-html/repository_19.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_2.html b/Manual/repository-html/repository_2.html index 9b20412..ca40879 100644 --- a/Manual/repository-html/repository_2.html +++ b/Manual/repository-html/repository_2.html @@ -67,7 +67,7 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ] diff --git a/Manual/repository-html/repository_20.html b/Manual/repository-html/repository_20.html index 7db34f1..4a558d9 100644 --- a/Manual/repository-html/repository_20.html +++ b/Manual/repository-html/repository_20.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -114,7 +114,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_21.html b/Manual/repository-html/repository_21.html index b6f78b0..a9c0bb7 100644 --- a/Manual/repository-html/repository_21.html +++ b/Manual/repository-html/repository_21.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_22.html b/Manual/repository-html/repository_22.html index 08aa1c5..078ada0 100644 --- a/Manual/repository-html/repository_22.html +++ b/Manual/repository-html/repository_22.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_23.html b/Manual/repository-html/repository_23.html index f1cb041..83f90c5 100644 --- a/Manual/repository-html/repository_23.html +++ b/Manual/repository-html/repository_23.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -418,7 +418,7 @@ CentOS [base] and CentOS [updates] repositories.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_24.html b/Manual/repository-html/repository_24.html index f0693ef..0371c3a 100644 --- a/Manual/repository-html/repository_24.html +++ b/Manual/repository-html/repository_24.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_25.html b/Manual/repository-html/repository_25.html index 7a213d0..9ed49d1 100644 --- a/Manual/repository-html/repository_25.html +++ b/Manual/repository-html/repository_25.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_26.html b/Manual/repository-html/repository_26.html index f9310ab..d7f88fa 100644 --- a/Manual/repository-html/repository_26.html +++ b/Manual/repository-html/repository_26.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -120,7 +120,7 @@ final CentOS themes. CentOS themes can be tagged as "Default" or   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_27.html b/Manual/repository-html/repository_27.html index accc6a3..4dbd81b 100644 --- a/Manual/repository-html/repository_27.html +++ b/Manual/repository-html/repository_27.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -116,7 +116,7 @@ a directory to the list. By default you have the `See section   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_28.html b/Manual/repository-html/repository_28.html index 918454c..08ff1be 100644 --- a/Manual/repository-html/repository_28.html +++ b/Manual/repository-html/repository_28.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -114,7 +114,7 @@ themes are maintained by CentOS Community.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_29.html b/Manual/repository-html/repository_29.html index ddb6704..2e5726c 100644 --- a/Manual/repository-html/repository_29.html +++ b/Manual/repository-html/repository_29.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -186,7 +186,7 @@ everyone which major release of CentOS Distribution is being used.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_3.html b/Manual/repository-html/repository_3.html index f9e3a36..485ec88 100644 --- a/Manual/repository-html/repository_3.html +++ b/Manual/repository-html/repository_3.html @@ -67,7 +67,7 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ] diff --git a/Manual/repository-html/repository_30.html b/Manual/repository-html/repository_30.html index 19dee98..e99c729 100644 --- a/Manual/repository-html/repository_30.html +++ b/Manual/repository-html/repository_30.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_31.html b/Manual/repository-html/repository_31.html index 6510f52..710918d 100644 --- a/Manual/repository-html/repository_31.html +++ b/Manual/repository-html/repository_31.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -200,7 +200,7 @@ documenting it or supporting it for whatever reason.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_32.html b/Manual/repository-html/repository_32.html index 3d62fc5..85c65a2 100644 --- a/Manual/repository-html/repository_32.html +++ b/Manual/repository-html/repository_32.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_33.html b/Manual/repository-html/repository_33.html index c2a3983..d517950 100644 --- a/Manual/repository-html/repository_33.html +++ b/Manual/repository-html/repository_33.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_34.html b/Manual/repository-html/repository_34.html index aa978ee..6fc390b 100644 --- a/Manual/repository-html/repository_34.html +++ b/Manual/repository-html/repository_34.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_35.html b/Manual/repository-html/repository_35.html index f910865..d9b2349 100644 --- a/Manual/repository-html/repository_35.html +++ b/Manual/repository-html/repository_35.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_36.html b/Manual/repository-html/repository_36.html index e26c3cc..d945b5f 100644 --- a/Manual/repository-html/repository_36.html +++ b/Manual/repository-html/repository_36.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_37.html b/Manual/repository-html/repository_37.html index b40cf60..42685a9 100644 --- a/Manual/repository-html/repository_37.html +++ b/Manual/repository-html/repository_37.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_38.html b/Manual/repository-html/repository_38.html index e59f5e9..d08db0c 100644 --- a/Manual/repository-html/repository_38.html +++ b/Manual/repository-html/repository_38.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_39.html b/Manual/repository-html/repository_39.html index ddd4344..22c5e34 100644 --- a/Manual/repository-html/repository_39.html +++ b/Manual/repository-html/repository_39.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_4.html b/Manual/repository-html/repository_4.html index e7c3dc7..4a41252 100644 --- a/Manual/repository-html/repository_4.html +++ b/Manual/repository-html/repository_4.html @@ -67,7 +67,7 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ] diff --git a/Manual/repository-html/repository_40.html b/Manual/repository-html/repository_40.html index dc3b95b..abd4ee7 100644 --- a/Manual/repository-html/repository_40.html +++ b/Manual/repository-html/repository_40.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_41.html b/Manual/repository-html/repository_41.html index e612338..d901b55 100644 --- a/Manual/repository-html/repository_41.html +++ b/Manual/repository-html/repository_41.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -115,7 +115,7 @@ examples of promotion designs.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_42.html b/Manual/repository-html/repository_42.html index 5606067..f3b8c33 100644 --- a/Manual/repository-html/repository_42.html +++ b/Manual/repository-html/repository_42.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -114,7 +114,7 @@ HTML standards should be consider here.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_43.html b/Manual/repository-html/repository_43.html index 748bee1..15b6470 100644 --- a/Manual/repository-html/repository_43.html +++ b/Manual/repository-html/repository_43.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -204,7 +204,7 @@ works are released under   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_44.html b/Manual/repository-html/repository_44.html index 50825ac..9220352 100644 --- a/Manual/repository-html/repository_44.html +++ b/Manual/repository-html/repository_44.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -97,7 +97,8 @@ to reduce the time used to produce new artistic motifs, because of its "randomly generated" nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the `centos-art.sh' script -(see section The `trunk/Scripts/Bash' Directory) inside the CentOS Artwork Repository. +(see section The `trunk/Scripts' Directory) inside the CentOS Artwork +Repository.

To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we @@ -305,7 +306,7 @@ variables you may face.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_45.html b/Manual/repository-html/repository_45.html index 4dfdd3f..c15cf92 100644 --- a/Manual/repository-html/repository_45.html +++ b/Manual/repository-html/repository_45.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_46.html b/Manual/repository-html/repository_46.html index 1936131..d1b5295 100644 --- a/Manual/repository-html/repository_46.html +++ b/Manual/repository-html/repository_46.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -219,7 +219,7 @@ organize the design process.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_47.html b/Manual/repository-html/repository_47.html index e56e7e4..7ef5adc 100644 --- a/Manual/repository-html/repository_47.html +++ b/Manual/repository-html/repository_47.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -107,7 +107,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_48.html b/Manual/repository-html/repository_48.html index e6f9b05..d765519 100644 --- a/Manual/repository-html/repository_48.html +++ b/Manual/repository-html/repository_48.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -106,7 +106,7 @@ command line interface.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_49.html b/Manual/repository-html/repository_49.html index 96b66a8..fa11ff4 100644 --- a/Manual/repository-html/repository_49.html +++ b/Manual/repository-html/repository_49.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -115,7 +115,7 @@ In this last case you need the `Xcf/' directory.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_5.html b/Manual/repository-html/repository_5.html index b92e34c..5f1a07c 100644 --- a/Manual/repository-html/repository_5.html +++ b/Manual/repository-html/repository_5.html @@ -67,7 +67,7 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ] diff --git a/Manual/repository-html/repository_50.html b/Manual/repository-html/repository_50.html index 27b1d14..4c6f207 100644 --- a/Manual/repository-html/repository_50.html +++ b/Manual/repository-html/repository_50.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -143,7 +143,7 @@ centos-art render --identity   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_51.html b/Manual/repository-html/repository_51.html index ec54b79..a188983 100644 --- a/Manual/repository-html/repository_51.html +++ b/Manual/repository-html/repository_51.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -108,7 +108,7 @@ required by theme.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_52.html b/Manual/repository-html/repository_52.html index 22f6d9c..ed34bcc 100644 --- a/Manual/repository-html/repository_52.html +++ b/Manual/repository-html/repository_52.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_53.html b/Manual/repository-html/repository_53.html index 19440ca..39b7f8a 100644 --- a/Manual/repository-html/repository_53.html +++ b/Manual/repository-html/repository_53.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -414,7 +414,7 @@ the following `syslinux.hex' file:   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_54.html b/Manual/repository-html/repository_54.html index 3f43641..7c7032d 100644 --- a/Manual/repository-html/repository_54.html +++ b/Manual/repository-html/repository_54.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -102,7 +102,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_55.html b/Manual/repository-html/repository_55.html index 7a74e33..b539ad3 100644 --- a/Manual/repository-html/repository_55.html +++ b/Manual/repository-html/repository_55.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -127,7 +127,7 @@ the file that contain the translation messages themselves. functionality of command-line interface.

-
2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory   +
2.65 The `trunk/Scripts/Functions/Locale' Directory  
@@ -139,7 +139,7 @@ functionality of command-line interface.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_56.html b/Manual/repository-html/repository_56.html index 590a202..1bfbee7 100644 --- a/Manual/repository-html/repository_56.html +++ b/Manual/repository-html/repository_56.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -114,7 +114,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_57.html b/Manual/repository-html/repository_57.html index 26b3b24..de3631f 100644 --- a/Manual/repository-html/repository_57.html +++ b/Manual/repository-html/repository_57.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -194,7 +194,7 @@ inside template translation files.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_58.html b/Manual/repository-html/repository_58.html index 5cd3509..580ab88 100644 --- a/Manual/repository-html/repository_58.html +++ b/Manual/repository-html/repository_58.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -98,7 +98,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_59.html b/Manual/repository-html/repository_59.html index 4d3f3c6..ab5a01e 100644 --- a/Manual/repository-html/repository_59.html +++ b/Manual/repository-html/repository_59.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -152,7 +152,7 @@ directory (`Tpl/'), nor translation rendering using   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_6.html b/Manual/repository-html/repository_6.html index ce76424..6cdbc72 100644 --- a/Manual/repository-html/repository_6.html +++ b/Manual/repository-html/repository_6.html @@ -67,7 +67,7 @@ ul.toc {list-style: none}   [Top] [Contents] -[Index] +[Index] [ ? ] diff --git a/Manual/repository-html/repository_60.html b/Manual/repository-html/repository_60.html index a18b31a..be028ec 100644 --- a/Manual/repository-html/repository_60.html +++ b/Manual/repository-html/repository_60.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -98,7 +98,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_61.html b/Manual/repository-html/repository_61.html index 8b1f5a5..f7c22fc 100644 --- a/Manual/repository-html/repository_61.html +++ b/Manual/repository-html/repository_61.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -98,7 +98,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_62.html b/Manual/repository-html/repository_62.html index 44ba287..836f2c2 100644 --- a/Manual/repository-html/repository_62.html +++ b/Manual/repository-html/repository_62.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -98,7 +98,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_63.html b/Manual/repository-html/repository_63.html index caa8376..e6115b0 100644 --- a/Manual/repository-html/repository_63.html +++ b/Manual/repository-html/repository_63.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_64.html b/Manual/repository-html/repository_64.html index dbd6cd0..6ab9c94 100644 --- a/Manual/repository-html/repository_64.html +++ b/Manual/repository-html/repository_64.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -178,7 +178,7 @@ documentation entry (-- Removed(pxref:trunk Translations) --).   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_65.html b/Manual/repository-html/repository_65.html index bc30451..dd897e2 100644 --- a/Manual/repository-html/repository_65.html +++ b/Manual/repository-html/repository_65.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_66.html b/Manual/repository-html/repository_66.html index 294ecf3..e18c482 100644 --- a/Manual/repository-html/repository_66.html +++ b/Manual/repository-html/repository_66.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -110,7 +110,7 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_67.html b/Manual/repository-html/repository_67.html index 2b3418d..3765e20 100644 --- a/Manual/repository-html/repository_67.html +++ b/Manual/repository-html/repository_67.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.60 The trunk/Manuals Directory +CentOS Artwork Repository: 2.60 The trunk/Scripts Directory - - + + @@ -60,48 +60,180 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] - + -

2.60 The `trunk/Manuals' Directory

+

2.60 The `trunk/Scripts' Directory

2.60.1 Goals

-
    -
  • ... -
- +

The `trunk/Scripts' directory exists to organize the trunk +development line of `centos-art.sh' automation script. The +`centos-art.sh' script standardizes tasks you need to do +frequently inside CentOS Artwork Repository. +

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 function path/to/dir --options
+
+

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/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_getArguments | .   .
+.   .   +---v--------------v-----+ .   .
+.   .   .   | action 1     |     . .   .
+.   .   .   | action 2     |     . .   .
+.   .   .   | action n     |     . .   .
+.   .   .   +--------------+     . .   .
+.   .   .......................... .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function2                    |   .
+.   +---v------------------------v-+   .
+.   .   | function2_getArguments | .   .
+.   .   +---v--------------v-----+ .   .
+.   .   .   | action 1     |     . .   .
+.   .   .   | action 2     |     . .   .
+.   .   .   | action n     |     . .   .
+.   .   .   +--------------+     . .   .
+.   .   .......................... .   .
+.   ................................   .
+.   +------------------------------+   .
+.   | function3                    |   .
+.   +---v------------------------v-+   .
+.   .   | function3_getArguments | .   .
+.   .   +---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.60 The `trunk/Scripts' Directory   +
+ @@ -110,7 +242,7 @@ ul.toc {list-style: none} - +
  [ << ] [ Up ][ >> ][ >> ]

diff --git a/Manual/repository-html/repository_68.html b/Manual/repository-html/repository_68.html index b439261..49a2df0 100644 --- a/Manual/repository-html/repository_68.html +++ b/Manual/repository-html/repository_68.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.61 The trunk/Scripts Directory +CentOS Artwork Repository: 2.61 The trunk/Scripts/Functions Directory - - + + @@ -60,60 +60,1291 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] - + -

2.61 The `trunk/Scripts' Directory

+

2.61 The `trunk/Scripts/Functions' Directory

2.61.1 Goals

-

The `trunk/Scripts' directory exists to: +

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

-
    -
  • Organize the "trunk" development line of automation scripts by -programming language. -
-

2.61.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.61.3 Usage

+ + +

2.61.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.61.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.61.3.3 Specific functions

+ +

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

+ + +

2.61.4 See also

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

diff --git a/Manual/repository-html/repository_69.html b/Manual/repository-html/repository_69.html index 5b7e15f..fd9cc73 100644 --- a/Manual/repository-html/repository_69.html +++ b/Manual/repository-html/repository_69.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.62 The trunk/Scripts/Bash Directory +CentOS Artwork Repository: 2.62 The trunk/Scripts/Functions/Help Directory - - + + @@ -55,193 +55,62 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.62 The `trunk/Scripts/Bash' Directory

+ + +

2.62 The `trunk/Scripts/Functions/Help' Directory

- +

2.62.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.62.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.62.3 Usage

-

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

+
    +
  • ... +
- + +

2.62.4 See also

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

diff --git a/Manual/repository-html/repository_7.html b/Manual/repository-html/repository_7.html index f45e72d..93fefca 100644 --- a/Manual/repository-html/repository_7.html +++ b/Manual/repository-html/repository_7.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -202,39 +202,31 @@ to explore: 2.59 The `trunk/Manual' Directory   -2.60 The `trunk/Manuals' Directory   +2.60 The `trunk/Scripts' Directory   -2.61 The `trunk/Scripts' Directory   +2.61 The `trunk/Scripts/Functions' Directory   -2.62 The `trunk/Scripts/Bash' Directory   +2.62 The `trunk/Scripts/Functions/Help' Directory   -2.63 The `trunk/Scripts/Bash/Cli' Directory   +2.63 The `trunk/Scripts/Functions/Html' Directory   -2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory   +2.64 The `trunk/Scripts/Functions/Identity' Directory   -2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory   +2.65 The `trunk/Scripts/Functions/Locale' Directory   -2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory   +2.66 The `trunk/Scripts/Functions/Manual' Directory   -2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory   +2.67 The `trunk/Scripts/Functions/Path' Directory   -2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory   +2.68 The `trunk/Scripts/Functions/Render' Directory   -2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory   +2.69 The `trunk/Scripts/Functions/Render/Config' Directory   -2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory   +2.70 The `trunk/Scripts/Functions/Shell' Directory   -2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory   +2.71 The `trunk/Scripts/Functions/Svg' Directory   -2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory   - -2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory   - -2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory   - -2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory   - -2.76 The `trunk/Scripts/Python' Directory   +2.72 The `trunk/Scripts/Functions/Verify' Directory   @@ -245,7 +237,7 @@ to explore:   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_70.html b/Manual/repository-html/repository_70.html index 65cd1c4..529c5a6 100644 --- a/Manual/repository-html/repository_70.html +++ b/Manual/repository-html/repository_70.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.63 The trunk/Scripts/Bash/Cli Directory +CentOS Artwork Repository: 2.63 The trunk/Scripts/Functions/Html Directory - - + + @@ -55,34 +55,62 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.63 The `trunk/Scripts/Functions/Html' Directory

+ + + +

2.63.1 Goals

+ +
    +
  • ... +
+ + + +

2.63.2 Description

+ +
    +
  • ... +
+ + + +

2.63.3 Usage

+ +
    +
  • ... +
+ + + +

2.63.4 See also

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

diff --git a/Manual/repository-html/repository_71.html b/Manual/repository-html/repository_71.html index 5a46579..ca738f8 100644 --- a/Manual/repository-html/repository_71.html +++ b/Manual/repository-html/repository_71.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.64 The trunk/Scripts/Bash/Cli/Functions Directory +CentOS Artwork Repository: 2.64 The trunk/Scripts/Functions/Identity Directory - - + + @@ -55,1296 +55,62 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.64 The `trunk/Scripts/Functions/Identity' Directory

- +

2.64.1 Goals

-

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

- - -

2.64.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"
+
+
 2.64.2 Description 

 
-}
-
-

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

- - -

2.64.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.64.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.64.3.3 Specific functions

- -

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

- - - +

2.64.4 See also

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

diff --git a/Manual/repository-html/repository_72.html b/Manual/repository-html/repository_72.html index 1549ec7..bb9bda7 100644 --- a/Manual/repository-html/repository_72.html +++ b/Manual/repository-html/repository_72.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.65 The trunk/Scripts/Bash/Cli/Functions/Help Directory +CentOS Artwork Repository: 2.65 The trunk/Scripts/Functions/Locale Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

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

- +

2.65.1 Goals

    @@ -83,34 +83,99 @@ ul.toc {list-style: none}
- +

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

+
    +
  • `trunk/Scripts/Bash/initFunctions.sh' +
  • `trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh' +
  • `trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh' +
+
  • ...
- +

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

diff --git a/Manual/repository-html/repository_73.html b/Manual/repository-html/repository_73.html index f9707dd..d9961ad 100644 --- a/Manual/repository-html/repository_73.html +++ b/Manual/repository-html/repository_73.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.66 The trunk/Scripts/Bash/Cli/Functions/Html Directory +CentOS Artwork Repository: 2.66 The trunk/Scripts/Functions/Manual Directory - - + + @@ -55,27 +55,27 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

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

- +

2.66.1 Goals

    @@ -83,7 +83,7 @@ ul.toc {list-style: none}
- +

2.66.2 Description

    @@ -91,7 +91,7 @@ ul.toc {list-style: none}
- +

2.66.3 Usage

    @@ -99,18 +99,18 @@ ul.toc {list-style: none}
- +

2.66.4 See also

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

diff --git a/Manual/repository-html/repository_74.html b/Manual/repository-html/repository_74.html index ab700ed..d42319b 100644 --- a/Manual/repository-html/repository_74.html +++ b/Manual/repository-html/repository_74.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.67 The trunk/Scripts/Bash/Cli/Functions/Identity Directory +CentOS Artwork Repository: 2.67 The trunk/Scripts/Functions/Path Directory - - + + @@ -55,62 +55,379 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.67 The `trunk/Scripts/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

+ +

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

+ +

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?

+ +

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' Directory   +
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

diff --git a/Manual/repository-html/repository_75.html b/Manual/repository-html/repository_75.html index a0a893c..d39d9a0 100644 --- a/Manual/repository-html/repository_75.html +++ b/Manual/repository-html/repository_75.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.68 The trunk/Scripts/Bash/Cli/Functions/Locale Directory +CentOS Artwork Repository: 2.68 The trunk/Scripts/Functions/Render Directory - - + + @@ -55,127 +55,763 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.68 The `trunk/Scripts/Functions/Render' 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 Goals

+ +

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.1 Design template without translation

- -

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

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.

-
    -
  • `trunk/Scripts/Bash/initFunctions.sh' -
  • `trunk/Scripts/Bash/Functions/Help/cli_localeMessages.sh' -
  • `trunk/Scripts/Bash/Functions/Help/cli_localeMessagesStatus.sh' -
+

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

+

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 rendition actions.
+    ACTIONS[0]='BASE:renderImage'
+
+}
+
+

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

+
+ + + +

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

+

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

+ +

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

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

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

+
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.68.4 See also

+ +

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

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

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

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

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

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

diff --git a/Manual/repository-html/repository_76.html b/Manual/repository-html/repository_76.html index 1abcffd..6bf4ef0 100644 --- a/Manual/repository-html/repository_76.html +++ b/Manual/repository-html/repository_76.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.69 The trunk/Scripts/Bash/Cli/Functions/Manual Directory +CentOS Artwork Repository: 2.69 The trunk/Scripts/Functions/Render/Config Directory - - + + @@ -55,62 +55,229 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

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

- +

2.69.1 Goals

-
    -
  • ... -
- +

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

- +

2.69.2 Description

-
    -
  • ... -
+

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

+ + +

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

+

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

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

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

+ + +

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

+ + +

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

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

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

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

-
    -
  • ... -
+

Use the following commands to administer both identity and translation +pre-rendering configuration scripts: +

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

Use this command to create `path/to/dir' related pre-rendering +configuration script. +

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

+
+
`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.69.4 See also

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

diff --git a/Manual/repository-html/repository_77.html b/Manual/repository-html/repository_77.html index ae4c750..1536644 100644 --- a/Manual/repository-html/repository_77.html +++ b/Manual/repository-html/repository_77.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.70 The trunk/Scripts/Bash/Cli/Functions/Path Directory +CentOS Artwork Repository: 2.70 The trunk/Scripts/Functions/Shell Directory - - + + @@ -55,379 +55,219 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.70 The `trunk/Scripts/Functions/Shell' Directory

- +

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

This section exists to organize files related to shell +functionality of `centos-art.sh' script.

- +

2.70.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.70.2.1 Repository layout

+

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

+

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

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

+

Relevant lines in the above structure are lines from 5 to 9. +Everything else in the file is left immutable. +

+

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

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

+

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

+

When shell functionality uses its own default values, the final +copyright note looks like the following: +

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

-

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

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.

- - -

2.70.2.2 Repository name convenctions

- -

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

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.

-

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

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.

-

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

Important

Important

The `centos-art.sh' script is released as:

+
GNU GENERAL PUBLIC LICENSE
+Version 2, June 1991
 
-
-
 2.70.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.
+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.

-

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.70.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.70.3 Usage

- -

2.70.2.5 Syncronizing path information

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

+
-

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

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.

-

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

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.

-

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

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.

-

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

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.

-

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.70.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.70.4 See also

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

diff --git a/Manual/repository-html/repository_78.html b/Manual/repository-html/repository_78.html index b7aee9b..939a918 100644 --- a/Manual/repository-html/repository_78.html +++ b/Manual/repository-html/repository_78.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.71 The trunk/Scripts/Bash/Cli/Functions/Render Directory +CentOS Artwork Repository: 2.71 The trunk/Scripts/Functions/Svg Directory - - + + @@ -55,763 +55,251 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' 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.71.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.71.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: + + +

2.71 The `trunk/Scripts/Functions/Svg' Directory

+ + + +

2.71.1 Goals

+ +

This section exists to organize files related to svg +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. +

+

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:

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

-

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

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

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

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

-

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

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

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

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

-

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

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

-

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

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

-

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

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

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

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

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

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

-
function render_loadConfig {
-
-    # Define rendition actions.
-    ACTIONS[0]='BASE:renderImage'
-
-}
-
-

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

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

-

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

+
`Coverage'
+

Extent or scope of this document. If no value is set here, +`centos-art.sh' script uses the string `The CentOS Project'.

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

+
`Description'
+

Description about the document. If no value is set here, +`centos-art.sh' script uses uses empty value as default.

-

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

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

- - -

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

- -

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

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.

-
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.71.1.3 Design template with translation (optimized)

+ +

2.71.2.2 Unused definitions

-

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

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.

-

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

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.

-

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

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.

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

-
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.71.1.4 Design template with translation (optimized+flexibility)

+ +

2.71.3 Usage

-

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

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

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

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.

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

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

-

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

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.

- -

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

-

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 +

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.

-

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 +

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.

-

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

- -
    -
  • ... -
- - -

2.71.5 See also

+ +

2.71.4 See also

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

diff --git a/Manual/repository-html/repository_79.html b/Manual/repository-html/repository_79.html index ef03787..47f6b35 100644 --- a/Manual/repository-html/repository_79.html +++ b/Manual/repository-html/repository_79.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.72 The trunk/Scripts/Bash/Cli/Functions/Render/Config Directory +CentOS Artwork Repository: 2.72 The trunk/Scripts/Functions/Verify Directory - - + + @@ -55,229 +55,300 @@ ul.toc {list-style: none} - - + + - + - +
[ < ][ > ]
[ < ][ > ]   [ << ] [ Up ][ >> ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

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

+ + +

2.72 The `trunk/Scripts/Functions/Verify' Directory

- +

2.72.1 Goals

-

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

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

-

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

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.

-

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

- - -

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

-

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

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

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

- - -

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

- - -

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

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

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

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

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

-

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

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.

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

2.72.3 Usage

+ +

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

+ + +

2.72.2.3 Environment variables

-

Use the following commands to administer both identity and translation -pre-rendering configuration scripts: +

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:

-
`centos-art config --create='path/to/dir/''
+
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
-

Use this command to create `path/to/dir' related pre-rendering -configuration script. +

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

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

Use this command to edit `path/to/dir' related pre-rendering -configuration script. +

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

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

Use this command to read `path/to/dir' related pre-rendering -configuration script. +

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.

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

Use this command to remove `path/to/dir' related pre-rendering -configuration script. +

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

+ +

The format of TZ environment variable is described in +`tzset(3)' manual page.

-

In the commands above, `path/to/dir' refers to one renderable -directory path under `trunk/Identity' or -`trunk/Translations' structures only. + + +

2.72.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.72.4 See also

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

diff --git a/Manual/repository-html/repository_8.html b/Manual/repository-html/repository_8.html index ff7f3ea..0392d76 100644 --- a/Manual/repository-html/repository_8.html +++ b/Manual/repository-html/repository_8.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -113,7 +113,7 @@ structure for parallel development and later merging changes back to   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_80.html b/Manual/repository-html/repository_80.html index 67cc673..96e0f3d 100644 --- a/Manual/repository-html/repository_80.html +++ b/Manual/repository-html/repository_80.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.73 The trunk/Scripts/Bash/Cli/Functions/Shell Directory +CentOS Artwork Repository: Index - - + + @@ -55,219 +55,184 @@ ul.toc {list-style: none} - - + + - - + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory

- - - -

2.73.1 Goals

- -

This section exists to organize files related to shell -functionality of `centos-art.sh' script. -

- - -

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

-

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

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

-

Relevant lines in the above structure are lines from 5 to 9. -Everything else in the file is left immutable. -

-

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

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

-

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

-

When shell functionality uses its own default values, the final -copyright note looks like the following: -

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

-

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

-

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

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

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

- - - -

2.73.3 Usage

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

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

-

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.73.4 See also

- - - + + +

Index

+
2.62 The `trunk/Scripts/Bash' Directory   -
Jump to:   A +   +C +   +D +   +F +   +H +   +I +   +M +   +R +   +T +   +U +   +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Index Entry Section
A
Authors1.2 Authors
C
Copying conditions1.3 Copying Conditions
D
Directories branches2.1 The `branches' Directory
Directories tags2.2 The `tags' Directory
Directories trunk2.3 The `trunk' Directory
Directories trunk Identity2.4 The `trunk/Identity' Directory
Directories trunk Identity Brands2.5 The `trunk/Identity/Brands' Directory
Directories trunk Identity Colors2.6 The `trunk/Identity/Colors' Directory
Directories trunk Identity Fonts2.7 The `trunk/Identity/Fonts' Directory
Directories trunk Identity Icons2.8 The `trunk/Identity/Icons' Directory
Directories trunk Identity Isolinux2.9 The `trunk/Identity/Isolinux' Directory
Directories trunk Identity Models2.10 The `trunk/Identity/Models' Directory
Directories trunk Identity Models Css2.11 The `trunk/Identity/Models/Css' Directory
Directories trunk Identity Models Html2.12 The `trunk/Identity/Models/Html' Directory
Directories trunk Identity Models Img Promo Web2.13 The `trunk/Identity/Models/Img/Promo/Web' Directory
Directories trunk Identity Models Tpl2.14 The `trunk/Identity/Models/Tpl' Directory
Directories trunk Identity Models Tpl Brands2.15 The `trunk/Identity/Models/Tpl/Brands' Directory
Directories trunk Identity Models Tpl Promo Web2.16 The `trunk/Identity/Models/Tpl/Promo/Web' Directory
Directories trunk Identity Models Xcf2.17 The `trunk/Identity/Models/Xcf' Directory
Directories trunk Identity Release2.18 The `trunk/Identity/Release' Directory
Directories trunk Identity Themes2.19 The `trunk/Identity/Themes' Directory
Directories trunk Identity Themes Models2.20 The `trunk/Identity/Themes/Models' Directory
Directories trunk Identity Themes Models Alternative2.21 The `trunk/Identity/Themes/Models/Alternative' Directory
Directories trunk Identity Themes Models Default2.22 The `trunk/Identity/Themes/Models/Default' Directory
Directories trunk Identity Themes Models Default Concept2.23 The `trunk/Identity/Themes/Models/Default/Concept' Directory
Directories trunk Identity Themes Models Default Distro2.24 The `trunk/Identity/Themes/Models/Default/Distro' Directory
Directories trunk Identity Themes Models Default Distro Anaconda2.25 The `trunk/Identity/Themes/Models/Default/Distro/Anaconda' Directory
Directories trunk Identity Themes Models Default Distro Firstboot2.26 The `trunk/Identity/Themes/Models/Default/Distro/Firstboot' Directory
Directories trunk Identity Themes Models Default Distro Gdm2.27 The `trunk/Identity/Themes/Models/Default/Distro/Gdm' Directory
Directories trunk Identity Themes Models Default Distro Grub2.28 The `trunk/Identity/Themes/Models/Default/Distro/Grub' Directory
Directories trunk Identity Themes Models Default Distro Gsplash2.29 The `trunk/Identity/Themes/Models/Default/Distro/Gsplash' Directory
Directories trunk Identity Themes Models Default Distro Kdm2.30 The `trunk/Identity/Themes/Models/Default/Distro/Kdm' Directory
Directories trunk Identity Themes Models Default Distro Ksplash2.31 The `trunk/Identity/Themes/Models/Default/Distro/Ksplash' Directory
Directories trunk Identity Themes Models Default Distro Rhgb2.32 The `trunk/Identity/Themes/Models/Default/Distro/Rhgb' Directory
Directories trunk Identity Themes Models Default Distro Syslinux2.33 The `trunk/Identity/Themes/Models/Default/Distro/Syslinux' Directory
Directories trunk Identity Themes Models Default Promo2.34 The `trunk/Identity/Themes/Models/Default/Promo' Directory
Directories trunk Identity Themes Models Default Web2.35 The `trunk/Identity/Themes/Models/Default/Web' Directory
Directories trunk Identity Themes Motifs2.36 The `trunk/Identity/Themes/Motifs' Directory
Directories trunk Identity Themes Motifs Flame2.37 The `trunk/Identity/Themes/Motifs/Flame' Directory
Directories trunk Identity Themes Motifs Modern2.38 The `trunk/Identity/Themes/Motifs/Modern' Directory
Directories trunk Identity Themes Motifs Modern Backgrounds2.39 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds' Directory
Directories trunk Identity Themes Motifs Modern Backgrounds Img2.40 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Img' Directory
Directories trunk Identity Themes Motifs Modern Backgrounds Tpl2.41 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Tpl' Directory
Directories trunk Identity Themes Motifs Modern Backgrounds Xcf2.42 The `trunk/Identity/Themes/Motifs/Modern/Backgrounds/Xcf' Directory
Directories trunk Identity Themes Motifs Modern Distro Anaconda Progress2.43 The `trunk/Identity/Themes/Motifs/Modern/Distro/Anaconda/Progress' Directory
Directories trunk Identity Themes Motifs Modern Palettes2.44 The `trunk/Identity/Themes/Motifs/Modern/Palettes' Directory
Directories trunk Identity Themes Motifs TreeFlower2.45 The `trunk/Identity/Themes/Motifs/TreeFlower' Directory
Directories trunk Identity Themes Motifs TreeFlower Backgrounds2.46 The `trunk/Identity/Themes/Motifs/TreeFlower/Backgrounds' Directory
Directories trunk Identity Widgets2.47 The `trunk/Identity/Widgets' Directory
Directories trunk Locales2.48 The `trunk/Locales' Directory
Directories trunk Locales Identity2.49 The `trunk/Locales/Identity' Directory
Directories trunk Locales Identity Brands2.50 The `trunk/Locales/Identity/Brands' Directory
Directories trunk Locales Identity Brands Tpl2.51 The `trunk/Locales/Identity/Brands/Tpl' Directory
Directories trunk Locales Identity Fonts2.52 The `trunk/Locales/Identity/Fonts' Directory
Directories trunk Locales Identity Models2.53 The `trunk/Locales/Identity/Models' Directory
Directories trunk Locales Identity Release2.54 The `trunk/Locales/Identity/Release' Directory
Directories trunk Locales Identity Themes2.55 The `trunk/Locales/Identity/Themes' Directory
Directories trunk Locales Identity Themes Backgrounds2.56 The `trunk/Locales/Identity/Themes/Backgrounds' Directory
Directories trunk Locales Identity Themes Distro Anaconda Progress2.57 The `trunk/Locales/Identity/Themes/Distro/Anaconda/Progress' Directory
Directories trunk Locales Identity Widgets2.58 The `trunk/Locales/Identity/Widgets' Directory
Directories trunk Manual2.59 The `trunk/Manual' Directory
Directories trunk Scripts2.60 The `trunk/Scripts' Directory
Directories trunk Scripts Functions2.61 The `trunk/Scripts/Functions' Directory
Directories trunk Scripts Functions Help2.62 The `trunk/Scripts/Functions/Help' Directory
Directories trunk Scripts Functions Html2.63 The `trunk/Scripts/Functions/Html' Directory
Directories trunk Scripts Functions Identity2.64 The `trunk/Scripts/Functions/Identity' Directory
Directories trunk Scripts Functions Locale2.65 The `trunk/Scripts/Functions/Locale' Directory
Directories trunk Scripts Functions Manual2.66 The `trunk/Scripts/Functions/Manual' Directory
Directories trunk Scripts Functions Path2.67 The `trunk/Scripts/Functions/Path' Directory
Directories trunk Scripts Functions Render2.68 The `trunk/Scripts/Functions/Render' Directory
Directories trunk Scripts Functions Render Config2.69 The `trunk/Scripts/Functions/Render/Config' Directory
Directories trunk Scripts Functions Shell2.70 The `trunk/Scripts/Functions/Shell' Directory
Directories trunk Scripts Functions Svg2.71 The `trunk/Scripts/Functions/Svg' Directory
Directories trunk Scripts Functions Verify2.72 The `trunk/Scripts/Functions/Verify' Directory
Document convenctions1.4 Document Convenctions
F
Feedback1.5 Send in Your Feedback
H
History1.1 History
How to render brands' translation files2.50.3 Usage
How to render fonts' translation files2.52.3 Usage
I
Introduction1. Introduction
M
Metadata maintainance2.71.2 Description
R
Repository directories2. The Repository Directories
T
Translation brands file names2.50.2.1 Conventional file names
Translation brands file names2.50.2.2 Numeric file names
U
Unused definitions2.71.2.1 Metadata maintainance
+
Jump to:   A +   +C +   +D +   +F +   +H +   +I +   +M +   +R +   +T +   +U +   +
- - + + - - + +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ Up ][ >> ]

diff --git a/Manual/repository-html/repository_81.html b/Manual/repository-html/repository_81.html index e99ad2f..1cf8369 100644 --- a/Manual/repository-html/repository_81.html +++ b/Manual/repository-html/repository_81.html @@ -23,10 +23,10 @@ Send bugs and suggestions to --> -CentOS Artwork Repository: 2.74 The trunk/Scripts/Bash/Cli/Functions/Svg Directory +CentOS Artwork Repository: List of Figures - - + + @@ -55,251 +55,45 @@ ul.toc {list-style: none} - - + + - - - + + + - +
[ < ][ > ]
[ < ][ > ]   [ << ][ Up ][ >> ][ << ][ Up ][ >> ]         [Top] [Contents][Index][Index] [ ? ]
- - -

2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory

- - - -

2.74.1 Goals

- -

This section exists to organize files related to svg -functionality of `centos-art.sh' script. -

- - -

2.74.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.74.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: -

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

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

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

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

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

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

-
-
`Coverage'
-

Extent or scope of this document. If no value is set here, -`centos-art.sh' script uses the string `The CentOS Project'. -

-
-
`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.74.2.2 Unused definitions

- -

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

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

-

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.74.4 See also

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

diff --git a/Manual/repository-html/repository_9.html b/Manual/repository-html/repository_9.html index d8d9cae..a84e3c2 100644 --- a/Manual/repository-html/repository_9.html +++ b/Manual/repository-html/repository_9.html @@ -60,14 +60,14 @@ ul.toc {list-style: none}   [ << ] [ Up ] -[ >> ] +[ >> ]         [Top] [Contents] -[Index] +[Index] [ ? ] @@ -114,7 +114,7 @@ structure.   [ << ] [ Up ] -[ >> ] +[ >> ]

diff --git a/Manual/repository-html/repository_abt.html b/Manual/repository-html/repository_abt.html index d83cc9b..d151b0e 100644 --- a/Manual/repository-html/repository_abt.html +++ b/Manual/repository-html/repository_abt.html @@ -58,7 +58,7 @@ ul.toc {list-style: none} - +
[Top] [Contents][Index][Index] [ ? ]

About This Document

@@ -166,7 +166,7 @@ ul.toc {list-style: none} - +
[Top] [Contents][Index][Index] [ ? ]

diff --git a/Manual/repository-html/repository_fot.html b/Manual/repository-html/repository_fot.html index 3d8652a..45a2491 100644 --- a/Manual/repository-html/repository_fot.html +++ b/Manual/repository-html/repository_fot.html @@ -58,7 +58,7 @@ ul.toc {list-style: none} - +
[Top] [Contents][Index][Index] [ ? ]

Footnotes

@@ -69,7 +69,7 @@ mailman-3.x.x release. - +
[Top] [Contents][Index][Index] [ ? ]

diff --git a/Manual/repository-html/repository_toc.html b/Manual/repository-html/repository_toc.html index 9697eb7..e2f4b93 100644 --- a/Manual/repository-html/repository_toc.html +++ b/Manual/repository-html/repository_toc.html @@ -58,7 +58,7 @@ ul.toc {list-style: none} - +
[Top] [Contents][Index][Index] [ ? ]

Table of Contents

@@ -522,164 +522,142 @@ ul.toc {list-style: none}
  • 2.59.3 Usage
  • 2.59.4 See also
    • -
  • 2.60 The `trunk/Manuals' Directory +
  • 2.60 The `trunk/Scripts' Directory
    • -
  • 2.61 The `trunk/Scripts' Directory +
  • 2.61 The `trunk/Scripts/Functions' Directory
    • -
  • 2.62 The `trunk/Scripts/Bash' Directory -
    • -
  • 2.63 The `trunk/Scripts/Bash/Cli' Directory
    • -
  • 2.64 The `trunk/Scripts/Bash/Cli/Functions' Directory -
    • -
  • 2.65 The `trunk/Scripts/Bash/Cli/Functions/Help' Directory +
  • 2.62 The `trunk/Scripts/Functions/Help' Directory
    • -
  • 2.66 The `trunk/Scripts/Bash/Cli/Functions/Html' Directory +
  • 2.63 The `trunk/Scripts/Functions/Html' Directory
    • -
  • 2.67 The `trunk/Scripts/Bash/Cli/Functions/Identity' Directory +
  • 2.64 The `trunk/Scripts/Functions/Identity' Directory
    • -
  • 2.68 The `trunk/Scripts/Bash/Cli/Functions/Locale' Directory +
  • 2.65 The `trunk/Scripts/Functions/Locale' Directory
    • -
  • 2.69 The `trunk/Scripts/Bash/Cli/Functions/Manual' Directory +
  • 2.66 The `trunk/Scripts/Functions/Manual' Directory
    • -
  • 2.70 The `trunk/Scripts/Bash/Cli/Functions/Path' Directory +
  • 2.67 The `trunk/Scripts/Functions/Path' Directory
    • -
  • 2.71 The `trunk/Scripts/Bash/Cli/Functions/Render' Directory +
  • 2.68 The `trunk/Scripts/Functions/Render' Directory
    • -
  • 2.72 The `trunk/Scripts/Bash/Cli/Functions/Render/Config' Directory +
  • 2.69 The `trunk/Scripts/Functions/Render/Config' Directory
    • -
  • 2.73 The `trunk/Scripts/Bash/Cli/Functions/Shell' Directory +
  • 2.70 The `trunk/Scripts/Functions/Shell' Directory
    • -
  • 2.74 The `trunk/Scripts/Bash/Cli/Functions/Svg' Directory +
  • 2.71 The `trunk/Scripts/Functions/Svg' Directory
    • -
  • 2.75 The `trunk/Scripts/Bash/Cli/Functions/Verify' Directory +
  • 2.72 The `trunk/Scripts/Functions/Verify' Directory
    • -
  • 2.76 The `trunk/Scripts/Python' Directory -
    • -
  • Index
    • -
  • List of Figures
    • +
  • Index
    • +
  • List of Figures
    • - +
    [Top] [Contents][Index][Index] [ ? ]

    diff --git a/Manual/repository.info.bz2 b/Manual/repository.info.bz2 index fad24c2..a2b03e3 100644 Binary files a/Manual/repository.info.bz2 and b/Manual/repository.info.bz2 differ diff --git a/Manual/repository.pdf b/Manual/repository.pdf index 88ecebe..ee246d0 100644 Binary files a/Manual/repository.pdf and b/Manual/repository.pdf differ diff --git a/Manual/repository.txt.bz2 b/Manual/repository.txt.bz2 index eb8139e..6f0ff26 100644 Binary files a/Manual/repository.txt.bz2 and b/Manual/repository.txt.bz2 differ diff --git a/Manual/repository.xml b/Manual/repository.xml index 60fac8d..d3e4aec 100644 --- a/Manual/repository.xml +++ b/Manual/repository.xml @@ -58,8 +58,8 @@ Top Introduction - IntroductionWelcome to centos-art.sh script manual. - The centos-art.sh manual contains information on how to use the centos-art.sh script to help you achieve high production levels when you work on The CentOS Project Corporate Visual Identity inside the CentOS Artwork Repository (https://projects.centos.org/svn/artwork/). If you are looking for a comprehensive, task-oriented guide for understanding how The CentOS Project corporate visual identity is produced, this is the manual for you. + IntroductionWelcome to CentOS Artwork Repository Manual. + The CentOS Artwork Repository Manual describes how The CentOS Project Corporate Visual Identity is organized and produced inside the CentOS Artwork Repository (https://projects.centos.org/svn/artwork/). If you are looking for a comprehensive, task-oriented guide for understanding how The CentOS Project Corporate Visual Identity is produced, this is the manual for you. This manual discusses the following intermedite topics: • @@ -74,7 +74,7 @@ This manual is organized in the same way of CentOS Artwork Repository directory structure. In the CentOS Artwork Repository we use directories to store conceptual ideas of The CentOS Project Corporate Visual Identity. For this manual sake, each directory in CentOS Artwork Repository has its own documentation section to describe the related conceptual ideas it is based on. - This manual uses Texinfo as base documentation system. The Texinfo documentation structure is controlled by the help functionality of centos-art.sh script. + This manual uses Texinfo as base documentation system. The Texinfo documentation structure is controlled by the help functionality of centos-art.sh script. Through this functionality you can create documentation sections for each directory structure inside the repository and edit those already created, as well. See Directories trunk Scripts Functions Help, for more information on how to use the help functionality of centos-art.sh script. 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 (http://wiki.centos.org/Help) for a list of different places you can find help.

    @@ -585,88 +585,68 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh - Directories trunk Manuals - Directories trunk Manuals - - - Directories trunk Scripts Directories trunk Scripts - Directories trunk Scripts Bash - Directories trunk Scripts Bash - - - - Directories trunk Scripts Bash Cli - Directories trunk Scripts Bash Cli - - - - Directories trunk Scripts Bash Cli Functions - Directories trunk Scripts Bash Cli Functions - - - - Directories trunk Scripts Bash Cli Functions Help - Directories trunk Scripts Bash Cli Functions Help + Directories trunk Scripts Functions + Directories trunk Scripts Functions - Directories trunk Scripts Bash Cli Functions Html - Directories trunk Scripts Bash Cli Functions Html + Directories trunk Scripts Functions Help + Directories trunk Scripts Functions Help - Directories trunk Scripts Bash Cli Functions Identity - Directories trunk Scripts Bash Cli Functions Identity + Directories trunk Scripts Functions Html + Directories trunk Scripts Functions Html - Directories trunk Scripts Bash Cli Functions Locale - Directories trunk Scripts Bash Cli Functions Locale + Directories trunk Scripts Functions Identity + Directories trunk Scripts Functions Identity - Directories trunk Scripts Bash Cli Functions Manual - Directories trunk Scripts Bash Cli Functions Manual + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Locale - Directories trunk Scripts Bash Cli Functions Path - Directories trunk Scripts Bash Cli Functions Path + Directories trunk Scripts Functions Manual + Directories trunk Scripts Functions Manual - Directories trunk Scripts Bash Cli Functions Render - Directories trunk Scripts Bash Cli Functions Render + Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Path - Directories trunk Scripts Bash Cli Functions Render Config - Directories trunk Scripts Bash Cli Functions Render Config + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Render - Directories trunk Scripts Bash Cli Functions Shell - Directories trunk Scripts Bash Cli Functions Shell + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Render Config - Directories trunk Scripts Bash Cli Functions Svg - Directories trunk Scripts Bash Cli Functions Svg + Directories trunk Scripts Functions Shell + Directories trunk Scripts Functions Shell - Directories trunk Scripts Bash Cli Functions Verify - Directories trunk Scripts Bash Cli Functions Verify + Directories trunk Scripts Functions Svg + Directories trunk Scripts Functions Svg - Directories trunk Scripts Python - Directories trunk Scripts Python + Directories trunk Scripts Functions Verify + Directories trunk Scripts Functions Verify @@ -915,12 +895,12 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh centos-art render trunk/Identity/Path/To/Dir ]]> - Warning If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared it for using The CentOS Artwork Repository yet. See Directories trunk Scripts Bash Cli Functions Verify, for more information. + Warning If the centos-art command-line is not found in your workstation, it is probably because you haven't prepared it for using The CentOS Artwork Repository yet. See Directories trunk Scripts Functions Verify, for more information. This command takes one design template from the template directory and creates an instance of it in order to apply translation messages on it, if any. Later, using the design template instance, the command renders the final content based on whether the design template instance is a SVG file or a Docbook file. If the design template instace is a SVG file, the final content produced is a PNG image. On the other hand, if the design template instance is a Docbook file, the final content produced is a XHTML file. Final content is stored in the image directory using the design template directory paths as referece. The rendition flow described so far is known as the base-rendition flow. Besides the base-rendition flow, the centos-art provides the post-rendition and last-rendition flows. The post-rendition flow is applied to files produced as result of base-rendition flow under the same directory structure. For example, you can use post-rendition action to convert the PNG base output into different outputs (e.g., JPG, PDF, etc.) before passing to process the next file in the same directory structure. The last-rendition flow is applied to all files produced as result of both base-rendition and post-rendition flows in the same directory structure, just before passing to process a different directory structure. For example, the Preview.png image from Ksplash component is made of three images. In order to build the Preview.png image through centos-art we need to wait for all the three images the Preview.png image is made of to be rendered, so we can combine them all together into just one image (i.e., the Preview.png image). This is something we can't do using post-rendition flow. Inside trunk/Identity directory structure, you can find that base-rendition, post-rendition and last-rendition flows can be combined to build directory-specific rendition. The directory-specific rendition exists to automatically process specific renderable directories in very specific ways. Using directory-specific rendition speeds up production of different components like Syslinux, Grub, Gdm, Kdm and Ksplash that require intermediate formats or even several independent files, in order to reach its final construction. Directory-specific rendition is a way to programmatically describe how specific art works are built in and organized inside The CentOS Artwork Repository. Such descriptions have been added to centos-art command-line to let you produce them all with just one single command, as fast as your machine can be able to handle it. - See Directories trunk Scripts Bash Cli Functions Identity, for more information about the identity functionality of centos-art command-line interface. + See Directories trunk Scripts Functions Identity, for more information about the identity functionality of centos-art command-line interface. @@ -2706,7 +2686,7 @@ priority=10 Description The Flame artistic motif was built using the flame filter of Gimp 2.2 in CentOS 5.5. - The flame filter of Gimp can produce stunning, randomly generated fractal patterns. The flame filter of Gimp gives us a great oportunity to reduce the time used to produce new artistic motifs, because of its “randomly generated” nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the centos-art.sh script (see Directories trunk Scripts Bash) inside the CentOS Artwork Repository. + The flame filter of Gimp can produce stunning, randomly generated fractal patterns. The flame filter of Gimp gives us a great oportunity to reduce the time used to produce new artistic motifs, because of its “randomly generated” nature. Once the artistic motif be created, it is propagated through all visual manifestations of CentOS Project corporate visual identity using the centos-art.sh script (see Directories trunk Scripts) inside the CentOS Artwork Repository. To set the time intervals between each new visual style production, we could reuse the CentOS distribution major release schema. I.e., we could produce a new visual style, every two years, based on a new “randomly generated” flame pattern, and publish the whole corporate visual identity (i.e., distribution stuff, promotion stuff, websites stuff, etc.) with the new major release of CentOS distribution all together at once. Producing a new visual style is not one day's task. Once we have defined the artistic motif, we need to propagate it through all visual manifestations of The CentOS Project corporate visual identity. When we say that we could produce one new visual style every two years we really mean: to work two years long in order to propagate a new visual style to all visual manifestations of The CentOS Project corporate visual identity. Obviously, in order to propagate one visual style to all different visual manifestations of The CentOS Project corporate visual identity, we need first to know which the visual manifestations are. To define which visual manifestations are inside The CentOS Project corporate visual identity is one of the goals the CentOS Artwork Repository and this documentation manual are both aimed to satisfy. @@ -3421,8 +3401,8 @@ trunk/Identity/Themes/Motifs/TreeFlower/Colors/syslinux.hex Automation of localization tasks is achived through the locale functionality of command-line interface. - Directories trunk Scripts Bash Cli Functions Locale - Directories trunk Scripts Bash Cli Functions Locale + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Locale @@ -3930,7 +3910,7 @@ vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.se Directories trunk Manual - Directories trunk Manuals + Directories trunk Scripts Directories trunk Locales Identity Widgets Directories
    @@ -3974,107 +3954,16 @@ vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.se
    - Directories trunk Manuals - Directories trunk Scripts - Directories trunk Manual - Directories -
    - The <file>trunk/Manuals</file> Directory - Directories trunk Manuals - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - -
    -     - Directories trunk Scripts - Directories trunk Scripts Bash - Directories trunk Manuals + Directories trunk Scripts Functions + Directories trunk Manual Directories
    The <file>trunk/Scripts</file> Directory Directories trunk Scripts Goals - The trunk/Scripts directory exists to: - - • - - Organize the “trunk” development line of automation scripts by programming language. - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - - - -
    -     - - Directories trunk Scripts Bash - Directories trunk Scripts Bash Cli - Directories trunk Scripts - Directories -
    - The <file>trunk/Scripts/Bash</file> Directory - Directories trunk Scripts Bash - - 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 organize the trunk development line of centos-art.sh automation script. The centos-art.sh script standardizes tasks you need to do frequently inside CentOS Artwork Repository. @@ -4086,7 +3975,7 @@ vim /home/centos/artwork/trunk/Translations/Fonts/dejavu_lgc_sans-boldoblique.se 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: 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., , , , , etc.). The remaining arguments are modifiers to . The definition is required and represets, specifically, the action inside the functionality you want to perform. The 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. @@ -4097,7 +3986,7 @@ centos-art arg1 --arg2=val2 --arg3=val3 +----------------------------------------------------------------------+ | [centos@host]$ centos-art function --action='value' --option='value' | +----------------------------------------------------------------------+ -| ~/bin/centos-art --> ~/artwork/trunk/Scripts/Bash/centos-art.sh | +| ~/bin/centos-art --> ~/artwork/trunk/Scripts/centos-art.sh | +---v-----------------------------------------v------------------------+ | centos-art.sh | +---v---------------------------------v---+ @@ -4126,36 +4015,36 @@ centos-art arg1 --arg2=val2 --arg3=val3 | cli_getFunctions | +---v------------------------------v---+ . | function1 | . -. +---v----------------------v---+ . -. . | function1_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function1_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . . +------------------------------+ . . | function2 | . -. +---v----------------------v---+ . -. . | function2_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function2_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . . +------------------------------+ . . | function3 | . -. +---v----------------------v---+ . -. . | function3_getActions | . . -. . +---v--------------v---+ . . -. . . | action 1 | . . . -. . . | action 2 | . . . -. . . | action n | . . . -. . . +--------------+ . . . -. . ........................ . . +. +---v------------------------v-+ . +. . | function3_getArguments | . . +. . +---v--------------v-----+ . . +. . . | action 1 | . . . +. . . | action 2 | . . . +. . . | action n | . . . +. . . +--------------+ . . . +. . .......................... . . . ................................ . ........................................ ]]> @@ -4175,31 +4064,21 @@ centos-art arg1 --arg2=val2 --arg3=val3 Directories trunk Scripts Directories trunk Scripts - - + +
    - Directories trunk Scripts Bash Cli - Directories trunk Scripts Bash Cli Functions - Directories trunk Scripts Bash - Directories -
    - The <file>trunk/Scripts/Bash/Cli</file> Directory - Directories trunk Scripts Bash Cli -
    -     - - Directories trunk Scripts Bash Cli Functions - Directories trunk Scripts Bash Cli Functions Help - Directories trunk Scripts Bash Cli + Directories trunk Scripts Functions + Directories trunk Scripts Functions Help + Directories trunk Scripts Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions</file> Directory - Directories trunk Scripts Bash Cli Functions + The <file>trunk/Scripts/Functions</file> Directory + Directories trunk Scripts Functions Goals The trunk/Scripts/Bash/Functions directory exists to organize centos-art.sh specific functionalities. @@ -5143,15 +5022,15 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk Specific functions The following specific functions of centos-art.sh script, are available for you to use: - - - - - - - - - + + + + + + + + + @@ -5160,23 +5039,23 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - +
    - Directories trunk Scripts Bash Cli Functions Help - Directories trunk Scripts Bash Cli Functions Html - Directories trunk Scripts Bash Cli Functions + Directories trunk Scripts Functions Help + Directories trunk Scripts Functions Html + Directories trunk Scripts Functions Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Help</file> Directory - Directories trunk Scripts Bash Cli Functions Help + The <file>trunk/Scripts/Functions/Help</file> Directory + Directories trunk Scripts Functions Help Goals @@ -5215,13 +5094,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
    - Directories trunk Scripts Bash Cli Functions Html - Directories trunk Scripts Bash Cli Functions Identity - Directories trunk Scripts Bash Cli Functions Help + Directories trunk Scripts Functions Html + Directories trunk Scripts Functions Identity + Directories trunk Scripts Functions Help Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Html</file> Directory - Directories trunk Scripts Bash Cli Functions Html + The <file>trunk/Scripts/Functions/Html</file> Directory + Directories trunk Scripts Functions Html Goals @@ -5260,13 +5139,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
    - Directories trunk Scripts Bash Cli Functions Identity - Directories trunk Scripts Bash Cli Functions Locale - Directories trunk Scripts Bash Cli Functions Html + Directories trunk Scripts Functions Identity + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Html Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Identity</file> Directory - Directories trunk Scripts Bash Cli Functions Identity + The <file>trunk/Scripts/Functions/Identity</file> Directory + Directories trunk Scripts Functions Identity Goals @@ -5305,13 +5184,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
    - Directories trunk Scripts Bash Cli Functions Locale - Directories trunk Scripts Bash Cli Functions Manual - Directories trunk Scripts Bash Cli Functions Identity + Directories trunk Scripts Functions Locale + Directories trunk Scripts Functions Manual + Directories trunk Scripts Functions Identity Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Locale</file> Directory - Directories trunk Scripts Bash Cli Functions Locale + The <file>trunk/Scripts/Functions/Locale</file> Directory + Directories trunk Scripts Functions Locale Goals @@ -5379,13 +5258,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
    - Directories trunk Scripts Bash Cli Functions Manual - Directories trunk Scripts Bash Cli Functions Path - Directories trunk Scripts Bash Cli Functions Locale + Directories trunk Scripts Functions Manual + Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Locale Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Manual</file> Directory - Directories trunk Scripts Bash Cli Functions Manual + The <file>trunk/Scripts/Functions/Manual</file> Directory + Directories trunk Scripts Functions Manual Goals @@ -5424,13 +5303,13 @@ trunk/Scripts/Bash/Styles/output_forTwoColumns.awk
    - Directories trunk Scripts Bash Cli Functions Path - Directories trunk Scripts Bash Cli Functions Render - Directories trunk Scripts Bash Cli Functions Manual + Directories trunk Scripts Functions Path + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Manual Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Path</file> Directory - Directories trunk Scripts Bash Cli Functions Path + The <file>trunk/Scripts/Functions/Path</file> Directory + Directories trunk Scripts Functions Path 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. @@ -5537,23 +5416,23 @@ centos-art manual --read=turnk/Identity/Themes/Motifs/TreeFlower/ See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - +
    - Directories trunk Scripts Bash Cli Functions Render - Directories trunk Scripts Bash Cli Functions Render Config - Directories trunk Scripts Bash Cli Functions Path + Directories trunk Scripts Functions Render + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Path Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Render</file> Directory - Directories trunk Scripts Bash Cli Functions RenderThe render functionality exists to produce both identity and translation files on different levels of information (i.e., different languages, release numbers, architectures, etc.). + The <file>trunk/Scripts/Functions/Render</file> Directory + Directories trunk Scripts Functions RenderThe 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. @@ -5918,19 +5797,19 @@ function render_loadConfig { See also - +
    - Directories trunk Scripts Bash Cli Functions Render Config - Directories trunk Scripts Bash Cli Functions Shell - Directories trunk Scripts Bash Cli Functions Render + Directories trunk Scripts Functions Render Config + Directories trunk Scripts Functions Shell + Directories trunk Scripts Functions Render Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Render/Config</file> Directory - Directories trunk Scripts Bash Cli Functions Render Config + The <file>trunk/Scripts/Functions/Render/Config</file> Directory + Directories trunk Scripts Functions Render Config Goals The trunk/Scripts/Bash/Config directory exists to oraganize pre-rendering configuration scripts. @@ -6046,24 +5925,24 @@ ACTIONS[2]='LAST:groupByformat: png xpm jpg tif' See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - - + +
    - Directories trunk Scripts Bash Cli Functions Shell - Directories trunk Scripts Bash Cli Functions Svg - Directories trunk Scripts Bash Cli Functions Render Config + Directories trunk Scripts Functions Shell + Directories trunk Scripts Functions Svg + Directories trunk Scripts Functions Render Config Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Shell</file> Directory - Directories trunk Scripts Bash Cli Functions Shell + The <file>trunk/Scripts/Functions/Shell</file> Directory + Directories trunk Scripts Functions Shell Goals This section exists to organize files related to shell functionality of centos-art.sh script. @@ -6177,23 +6056,23 @@ Copyright (C) 1989, 1991 Free Software Foundation, Inc. See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - +
    - Directories trunk Scripts Bash Cli Functions Svg - Directories trunk Scripts Bash Cli Functions Verify - Directories trunk Scripts Bash Cli Functions Shell + Directories trunk Scripts Functions Svg + Directories trunk Scripts Functions Verify + Directories trunk Scripts Functions Shell Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Svg</file> Directory - Directories trunk Scripts Bash Cli Functions Svg + The <file>trunk/Scripts/Functions/Svg</file> Directory + Directories trunk Scripts Functions Svg Goals This section exists to organize files related to svg functionality of centos-art.sh script. @@ -6332,23 +6211,22 @@ Copyright (C) 1989, 1991 Free Software Foundation, Inc. See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - +
    - Directories trunk Scripts Bash Cli Functions Verify - Directories trunk Scripts Python - Directories trunk Scripts Bash Cli Functions Svg + Directories trunk Scripts Functions Verify + Directories trunk Scripts Functions Svg Directories
    - The <file>trunk/Scripts/Bash/Cli/Functions/Verify</file> Directory - Directories trunk Scripts Bash Cli Functions Verify + The <file>trunk/Scripts/Functions/Verify</file> Directory + Directories trunk Scripts Functions Verify 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. @@ -6472,56 +6350,12 @@ Copyright (C) 1989, 1991 Free Software Foundation, Inc. See also - Directories trunk Scripts Bash - Directories trunk Scripts Bash + Directories trunk Scripts + Directories trunk Scripts - + - -
    -     - - Directories trunk Scripts Python - Directories trunk Scripts Bash Cli Functions Verify - Directories -
    - The <file>trunk/Scripts/Python</file> Directory - Directories trunk Scripts Python - - Goals - - • - - ... - - - - - - Description - - • - - ... - - - - - - Usage - - • - - ... - - - - - - See also - -