Journal Lire de fichiers de configuration depuis un script shell

Posté par Michaël (site web personnel) le 05 juin 2015 à 15:13. Licence CC By‑SA.

Étiquettes :

juin

2015

La petite technique shell du vendredi. Pour lire un fichier de configuration du style INI depuis un script shell, on peut utiliser le petit script sed suivant

1 {
  x
  s/^/default/
  x
}

/^#/n

/^\[/ {
  s/\[\(.*\)\]/\1/
  x
  b
}

/=/ {
  s/^[[:space:]]*//
  s/[[:space:]]*=[[:space:]]*/|/
  G
  s/\(.*\)\n\(.*\)/\2|\1/
  p
}

Il transforme

    # last modified 1 April 2001 by John Doe
    [owner]
    name=John Doe
    organization=Acme Widgets Inc.

    [database]
    # use IP address in case network name resolution is not working
    server=192.0.2.62
    port=143
    file=payroll.dat

    owner|name|John Doe
    owner|organization|Acme Widgets Inc.
    database|server|192.0.2.62
    database|port|143
    database|file|payroll.dat

et ce deuxième format est facile à lire avec awk ou read par exemple.

Avec le shell l'approche classique consiste à sourcer un script contenant des définitions de variables, ce qui peut impliquer des trous de sécurité et n'offre pas beaucoup de possibilités de structuration.

Je le raconte (en pareil et en anglais) sur mon blog.

# sed, c'est dien !

Posté par Ramón Perez (site web personnel) le 05 juin 2015 à 15:21. Évalué à 10.
# Perl r0x

Posté par tfeserver tfe (site web personnel) le 05 juin 2015 à 16:23. Évalué à 10.

Petite version rapide en Perl:
perl -ne '/^\s*\[(.*?)]/ and $c=$1; /^\s*([^=]+)=(.*)/ and print "$c|$1|$2\n"; ' < fichier.ini
- [^] # Re: Perl r0x
  
  Posté par flan (site web personnel) le 06 juin 2015 à 10:09. Évalué à 3. Dernière modification le 06 juin 2015 à 10:09.
  
  Ça me donne surtout envie d'utiliser un autre langage :(
  - [^] # Re: Perl r0x
    
    Posté par Sytoka Modon (site web personnel) le 06 juin 2015 à 14:58. Évalué à 7.
    
    C'est franchement difficile d'être plus clair pourtant ! On a juste deux commandes, une qui pose le contexte, une qui fait la sortie. C'est juste une petite merveille.
    
    Il faut savoir être ouvert sur les autres tribus et reconnaître à chacun ses mérites ;-)
    - [^] # Re: Perl r0x
      
      Posté par flan (site web personnel) le 06 juin 2015 à 20:44. Évalué à 2.
      
      Honnêtement, je ne comprends rien à ce que ça fait, et pourtant j'ai fait un (tout petit) peu de Perl il y a quelques années. Là, je ne saurais même pas dire ce que ça donne en pratique.
      
      A contrario, j'ai déjà réussi à patcher du Ruby sans jamais en avoir fait.
      - [^] # Re: Perl r0x
        
        Posté par Sytoka Modon (site web personnel) le 07 juin 2015 à 21:45. Évalué à 6.
        
        Attention, c'est du one-liner, l'objectif est principalement ici d'écrire du code jetable et celui-ci est particulièrement lisible malgré ce que tu dis. Ceci dis, si tu n'y comprends rien, je pense qu'une petite plongée dans Perl ne peut alors que faire du bien histoire d'ouvrir de nouveau paradigme ;-) Bref, c'est une bête machine à état basée sur deux expressions rationnelles assez simples. Il y a pleins de one-liner incompréhensibles (c'est aussi un jeu) mais honnêtement, pas celle-là ;-)
  - [^] # Re: Perl r0x
    
    Posté par polux14 le 06 juin 2015 à 15:13. Évalué à 2.
    
    J'ai trop souvent l'impression que Perl est jugé sur ses variables explicites et l'intégration forte des expressions régulières (qui peuvent rendre le code peu lisible, certes).
    Mais pour faire une analogie douteuse, c'est un peu comme dire que le chinois c'est incompréhensible car ce n'est pas un alphabet latin.
    
    Petit patch:
    perl -ne '/^\s*\[(.*?)]/ and $c=$1; /^\s*([^=#]+)=(.*)/ and print "$c|$1|$2\n"; ' < fichier.ini
    - [^] # Re: Perl r0x
      
      Posté par anaseto le 06 juin 2015 à 21:15. Évalué à 8.
      
      J'ai trop souvent l'impression que Perl est jugé sur ses variables explicites et l'intégration forte des expressions régulières (qui peuvent rendre le code peu lisible, certes).
      
      Le truc amusant c'est que cette intégration rend, paradoxalement, les expressions régulières potentiellement bien plus lisibles : moins d'échappements à faire, possibilité de les écrire sur plusieurs lignes avec des commentaires et support possible de la part de l'éditeur de texte pour la coloration (vu que ce n'est pas juste des chaîne de caractères ordinaires), auxquels on peut ajouter le fait d'avoir certains messages d'erreurs dans des regex à la compilation et non à l'exécution.
      
      Je pense que Perl est plutôt généralement jugé sur la possibilité d'écrire des one-liner ou petits scripts très compacts, car c'est souvent la partie la plus visible pour celui qui ne connaît pas Perl, celle qu'il a le plus de chances de rencontrer en tombant sur un forum au hasard, et, malheureusement, c'est probablement une des disciplines qui montrent les parties les moins évidentes et implicites du langage. À côté, le code Perl d'un développement un peu plus gros est beaucoup plus accessible.

# Vraiment en shell

Posté par ymorin le 05 juin 2015 à 19:41. Évalué à 4.

Ou alors, en restant vraiment en shell (bash 4.0+):

#------------------------------------------------------------------------------
# Parses a .ini file
#
# License:
#   GPLv2
#
# Parse the specified .ini file, and stores the results in caller-supplied
# variable arrays:
#
# * +$sections[]+: indexed array
# * +$variables[]+: associative array
# * +$values[]+: associative array
# * +$lines[]+: associative array
#
# Those variables will be filled as thus:
#
#     sections=( [0]='section-0' [1]='section-1' )
#     variables=( ['section-0']='var-0,var-1' ['section-1']='var-10,var-11' [...] )
#     values=( ['section-0:var-0']='value-0-0' ['section-1:var-10']='value-1-10' [...] )
#     lines=( ['section-0']='file:27' ['section-1:var-10']='file:42' [...] )
#
# Note that the accepted syntax is a subset of the .ini format, where only
# '=' is accepted to assign variables, while ':' is not accepted.
#
# Param:
#   $1: .ini file to parse
#
# Return:
#   $sections[] : the list of sections, one section per array index
#   $variables[]: the comma-separated list of variables for a section,
#                 indexed by the name of the section
#   $values[]   : the value of a variable in a section, indexed by the
#                 'section:variable' tuple
#   $lines[]    : the 'file:line' a section or variable was defined on,
#                 indexed by the 'section' name, or the 'section:variable'
#                 tuple
#
parse_ini() {
    local ini_file="${1}"
    local line var val i
    local cur_section

    i=0
    while read line; do
        : $((i++))

        # Mangle the line:
        # - get rid of comments
        # - get rid of spaces around the first '='
        line="$( sed -r -e 's/[[:space:]]*#.*$//; //d;'                     \
                        -e 's/=/ = /;' -e 's/[[:space:]]+=[[:space:]]+/=/'  \
                        <<<"${line}" )"

        case "${line}" in
        "") continue;;
        '['*']')
            cur_section="$( sed -r -e 's/[][]//g;' <<<"${line}" )"
            sections+=( "${cur_section}" )
            lines+=( ["${cur_section}"]="${ini_file}:${i}" )
            continue
        ;;
        ?*=*)   ;;
        *)      printf "malformed entry '%s' in '%s:%d'\n" "${line}" "${ini_file}" ${i} >&2; return 1;;
        esac

        var="${line%%=*}"
        eval val="${line#*=}"
        variables+=( ["${cur_section}"]=",${var}" )
        values+=( ["${cur_section}:${var}"]="${val}" )
        lines+=( ["${cur_section}:${var}"]="${ini_file}:${i}" )
    done <"${ini_file}"
}

Hop,
Moi.

[^] # Re: Vraiment en shell

Posté par Sytoka Modon (site web personnel) le 05 juin 2015 à 22:43. Évalué à 5.

Si tu restes en pure bash, tu ne mets pas de $( ) … La première qu'on voit dans ton script sont les sous commandes sed ! Bref, la monoligne Perl est vraiment plus esthétique et rapide. Si tu veux des variables à la fin, à peine modifié, tu fait un eval de son résultat.
[^] # Re: Vraiment en shell

Posté par Michaël (site web personnel) le 08 juin 2015 à 21:57. Évalué à 2.

Ce n'est pas du bash pur car tu appelles une ou deux fois sed par ligne lue, et cela ne fait pas du tout la même chose car tu ne produis pas de donnée tabulaire. Remarque, je ne programme pas en bash car c'est tout plein de bugs — dès que le job control devient compliqué, cela fait des segfaults.

# pure bash et un peu long

Posté par bunam le 06 juin 2015 à 01:08. Évalué à -1.

j'ai utilisé

#
# Copyright (c) 2009    Kevin Porter / Advanced Web Construction Ltd
#                       (http://coding.tinternet.info, http://webutils.co.uk)
# Copyright (c) 2010-2012     Ruediger Meier <sweet_f_a@gmx.de>
#                             (https://github.com/rudimeier/)
#
# Simple INI file parser.
#
# See README for usage.
#
#

function read_ini()
{
    # Be strict with the prefix, since it's going to be run through eval
    function check_prefix()
    {
        if ! [[ "${VARNAME_PREFIX}" =~ ^[a-zA-Z_][a-zA-Z0-9_]*$ ]] ;then
            echo "read_ini: invalid prefix '${VARNAME_PREFIX}'" >&2
            return 1
        fi
    }

    function check_ini_file()
    {
        if [ ! -r "$INI_FILE" ] ;then
            echo "read_ini: '${INI_FILE}' doesn't exist or not" \
                "readable" >&2
            return 1
        fi
    }

    # enable some optional shell behavior (shopt)
    function pollute_bash()
    {
        if ! shopt -q extglob ;then
            SWITCH_SHOPT="${SWITCH_SHOPT} extglob"
        fi
        if ! shopt -q nocasematch ;then
            SWITCH_SHOPT="${SWITCH_SHOPT} nocasematch"
        fi
        shopt -q -s ${SWITCH_SHOPT}
    }

    # unset all local functions and restore shopt settings before returning
    # from read_ini()
    function cleanup_bash()
    {
        shopt -q -u ${SWITCH_SHOPT}
        unset -f check_prefix check_ini_file pollute_bash cleanup_bash
    }

    local INI_FILE=""
    local INI_SECTION=""

    # {{{ START Deal with command line args

    # Set defaults
    local BOOLEANS=1
    local VARNAME_PREFIX=INI
    local CLEAN_ENV=0

    # {{{ START Options

    # Available options:
    #   --boolean       Whether to recognise special boolean values: ie for 'yes', 'true'
    #                   and 'on' return 1; for 'no', 'false' and 'off' return 0. Quoted
    #                   values will be left as strings
    #                   Default: on
    #
    #   --prefix=STRING String to begin all returned variables with (followed by '__').
    #                   Default: INI
    #
    #   First non-option arg is filename, second is section name

    while [ $# -gt 0 ]
    do

        case $1 in

            --clean | -c )
                CLEAN_ENV=1
            ;;

            --booleans | -b )
                shift
                BOOLEANS=$1
            ;;

            --prefix | -p )
                shift
                VARNAME_PREFIX=$1
            ;;

            * )
                if [ -z "$INI_FILE" ]
                then
                    INI_FILE=$1
                else
                    if [ -z "$INI_SECTION" ]
                    then
                        INI_SECTION=$1
                    fi
                fi
            ;;

        esac

        shift
    done

    if [ -z "$INI_FILE" ] && [ "${CLEAN_ENV}" = 0 ] ;then
        echo -e "Usage: read_ini [-c] [-b 0| -b 1]] [-p PREFIX] FILE"\
            "[SECTION]\n  or   read_ini -c [-p PREFIX]" >&2
        cleanup_bash
        return 1
    fi

    if ! check_prefix ;then
        cleanup_bash
        return 1
    fi

    local INI_ALL_VARNAME="${VARNAME_PREFIX}__ALL_VARS"
    local INI_ALL_SECTION="${VARNAME_PREFIX}__ALL_SECTIONS"
    local INI_NUMSECTIONS_VARNAME="${VARNAME_PREFIX}__NUMSECTIONS"
    if [ "${CLEAN_ENV}" = 1 ] ;then
        eval unset "\$${INI_ALL_VARNAME}"
    fi
    unset ${INI_ALL_VARNAME}
    unset ${INI_ALL_SECTION}
    unset ${INI_NUMSECTIONS_VARNAME}

    if [ -z "$INI_FILE" ] ;then
        cleanup_bash
        return 0
    fi

    if ! check_ini_file ;then
        cleanup_bash
        return 1
    fi

    # Sanitise BOOLEANS - interpret "0" as 0, anything else as 1
    if [ "$BOOLEANS" != "0" ]
    then
        BOOLEANS=1
    fi


    # }}} END Options

    # }}} END Deal with command line args

    local LINE_NUM=0
    local SECTIONS_NUM=0
    local SECTION=""

    # IFS is used in "read" and we want to switch it within the loop
    local IFS=$' \t\n'
    local IFS_OLD="${IFS}"

    # we need some optional shell behavior (shopt) but want to restore
    # current settings before returning
    local SWITCH_SHOPT=""
    pollute_bash

    while read -r line || [ -n "$line" ]
    do

        ((LINE_NUM++))

        # Skip blank lines and comments
        if [ -z "$line" -o "${line:0:1}" = ";" -o "${line:0:1}" = "#" ]
        then
            continue
        fi

        # Section marker?
        if [[ "${line}" =~ ^\[[a-zA-Z0-9_]{1,}\]$ ]]
        then

            # Set SECTION var to name of section (strip [ and ] from section marker)
            SECTION="${line#[}"
            SECTION="${SECTION%]}"
            eval "${INI_ALL_SECTION}=\"\${${INI_ALL_SECTION}# } $SECTION\""
            ((SECTIONS_NUM++))

            continue
        fi

        # Are we getting only a specific section? And are we currently in it?
        if [ ! -z "$INI_SECTION" ]
        then
            if [ "$SECTION" != "$INI_SECTION" ]
            then
                continue
            fi
        fi

        # Valid var/value line? (check for variable name and then '=')
        if ! [[ "${line}" =~ ^[a-zA-Z0-9._]{1,}[[:space:]]*= ]]
        then
            echo "Error: Invalid line:" >&2
            echo " ${LINE_NUM}: $line" >&2
            cleanup_bash
            return 1
        fi


        # split line at "=" sign
        IFS="="
        read -r VAR VAL <<< "${line}"
        IFS="${IFS_OLD}"

        # delete spaces around the equal sign (using extglob)
        VAR="${VAR%%+([[:space:]])}"
        VAL="${VAL##+([[:space:]])}"
        VAR=$(echo $VAR)


        # Construct variable name:
        # ${VARNAME_PREFIX}__$SECTION__$VAR
        # Or if not in a section:
        # ${VARNAME_PREFIX}__$VAR
        # In both cases, full stops ('.') are replaced with underscores ('_')
        if [ -z "$SECTION" ]
        then
            VARNAME=${VARNAME_PREFIX}__${VAR//./_}
        else
            VARNAME=${VARNAME_PREFIX}__${SECTION}__${VAR//./_}
        fi
        eval "${INI_ALL_VARNAME}=\"\${${INI_ALL_VARNAME}# } ${VARNAME}\""

        if [[ "${VAL}" =~ ^\".*\"$  ]]
        then
            # remove existing double quotes
            VAL="${VAL##\"}"
            VAL="${VAL%%\"}"
        elif [[ "${VAL}" =~ ^\'.*\'$  ]]
        then
            # remove existing single quotes
            VAL="${VAL##\'}"
            VAL="${VAL%%\'}"
        elif [ "$BOOLEANS" = 1 ]
        then
            # Value is not enclosed in quotes
            # Booleans processing is switched on, check for special boolean
            # values and convert

            # here we compare case insensitive because
            # "shopt nocasematch"
            case "$VAL" in
                yes | true | on )
                    VAL=1
                ;;
                no | false | off )
                    VAL=0
                ;;
            esac
        fi


        # enclose the value in single quotes and escape any
        # single quotes and backslashes that may be in the value
        VAL="${VAL//\\/\\\\}"
        VAL="\$'${VAL//\'/\'}'"

        eval "$VARNAME=$VAL"
    done  <"${INI_FILE}"

    # return also the number of parsed sections
    eval "$INI_NUMSECTIONS_VARNAME=$SECTIONS_NUM"

    cleanup_bash
}

exemple :

read_ini "/etc/yum.conf" main --prefix "yum_config"
echo "--- Depuis le cache yum : ${yum_config__main__cachedir}"

[^] # Re: pure bash et un peu long

Posté par Sébastien Koechlin le 06 juin 2015 à 11:18. Évalué à 10.

Sérieusement, quasiment 300 lignes pour lire un fichier ini, traiter les quotes à la main, tripoter IFS et shopt; il n'y a vraiment pas de quoi être fier.

C'est un bel exemple de code complètement non maintenable. En prime chacun y va de sa copie sans jamais faire la moindre mise à jour histoire de variés les bugs d'un code à l'autre.
- [^] # Re: pure bash et un peu long
  
  Posté par kaliko (site web personnel) le 06 juin 2015 à 14:07. Évalué à 7. Dernière modification le 06 juin 2015 à 14:07.
  Quand un script shell dépasse les 100 lignes il est temps de basculer sur un vrai^Wautre langage.
  
  Par exemple en python:
```
import configparser
config = configparser.ConfigParser()
config.read('/etc/myinifile.cfg')
```
  Pourquoi réécrire du code pour traiter un format standard (ie INI files), c'est tout l'intérêt de passer par un standard, hériter du travail fait par d'autre sur le sujet.
  
  Cependant l'exercice reste intéressant pour la beauté du geste et l'exploration des possibilités du shell.
  Dans le cadre de scripting système dans un environnement pro ça me semble en effet une mauvaise idée de construire de trop gros script en pur shell.
  - [^] # Re: pure bash et un peu long
    
    Posté par Christophe B. (site web personnel) le 06 juin 2015 à 15:32. Évalué à 1.
    
    @!#$ devancé de plus d'une heure
    je salivais à l'avance d'étaler ma science python …
    
    me reste plus que la mauvaise foi unixienne de base :
    
    ouiiii maiiiiiis python va consommer 15 fois plus de RAM que le shell …
    
    Dans le cadre de scripting système dans un environnement pro ça me semble en effet une mauvaise idée de construire de trop gros script en pur shell.
    
    tu as raison mais le shell reste quand même la meilleure glue qui soit sous unix
    de plus sur certain OS difficile à écarter, comme AIX, python n'est installé en standard, même si c'est faisable facilement
    Sinon le couple shell + python c'est quand même le top pour les scripts complexes comme les "exits" de CFT par exemple.
  - [^] # Re: pure bash et un peu long
    
    Posté par Sytoka Modon (site web personnel) le 06 juin 2015 à 15:54. Évalué à 2.
    
    Tu veux juste dire que Python est un langage déclaratif qui a un certain de module bien fait ;-)
    use Config::Tiny; my $Config = Config::Tiny->read('/etc/myinifile.cfg');
  - [^] # Re: pure bash et un peu long
    
    Posté par Michaël (site web personnel) le 08 juin 2015 à 21:24. Évalué à 5.
    
    Dans le cadre de scripting système dans un environnement pro ça me semble en effet une mauvaise idée de construire de trop gros script en pur shell.
    
    Contrairement à plein de croyances, ce n'est pas si difficile d'écrire des programmes complexes, maintenables et relativement gros avec le shell. La clef c'est de ne pas utiliser le shell n'importe comment. En gros il faut éviter le plus possible de maintenir des données complexes dans le shell lui-même, le shell servant juste à lancer des programmes — plus spécifiquement, des filtres — qui vont effectuer les traitements. En général on part de fonctions “prototypes” et de “mockings” pour écrire très rapidement un prototype. Ensuite on étend le prototype et on peut remplacer les traitements trop complexes par des programmes autonomes. Évidemment, il s'agit de faire du bon gros traitement de données pas du tout interactif, pour les programmes interactifs, cette approche ne va pas du tout!
- [^] # Re: pure bash et un peu long
  
  Posté par bunam le 07 juin 2015 à 00:09. Évalué à 1.
  
  Je pense être le seul à répondre au problème : shell et config type ini ;p
[^] # Re: pure bash et un peu long

Posté par barmic le 07 juin 2015 à 23:38. Évalué à 3.
On peut faire plus simple :
```
# Load var from INI files
function load() {
  for propertie in "$@" ; do
    [[ -f "${propertie}" ]] || die "load() : \"${propertie}\" don't exist !"
    while read ; do
      [[ "${REPLY}" =~ ^# || -z "${REPLY}" ]] && continue
      if [[ "${REPLY}" =~ ^\[.*\]$ ]] ; then
        c="${REPLY//[\[\]]/}"
      else
        eval "${c:-default}_${REPLY%%=*}"=\'"${REPLY#*=}"\'
      fi
    done < "${propertie}"
  done
}
```
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: pure bash et un peu long
  
  Posté par Benoît Sibaud (site web personnel) le 08 juin 2015 à 00:46. Évalué à 3.
  
  Petite correction d'ortho : property pas propertie. Il faudra aussi définir la fonction die.
  - [^] # Re: pure bash et un peu long
    
    Posté par barmic le 08 juin 2015 à 00:53. Évalué à 3.
    Voici la fonction die telle que je m'en sert généralement :
```
function die() {
  echo "$@" >&2
  exit 1
}
```
    Elle n'est AMHA pas nécessaire à comprendre la logique de la méthode.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: pure bash et un peu long
      
      Posté par Benoît Sibaud (site web personnel) le 08 juin 2015 à 09:43. Évalué à 3.
      Pour éviter ça :
      
      $ die "-e" "a\nb" a b
      
      je propose plutôt
      
      $ function die() { printf "%s\n" "$@" >&2; exit 1 } $ die "-e" "a\nb" -e a\nb
  - [^] # Re: pure bash et un peu long
    
    Posté par Michaël (site web personnel) le 08 juin 2015 à 21:44. Évalué à 2.
    C'est probablement does not exist ou doesn't exist. Mais au passage exist ça fait un peu vocabulaire mathématique et on utilise souvent plutôt no such … ou … not found — par exemple chez moi:
```
% ls /nonexistant
ls: /nonexistant: No such file or directory
```
[^] # Re: pure bash et un peu long

Posté par Michaël (site web personnel) le 08 juin 2015 à 21:34. Évalué à 2.
Mais ça ne fait pas du tout la même chose que le script sed puisque cela définit tout un tas de variables avec les valeurs assignées, du coup à moins de faire de l'introspection plutôt hasardeuse, tu ne peux pas itérer sur les valeurs définies mais seulement lire les valeurs que tu attends.

Avec le script sed on peut transformer un fichier INI comme la config de git en donnée tabulaire, du type
```
core|repositoryformatversion|0
core|filemode|true
core|bare|false
core|logallrefupdates|true
remote "origin"|url|git@github.com:michipili/anvil.git
remote "origin"|fetch|+refs/heads/*:refs/remotes/origin/*
branch "master"|remote|origin
branch "master"|merge|refs/heads/master
```
ce qui permet de sélectionner avec awk toutes les url de remotes par exemple.
- [^] # Re: pure bash et un peu long
  
  Posté par barmic le 08 juin 2015 à 22:47. Évalué à 3.
  
  Ton format csv est une plaie à utiliser en shell. On peut facilement modifier mon script pour créer des tableaux associatifs dont le nom correspond à la section et la clef le nom de la variable.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: pure bash et un peu long
    
    Posté par Michaël (site web personnel) le 09 juin 2015 à 09:00. Évalué à 2. Dernière modification le 09 juin 2015 à 09:00.
    
    Ton format csv est une plaie à utiliser en shell.
    
    On est régulièrement en désaccord là-dessus. Pour moi les données tabulaires sont à la base de la programmation en shell et je n'écris quasiment que des filtres qui lisent et écrivent des données tabulaires – et font parfois quelques traitement aussi! – bien-sûr cela demande de ne pas écrire de caractères NUL, de CR ou PIPE dans les champs, mais dans mon cas ce n'est pas une limitation.
    
    Je suis donc très content avec les données tabulaires. Quels sont les problèmes qu'elles te posent?
    - [^] # Re: pure bash et un peu long
      
      Posté par barmic le 09 juin 2015 à 10:12. Évalué à 3.
      
      Quels sont les problèmes qu'elles te posent?
      
      Ça se manipule bien avec des sed/grep/awk/perl, mais en shell c'est une infamie.
      
      Par contre de manière générale, le fait de s'en servir avec des filtres ça sert quand tu cherche à traiter le contenu du fichier INI, quand tu veut t'en servir comme d'une configuration, l'utilisation sous forme tabulaire n'est pas pratique (tu dois de toute manière déserialiser ton fichier).
      
      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
      - [^] # Re: pure bash et un peu long
        
        Posté par Michaël (site web personnel) le 09 juin 2015 à 10:23. Évalué à 2. Dernière modification le 09 juin 2015 à 10:24.
        
        Ça se manipule bien avec des sed/grep/awk/perl, mais en shell c'est une infamie
        
        Ma règle d'or de la programmation shell est de traiter aussi peu de données que possible avec le shell que je considère plutôt comme un outil de description des workflows qui transfère des données d'/un processus à l'autre, si possible sans regarder ce qu'il y a dedans.
        
        quand tu veut t'en servir comme d'une configuration, l'utilisation sous forme tabulaire n'est pas pratique (tu dois de toute manière déserialiser ton fichier).
        
        Ça dépend un peu des cas d'utilisation: s'il s'agit de lire une batterie de paramètres, je suis complètement d'accord avec toi, cependant si on a une collection de valeurs a priori inconnue (du style git qui a des paramètres pour chaque branche, mais ne connaît pas a priori le nom des branches), alors une donnée tabulaire peut-être pertinente.
        
        On peut aussi traduire la donnée tabulaire en fichier contenant des affectations puis sourcer ce fichier, au lieu de faire ça “ligne à ligne” ce qui est forcément très bavard (code) et très lent.
        
        [^] # Re: pure bash et un peu long
        
        Posté par barmic le 09 juin 2015 à 11:48. Évalué à 3.
        
        Ma règle d'or de la programmation shell est de traiter aussi peu de données que possible avec le shell
        
        C'est toi que ça regarde.
        
        que je considère plutôt comme un outil de description des workflows qui transfère des données d'/un processus à l'autre, si possible sans regarder ce qu'il y a dedans.
        
        Pour utiliser différents outils de workflow (ou affilié) le shell est assez mauvais pour ça (utiliser plus d'entrée et de sortie que ceux prévu en standard n'est pas très pratique, complexité de créer des routes avec plus d'une entrée et plus d'une sortie, aucun mécanisme de monitoring de ce que se passe, difficulté de debugage (beaucoup de monde écris cmd1|cmd2|cmd3 sans s'intéresser à gérer les erreurs de la commande cmd2, etc).
        
        Bref ce n'est AMHA pas parce qu'il fait des pipes que ça en fait un outil de description de workflow, ou du moins il a à peu près autant de défaut pour décrire des workflow que pour gérer des données.
        
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
        
        [^] # Re: pure bash et un peu long
        
        Posté par Michaël (site web personnel) le 09 juin 2015 à 12:14. Évalué à 3.
        
        C'est toi que ça regarde.
        
        Heu, je ne comprends pas trop le sens de cette discussion? J'explique pourquoi je n'ai pas de problème à traiter les données tabulaires avec le shell c'est tout simplement parceque je ne le fais pas – et ce, sciemment. C'est grave d'échanger des points de vue et des expériences?
        
        Pour utiliser différents outils de workflow (ou affilié) le shell est assez mauvais pour ça …
        
        Effectivement, pour les tâches complexes, je trouve le shell excellent pour écrire des prototypes – plutôt fragiles et lents, mais rapides à écrire.
        
        [^] # Re: pure bash et un peu long
        
        Posté par Michaël (site web personnel) le 09 juin 2015 à 14:35. Évalué à 2.
        
        Pour utiliser différents outils de workflow (ou affilié)
        
        Qu'est-ce que tu utilises dont tu es content? J'ai commencé à implémenter une bibliothèque en OCaml pour faire cela et j'aimerais bien regarder l'API d'autres solutions pour m'en inspirer.

# En bash, à la rache

Posté par kna le 08 juin 2015 à 15:40. Évalué à -1.
```
while read line ; do
    echo $line | grep -qE '^(#|$)' && continue
    if echo $line | grep -q '^\[.*\]$' ; then
        context=$(echo $line | tr -d '[]')
        continue
    fi
    echo -n "$context|"
    echo $line | sed 's/=/|/'
done < file.ini
```
- [^] # Re: En bash, à la rache
  
  Posté par Sytoka Modon (site web personnel) le 08 juin 2015 à 21:24. Évalué à 4.
  
  Enfin, bash + grep étendus + tr + sed…
- [^] # Re: En bash, à la rache
  
  Posté par Michaël (site web personnel) le 08 juin 2015 à 21:35. Évalué à 3.
  
  Quitte à lancer une instance de sed autant la laisser faire tout le travail, non?
# En python, c'est quand même plus simple

Posté par Dabowl_75 le 09 juin 2015 à 14:12. Évalué à 2.
Le fichier de config .ini :
```
[DB]
mysql.db='prout'
mysql.host='localhost'
mysql.user='lambda'
mysql.password='xxxxxxx'
[CONSOLE]
cons.port="12443"
cons.user="lambada"
cons.password="xxxxxx"
```
Le code pour parser le fichier et peupler des variables.
```
#!/usr/bin/python

import ConfigParser

def parseConfigFile(ini):

    config = ConfigParser.ConfigParser()
    try :
        fh = config.readfp(open(ini))
    except Exception as e:
        print str(e)
        raise SystemExit(1)

    ## Fetching parameters
    try :
            mysql_db = config.get('DB', 'mysql.db')
            mysql_user = config.get('DB', 'mysql.user')
            mysql_db = config.get('DB', 'mysql.password')
            cons_port = config.get('CONSOLE', 'cons.port')
            cons_user = config.get('CONSOLE', 'cons.user')
            cons_password = config.get('CONSOLE', 'cons.password')
    except Exception as e:
        print str(e)
        raise SystemExit(1)

parseConfigFile('cfig.ini')
```
- [^] # Re: En python, c'est quand même plus simple
  
  Posté par Sytoka Modon (site web personnel) le 09 juin 2015 à 21:55. Évalué à 0.
  
  Ah la vache, c'est caca boudin ! Deux try/except en aussi peu de ligne, aucune variable déclarée… C'est quoi ce langage de daube ;-)
  - [^] # Re: En python, c'est quand même plus simple
    
    Posté par Dabowl_75 le 10 juin 2015 à 09:17. Évalué à 2.
    
    Premier try/catch :
    
    il faut bien tester le cas où le fichier n'est pas accessible pour plein de raisons.
    
    Second try/catch :
    
    Il faut bien s'assurer que les variables dont le script a besoin pour fonctionner, sont bien présentes dans le fichier de config ini, et de surcroire dans la bonne section (ce qui valide la présence des sections).
    
    Au contraire, je trouve ça très simple et relativement concis puisqu'on vérifie quand même pas mal de choses en très peu de lignes.
    
    Il suffit de comparer avec les codes shell précédents….
    Alors ok je m'appuie sur une api, donc une partie du boulot et déjà fait, mais je ne vois pas l'intérêt de réinventer la roue.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.