Calculer efficacement le nombre de champs d'une string

Bonjour.

Petit problème de débutant!

J'ai une chaîne 'un_champ:un_autre_champ:encore_un' qui contient, sur une seule ligne, des champs séparés par le séparateur ':'.
Je voudrais calculer le nombre de champs de cette chaîne.

J'ai bien la solution extrêmement simple avec awk:

Code:

---

1 2 3 4

typeset LISTE='un_champ:un_autre_champ:encore_un' typeset -i nf=$(print "${LISTE}" | awk -F ":" '{print NF}') print ${nf} 3

---

mais je la soupçonne d'être passablement coûteuse... surtout pour une petite chaîne!

ou la solution de suppression des autres caractères avec sed:

Code:

---

1 2 3 4 5

typeset LISTE='un_champ:un_autre_champ:encore_un' typeset lif=$(print "${LISTE}" | sed -e 's/[^:]//g') typeset -i nf=$((${#lif} + 1)) print ${nf} 3

---

ou

Code:

---

1 2 3 4

typeset LISTE='un_champ:un_autre_champ:encore_un' typeset -i nf=$(print "${LISTE}" | sed -e 's/[^:]//g' | wc -c) print ${nf} 3

---

Les spécialistes savent-ils quelle solution (parmi celles-ci ou d'autres, valables pour ksh) est la plus efficace?

Je n'ai pas tester ma commande mais ca doit etre un truc dansle genre :

Code:

---

wc -l $($(echo"tt:tt:tt" | cut -d":"))

---

Bonjour,

en bash :

Code:

---

1 2 3 4

$ string="un_champ:un_autre_champ:encore_un" $ nf="${string//[^:]/}" $ echo $((${#nf}+1)) 3

---

il n'y a pas de raisons que ça ne fonctionne pas avec ksh.

Merci d'avoir répondu!

Citation:

---

Envoyé par l4r3nZu

Je n'ai pas tester ma commande

---

Ah ben, oui, je confirme! ;)

Citation:

---

mais ca doit etre un truc dans le genre :

Code:

---

wc -l $($(echo"tt:tt:tt" | cut -d":"))

---

---

En fait, cut sert à extraire des champs, mais ne permet pas de les "séparer" par des returns!

Code:

---

1 2 3 4 5 6 7 8 9

# sous linux: echo $string | cut -d":" cut: you must specify a list of bytes, characters, or fields   # sous AIX: echo $string | cut -d":" Usage: cut -b List [-n] [File...] or: cut -c List [File...] or: cut -f List [-d Character] [-s] [File...]

---

Mais, du coup, ça me fait penser à une autre solution avec 'tr' et 2 pipes:

Code:

---

typeset -i nf=$(print "${string}" | tr ':' '\n' | wc -l)

---

Rq: le 'typeset -i' permet de supprimer le formatage introduit par wc sous AIX.

Merci d'avoir répondu.

Citation:

---

Envoyé par N_BaH

Bonjour,

en bash :

Code:

---

1 2 3 4

$ string="un_champ:un_autre_champ:encore_un" $ nf="${string//[^:]/}" $ echo $((${#nf}+1)) 3

---

il n'y a pas de raisons que ça ne fonctionne pas avec ksh.

---

C'est ce qu'on va voir... et c'est tout vu!

Code:

---

1 2 3 4 5 6 7

# Sous AIX $ nf="${string//[^:]/}" ksh: nf="${string//[^:]/}": 0403-011 The specified substitution is not valid for this command.   # Sous linux $ nf="${string//[^:]/}" ksh: : bad substitution

---

Mais, c'était bien essayé!

il faudrait trouver des noms différents pour des shells qui ont un comportement aussi différent !

évidemment, avec ksh Version AJM 93u+ 2012-08-01, je n'ai pas de problème avec ces commandes.

dans la même idée :

Code:

---

1 2 3

$ nf=$(echo "$string" | tr -d -c ':') $ echo $((${#nf}+1)) 3

---

Citation:

---

Envoyé par N_BaH

Bonjour,

en bash :

Code:

---

1 2 3 4

$ string="un_champ:un_autre_champ:encore_un" $ nf="${string//[^:]/}" $ echo $((${#nf}+1)) 3

---

il n'y a pas de raisons que ça ne fonctionne pas avec ksh.

---

Citation:

---

Envoyé par N_BaH

il faudrait trouver des noms différents pour des shells qui ont un comportement aussi différent !

---

Je confirme l'erreur sous KSH Version M-11/16/88f sous AIX et en KSH Version M-11/16/88i sous Solaris, et en 11/16/88 sous HP-UX...

Neanmoins, c'est probablement la version la plus rapide que l'on peut obtenir, car il n'y a pas d'indirection (pipe ou autres).
Reste a faire un portage sous des vieux KSH :)

PS : la version avec "echo | tr" fonctionne bien

Citation:

---

Envoyé par gangsoleil

Je confirme l'erreur sous KSH Version M-11/16/88f sous AIX et en KSH Version M-11/16/88i sous Solaris, et en 11/16/88 sous HP-UX...

---

Merci pour ces précisions!

Citation:

---

Reste a faire un portage sous des vieux KSH :)

---

Oui, parce que notre projet tout moderne (dans une grande boite connue, avec plein de logiciels utilisés par tout le monde) repose, en grande partie, sur ces belles architectures!

Souvent, ksh identifie la version 88 du shell Korn mais on peut accéder à la version 93 avec l'exécutable ksh93.
Vérifie sur ton système...

Citation:

---

Envoyé par al1_24

Souvent, ksh identifie la version 88 du shell Korn mais on peut accéder à la version 93 avec l'exécutable ksh93.
Vérifie sur ton système...

---

Chez moi, c'est dispo sur AIX :)

Citation:

---

Envoyé par al1_24

Souvent, ksh identifie la version 88 du shell Korn mais on peut accéder à la version 93 avec l'exécutable ksh93.
Vérifie sur ton système...

---

Merci pour cette sollicitude!

Effectivement, j'ai bien vu ce ksh93... mais:
- je n'ai pas les autorisations pour faire pointer ksh vers ksh93
- les administrateurs système ne le feront jamais
- je me vois mal demander aux utilisateurs de changer le shebang de leurs scripts (qui devront, de toute façon, être portables sur toutes les architectures de la maison)

J'en suis réduit à utiliser le plus petit dénominateur commun des différents 'ksh' (ainsi que des outils unix (df sed grep...)) fournis sur les plateformes officiellement supportées ici...

D'après mon expérience, en général, quand ça passe sous AIX, c'est bon pour les autres...

Citation:

---

Envoyé par jack-ft

D'après mon expérience, en général, quand ça passe sous AIX, c'est bon pour les autres...

---

Se mefier d'HP-UX, il est capable d'avoir quelques specificites bien sympa aussi.

Citation:

---

Envoyé par gangsoleil

Se mefier d'HP-UX, il est capable d'avoir quelques specificites bien sympa aussi.

---

Ouais! C'est pas faux!
(c'est "spécificités" que t'as pas compris?)

Petite remarque: en remplaçant l'appel de awk par tr, j'ai eu 3 tests en échec (sur 430).
J'en déduis donc que les 2 formes ne sont pas complètement équivalentes.
(elles le sont à 99.3%, d'une certaine manière...)

Si leur interprétation est la même dans de nombreux cas:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ echo 'a:b' | awk -F: '{print NF}' 2 $ lif=$(echo 'a:b' | tr -d -c ':') ; echo $((${#lif}+1)) 2 $ echo ':b' | awk -F: '{print NF}' 2 $ lif=$(echo ':b' | tr -d -c ':') ; echo $((${#lif}+1)) 2 $ echo ':' | awk -F: '{print NF}' 2 $ lif=$(echo ':' | tr -d -c ':') ; echo $((${#lif}+1)) 2 $ echo 'a' | awk -F: '{print NF}' 1 $ lif=$(echo 'a' | tr -d -c ':') ; echo $((${#lif}+1)) 1

---

En revanche, leur interprétation d'une chaîne vide diffère:

Code:

---

1 2 3 4

$ echo '' | awk -F: '{print NF}' 0 $ lif=$(echo '' | tr -d -c ':') ; echo $((${#lif}+1)) 1

---

D'où la question philosophique: combien de champs séparés par ':' la chaîne vide contient-elle?

On vote?

Sous Linux on peut aussi utiliser "grep -Fo :" pour compter les ":"

qu'est-ce qu'il disait ? il est pas chipoteur ? ... :mrgreen:

Code:

---

1 2 3 4 5 6 7 8 9 10

for str in '' "a" "a:" "a:b" "a:b:c" do nf=$(echo "$str" | tr -d -c ':') echo $((n=${#nf}, ${#str} || n?n+1:n)) done 0 1 2 2 3

---

Citation:

---

Envoyé par matafan

Sous Linux on peut aussi utiliser "grep -Fo :" pour conter les ":"

---

Ah! raconter les ":"... ;)

Amis conteurs, faites vos comptes! ;)

euh... sinon, à part ça, évidemment, ça ne marche pas sous AIX.

Une syntaxe qui passe avec ksh88:

Code:

---

1 2 3 4

$ LISTE='un_champ:un_autre_champ:encore_un' $ NF=$(set $(echo "$LISTE"|tr ':' ' ');echo $#) $ echo $NF 3

---

Citation:

---

Envoyé par jlliagre

Une syntaxe qui passe avec ksh88:

Code:

---

1 2 3 4

$ LISTE='un_champ:un_autre_champ:encore_un' $ NF=$(set $(echo "$LISTE"|tr ':' ' ');echo $#) $ echo $NF 3

---

---

Exact!

Restriction #1: les champs ne doivent pas contenir d'espaces
Restriction #2: les champs ne doivent pas être vides

D'où la solution:

Code:

---

1 2 3 4

$ LISTE=':apres un champ initial vide:un autre champ:::apres deux champs et avant un dernier vides:' $ NF=$(set $(echo "_$LISTE" | sed -e 's/ //g;s/:/ _/g');echo $#) $ echo $NF 7

---

Citation:

---

Envoyé par jack-ft

Code:

---

1 2 3 4

$ LISTE=':apres un champ initial vide:un autre champ:::apres deux champs et avant un dernier vides:' $ NF=$(set $(echo "_$LISTE" | sed -e 's/ //g;s/:/ _/g');echo $#) $ echo $NF 7

---

---

Je doute qu'un set --> echo --> sed --> echo soit plus économe que la solution awk ou mieux, un tr -cd : | wc -c comme suggéré plus haut par N_BaH.

Testé sur une longue chaîne (contenue dans le fichier test):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

jeanluc@ibm:~/scripts/test$ time set $(sed -e 's/ //g;s/:/ _/g' fichier_test); echo $# real 0m0.042s user 0m0.032s sys 0m0.008s   jeanluc@ibm:~/scripts/test$ time awk -F":" '{print NF}' fichier_test real 0m0.007s user 0m0.008s sys 0m0.000s   jeanluc@ibm:~/scripts/test$ time tr -cd : < fichier_test | wc -c real 0m0.004s user 0m0.000s sys 0m0.004s

---

Citation:

---

Envoyé par ripat

Je doute qu'un set --> echo --> sed --> echo soit plus économe que la solution awk ou mieux, un tr -cd : | wc -c comme suggéré plus haut par N_BaH.

---

Sans faire les tests, il faut savoir que ce qui coute le plus cher (pour peu que l'on fasse des appels simples), ce sont toujours les indirections. Donc oui, tu as de bonnes raisons de douter :) (ce que montrent tes tests).