From 78667f340ddaf8fe8c73a484ee943402c467d2f3 Mon Sep 17 00:00:00 2001 From: Alain Reguera Delgado Date: Jan 26 2011 16:05:59 +0000 Subject: Rename cli_getFromPath.sh to cli_getPathComponent.sh. To get _what_ from path? getFromPath name say very few about what the function does. On the other hand, getPathComponent looks a bit more descriptive. --- diff --git a/Scripts/Bash/Functions/cli_getFromPath.sh b/Scripts/Bash/Functions/cli_getFromPath.sh deleted file mode 100755 index bc9e2a4..0000000 --- a/Scripts/Bash/Functions/cli_getFromPath.sh +++ /dev/null @@ -1,223 +0,0 @@ -#!/bin/bash -# -# cli_getFromPath.sh -- This function outputs different parts from -# path string. By default the full release information is output. -# -# Copyright (C) 2009-2011 Alain Reguera Delgado -# -# 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 cli_getFromPath { - - local -a PATTERN - local LOCATION='' - local OPTION='' - - # Define location from which we retrive information. - if [[ "$#" -eq 1 ]];then - LOCATION="$ACTIONVAL" - OPTION="$1" - elif [[ "$#" -eq 2 ]];then - LOCATION="$1" - OPTION="$2" - else - cli_printMessage "cli_getFromPath: `gettext "Invalid arguments."`" 'AsErrorLine' - cli_printMessage "$(caller)" 'AsToKnowMoreLine' - fi - - # Define release pattern. - PATTERN[0]="(([[:digit:]]+)(\.([[:digit:]]+)){,1})" - - # Define architecture pattern. - PATTERN[1]="^.+/${PATTERN[0]}/(i386|x86_64)/.*$" - - # Define theme pattern for trunk, branches, and tags directory - # structures. - # - # trunk: - # ------ - # Themes are made of `Models' and `Motifs'. `Models' controls the - # `Motifs' characteristcs and it is not rendereable. On the other - # hand, `Motifs' controls the theme visual style and do is - # renderable. Since we only need to know the theme name when we - # render something, we take the `Motifs' directory structure as - # reference to find out the theme name we are producing images - # for. - # - # `Motifs' are organized by names, so when we say `a theme name' - # we are really saying `the artistic motif name of a theme', but - # for short `theme name' is used instead. `Models' are also - # organized by names, but we do never use model names to name a - # thame. We always say the `theme models' or `the models of the - # theme` to refere the theme component that controls the - # characteristics of artistic motifs. We never name a thame as its - # model. We use artistic motifs name for such purpose. - # - # Inside artistic motif names, we organize different versions of - # the same artistic motif by means of numerical worklines. - # Worklines, inside trunk, have an integer numerical form and - # begin at `1'. They increment one unit each time a new/fresh - # visual style ---for the same artistic motif--- is conceived. - # - # For example, the Flame theme uses the flame filter of Gimp to - # produce different fractal patterns randomly. We use the flame - # filter to produce different visual styles under the same theme - # since all patterns we produce are based on the same pattern - # (i.e., the random fractal pattern of Gimp's flame filter). This - # way, if you no longer want to produce visual styles from flame - # filter, it is time to create a new artistic motif name for it. - # - # This schema is very convenient for designers and packagers, - # since different designers can create their own worklines and go - # on with them until CentOS distribution release date is close. At - # that time, a workline is selected and tagged for packaging. - # Translators and programmers can continue working indepently, and - # without affection, in their own directory structures. - # - # Example: - # +------> theme name - # |-->| - # trunk/.../Themes/Motifs/Flame/1 - # trunk/.../Themes/Motifs/Flame/2 - # trunk/.../Themes/Motifs/Flame/3 - # | - # +----> theme release version - # - # Sometimes we only need to retrive the theme name, but othertimes - # both the theme name and its work-line is required as well. - # - # branches: - # --------- - # The branch development line is treated just as trunk development - # line does, but we rarely use it since it could be confusing to - # know whether a tag was created from trunk or branches. - # - # Conceive an enumeration schema in order to differentiate - # branches from trunk is not convenient either, it would introduce - # an intermediate point to the final production of tags we would - # need to be aware of. Instead of such configuration, we prefer - # to go straightforward from trunk to tags. - # - # Intermediate branches for quality assurance might be good in - # some situations, but not when we produce themes. We need a - # simple structure, where we could design, render content (using - # centos-art.sh), and release for testing (through tags). If - # something goes wrong in the released tag, it would be fixed in - # trunk and later released in another tagged relase. - # - # Of course, care should be taken to avoid making of trunk - # development line a chaotic place. Everbody should know exactly - # what they are doing therein. We need to design protections to - # isolate possible damages and that way, we could know exactly - # what and where we need to concentrate in and put our time on. - # - # In resume, do not use branches if you don't need to. Use trunk - # development line instead. - # - # tags: - # ----- - # The tag frozen line is mainly used to perform theme releases. - # - # Example: - # +------> theme name - # |-->| - # tags/.../Themes/Motifs/Flame/1.0 - # trunk/.../Themes/Motifs/Flame/1 |--> minor update - # |----> major udpate - # - # Tags have the format X.Z, where X is the first number in the - # name (e.g., `1') and represents the trunk/branches artistic - # motif version. The Z represents the second number in the name - # (e.g., `0') which is the tag version itself. - # - # Tag versions start at `0' and increment one unit each time a new - # tag is created from the same artistic motif version. When a new - # tag is created for the same artistic motif version, the first - # number in the tag name remains intact. The first number in the - # tag name only changes when we create a new tag for a new - # artistic motif version. - # - # Consider the following relations: - # - # trunk/.../Themes/Motifs/Flame/1 - # tags/.../Themes/Motifs/Flame/1.0 - # tags/.../Themes/Motifs/Flame/1.1 - # tags/.../Themes/Motifs/Flame/1.2 - # - # trunk/.../Themes/Motifs/Flame/2 - # tags/.../Themes/Motifs/Flame/2.0 - # tags/.../Themes/Motifs/Flame/2.1 - # tags/.../Themes/Motifs/Flame/2.2 - # - # trunk/.../Themes/Motifs/TreeFlower/1 - # ... - # and so on. - # - # Tag versions are created to release fixes and improvements, Tags - # are immutable (i.e., once tags are created, they shouldn't be - # modified.). - PATTERN[2]="^.+/Identity/Themes/Motifs/(([A-Za-z0-9]+)/${PATTERN[0]})/.+$" - - # Identify which part of the release we want to output. - case "$OPTION" in - - '--release' ) - echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\1!" - ;; - - '--release-major' ) - echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\2!" - ;; - - '--release-minor' ) - echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\4!" - ;; - - '--release-pattern' ) - echo "${PATTERN[0]}" - ;; - - '--architecture' ) - echo "$LOCATION" | sed -r "s!${PATTERN[1]}!\5!" - ;; - - '--architecture-pattern' ) - echo "${PATTERN[1]}" - ;; - - '--theme' ) - echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\1!" - ;; - - '--theme-name' ) - echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\2!" - ;; - - '--theme-release' ) - echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\3!" - ;; - - '--theme-pattern' ) - echo "${PATTERN[2]}" - ;; - - esac - -} diff --git a/Scripts/Bash/Functions/cli_getPathComponent.sh b/Scripts/Bash/Functions/cli_getPathComponent.sh new file mode 100755 index 0000000..5d715cc --- /dev/null +++ b/Scripts/Bash/Functions/cli_getPathComponent.sh @@ -0,0 +1,229 @@ +#!/bin/bash +# +# cli_getPathComponent.sh -- This function evaluates one repository +# path and output parts/components from it. Generally, the path +# information is passed to the function's first positional argument +# and the part/component we want to retrive is passed to the +# function's second positional argument. If second argument is not +# passed, then first argument is assumed to be the part/component we +# want to retrive, and action value (ACTIONVAL) variable is used +# instead as source path information. +# +# Copyright (C) 2009-2011 Alain Reguera Delgado +# +# 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 cli_getPathComponent { + + local -a PATTERN + local LOCATION='' + local OPTION='' + + # Define location which we retrive information from. + if [[ "$#" -eq 1 ]];then + LOCATION="$ACTIONVAL" + OPTION="$1" + elif [[ "$#" -eq 2 ]];then + LOCATION="$1" + OPTION="$2" + else + cli_printMessage "cli_getPathComponent: `gettext "Invalid arguments."`" 'AsErrorLine' + cli_printMessage "$(caller)" 'AsToKnowMoreLine' + fi + + # Define release pattern. + PATTERN[0]="(([[:digit:]]+)(\.([[:digit:]]+)){,1})" + + # Define architecture pattern. + PATTERN[1]="^.+/${PATTERN[0]}/(i386|x86_64)/.*$" + + # Define theme pattern for trunk, branches, and tags directory + # structures. + # + # trunk: + # ------ + # Themes are made of `Models' and `Motifs'. `Models' controls the + # `Motifs' characteristcs and it is not rendereable. On the other + # hand, `Motifs' controls the theme visual style and do is + # renderable. Since we only need to know the theme name when we + # render something, we take the `Motifs' directory structure as + # reference to find out the theme name we are producing images + # for. + # + # `Motifs' are organized by names, so when we say `a theme name' + # we are really saying `the artistic motif name of a theme', but + # for short `theme name' is used instead. `Models' are also + # organized by names, but we do never use model names to name a + # thame. We always say the `theme models' or `the models of the + # theme` to refere the theme component that controls the + # characteristics of artistic motifs. We never name a thame as its + # model. We use artistic motifs name for such purpose. + # + # Inside artistic motif names, we organize different versions of + # the same artistic motif by means of numerical worklines. + # Worklines, inside trunk, have an integer numerical form and + # begin at `1'. They increment one unit each time a new/fresh + # visual style ---for the same artistic motif--- is conceived. + # + # For example, the Flame theme uses the flame filter of Gimp to + # produce different fractal patterns randomly. We use the flame + # filter to produce different visual styles under the same theme + # since all patterns we produce are based on the same pattern + # (i.e., the random fractal pattern of Gimp's flame filter). This + # way, if you no longer want to produce visual styles from flame + # filter, it is time to create a new artistic motif name for it. + # + # This schema is very convenient for designers and packagers, + # since different designers can create their own worklines and go + # on with them until CentOS distribution release date is close. At + # that time, a workline is selected and tagged for packaging. + # Translators and programmers can continue working indepently, and + # without affection, in their own directory structures. + # + # Example: + # +------> theme name + # |-->| + # trunk/.../Themes/Motifs/Flame/1 + # trunk/.../Themes/Motifs/Flame/2 + # trunk/.../Themes/Motifs/Flame/3 + # | + # +----> theme release version + # + # Sometimes we only need to retrive the theme name, but othertimes + # both the theme name and its work-line is required as well. + # + # branches: + # --------- + # The branch development line is treated just as trunk development + # line does, but we rarely use it since it could be confusing to + # know whether a tag was created from trunk or branches. + # + # Conceive an enumeration schema in order to differentiate + # branches from trunk is not convenient either, it would introduce + # an intermediate point to the final production of tags we would + # need to be aware of. Instead of such configuration, we prefer + # to go straightforward from trunk to tags. + # + # Intermediate branches for quality assurance might be good in + # some situations, but not when we produce themes. We need a + # simple structure, where we could design, render content (using + # centos-art.sh), and release for testing (through tags). If + # something goes wrong in the released tag, it would be fixed in + # trunk and later released in another tagged relase. + # + # Of course, care should be taken to avoid making of trunk + # development line a chaotic place. Everbody should know exactly + # what they are doing therein. We need to design protections to + # isolate possible damages and that way, we could know exactly + # what and where we need to concentrate in and put our time on. + # + # In resume, do not use branches if you don't need to. Use trunk + # development line instead. + # + # tags: + # ----- + # The tag frozen line is mainly used to perform theme releases. + # + # Example: + # +------> theme name + # |-->| + # tags/.../Themes/Motifs/Flame/1.0 + # trunk/.../Themes/Motifs/Flame/1 |--> minor update + # |----> major udpate + # + # Tags have the format X.Z, where X is the first number in the + # name (e.g., `1') and represents the trunk/branches artistic + # motif version. The Z represents the second number in the name + # (e.g., `0') which is the tag version itself. + # + # Tag versions start at `0' and increment one unit each time a new + # tag is created from the same artistic motif version. When a new + # tag is created for the same artistic motif version, the first + # number in the tag name remains intact. The first number in the + # tag name only changes when we create a new tag for a new + # artistic motif version. + # + # Consider the following relations: + # + # trunk/.../Themes/Motifs/Flame/1 + # tags/.../Themes/Motifs/Flame/1.0 + # tags/.../Themes/Motifs/Flame/1.1 + # tags/.../Themes/Motifs/Flame/1.2 + # + # trunk/.../Themes/Motifs/Flame/2 + # tags/.../Themes/Motifs/Flame/2.0 + # tags/.../Themes/Motifs/Flame/2.1 + # tags/.../Themes/Motifs/Flame/2.2 + # + # trunk/.../Themes/Motifs/TreeFlower/1 + # ... + # and so on. + # + # Tag versions are created to release fixes and improvements, Tags + # are immutable (i.e., once tags are created, they shouldn't be + # modified.). + PATTERN[2]="^.+/Identity/Themes/Motifs/(([A-Za-z0-9]+)/${PATTERN[0]})/.+$" + + # Identify which part of the release we want to output. + case "$OPTION" in + + '--release' ) + echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\1!" + ;; + + '--release-major' ) + echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\2!" + ;; + + '--release-minor' ) + echo "$LOCATION" | sed -r "s!.+/${PATTERN[0]}/.*!\4!" + ;; + + '--release-pattern' ) + echo "${PATTERN[0]}" + ;; + + '--architecture' ) + echo "$LOCATION" | sed -r "s!${PATTERN[1]}!\5!" + ;; + + '--architecture-pattern' ) + echo "${PATTERN[1]}" + ;; + + '--theme' ) + echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\1!" + ;; + + '--theme-name' ) + echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\2!" + ;; + + '--theme-release' ) + echo "$LOCATION" | sed -r "s!${PATTERN[2]}!\3!" + ;; + + '--theme-pattern' ) + echo "${PATTERN[2]}" + ;; + + esac + +}