Bonsoir,
Suite aux découvertes et aux investiguations de Riri, j'ai (enfin) effectué
les modifications dans Ncooker. Toutes les utilisations de l'opérateur =~
sont maintenant gérées comme Riri l'a suggeré.
J'en profite pour rappeler que tout le monde est invité à tester Ncooker.
C'est à la portée d'un linuxien de base. ;) Il vous suffit pour cela de
suivre le guide de test de Ncooker :
http://www.nasgaia.org/wiki/doku.php?id=tester_ncooker
A+
--
JulienL
From: "Richard Gill" <[EMAIL PROTECTED]>
Reply-To: Mailing list for dev purpose <[email protected]>
To: "Mailing list for dev purpose" <[email protected]>
Subject: Re: [Nasgaia-dev] Problème avec Ncooker
Date: Thu, 15 Mar 2007 19:01:17 +0100
Bon
après de moultes investigations, j'ai pu isoler le problème.
On avait pensé qu'il s'agissait du patch fourni par LFS pour bash,
mais en fait, après discussion sur la mailing list LFS:
* d'une part, ce patch n'est que l'accumulation des patchs officiels
de bash (bash32-001 à bash32-009)
* il existe un bash32-010 qui devrait régler ce problème
J'ai donc testé tout ça : sans patch, avec le patch LFS, avec le patch
LFS + le dernier de bash, tous les patchs de bash sans passer par le
raccourci LFS. Le résultat est toujours le même : un 'no match'. Mais
en y regardant de plus près, on remarque quelque chose:
test='check.sh install.sh wizard.sh'
regex=check
[[ $test =~ '^'$regex'.*' ]] || echo $?
-> 1
regex='^check.*' # juste pour tester une regex
[[ $test =~ "$regex" ]] || echo $?
-> 1
[[ $test =~ '^check.*' ]] || echo $?
-> 1
[[ $test =~ $regex ]] || echo $?
\o/ :-)
En fait le parser de bash a un problème s'il voir un quelconque ' ou "
dans la partie droite de l'expression. La solution que je préconise en
attendant une correction est donc de modifier notre code pour que
l'expression soit constituée avant le test.
Le 13/03/07, Richard Gill<[EMAIL PROTECTED]> a écrit :
C'est bien un problème du bash compilé dans le chroot. Les commandes:
toto="install.sh"
name=install
[[ "$toto" =~ "\<($name[^\.]*)\.sh" ]] || echo $?
ne renvoient rien sur mon système hôte (bash 3.1.17), donc le test a
réussi, alors que les même commandes renvoient 1 dans $? pour le bash
du chroot.
Comme je ne sais pas exactement d'où ça vient, je vais regarder
comment est compilé bash chez les autres (ubuntu, gentoo, etc..) pour
voir ce qu'il en est (il y a une option dans le configure, mais je
suis étonné que cela ne soit pas activé par défaut); je vais regarder
le log de compilation aussi, j'aurai peut-être une piste.
Le 13/03/07, Richard Gill<[EMAIL PROTECTED]> a écrit :
> Apparemment, c'est l'expression régulière ligne 241 de Ncooker qui
> pose problème :
>
> if [[ "$g_sCommands" =~ "\<($NC_COMMAND_NAME[^\.]*)\.sh" ]]
>
> le contenu de g_sCommands semble bon, et la partie droite est évaluée
en :
>
> \\\<\(\i\n\s\t\a\l\l\[\^\\\.\]\*\)\\\.\s\h
>
> avec donc un tout à :
>
> + [[ build.sh
> check.sh
> config.sh
> getpkg.sh
> install.sh
> pack.sh
> remove.sh
> wizard.sh =~ \\\<\(\i\n\s\t\a\l\l\[\^\\\.\]\*\)\\\.\s\h ]]
>
> Donc c'est =~ qui pose problème. Je vais vérifier s'il ne faut pas
> l'activer exlicitement dans le ./configure de bash pour l'avoir.
>
> --
> Richard 'riri' GILL
> jabber: [EMAIL PROTECTED]
> http://riri.houbathecat.info
> http://nasgaia.org
> http://www.gnurou.org/Writing/SmartQuestionsFr
>
--
Richard 'riri' GILL
jabber: [EMAIL PROTECTED]
http://riri.houbathecat.info
http://nasgaia.org
http://www.gnurou.org/Writing/SmartQuestionsFr
--
Richard 'riri' GILL
jabber: [EMAIL PROTECTED]
http://riri.houbathecat.info
http://nasgaia.org
http://www.gnurou.org/Writing/SmartQuestionsFr
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
_________________________________________________________________
Découvrez le Blog heroic Fantaisy d'Eragon!
http://eragon-heroic-fantasy.spaces.live.com/
_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev
