#!/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. Make it match the architectures the
    # CentOS distribution is able to be installed on.
    PATTERN[1]="(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]}!\1!"
            ;;
 
        '--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
 
}