je comprends ce point de vue, et j'abonde sur le fait que le shell c'est pas fait pour faire des choses complexes; y'a toujours un présupposé quelque part qui peut tout foutre en l'air cependant je trouve aussi que les gens ont tendance à se compliquer la vie à coup de sed/awk/grep alors que read fait beaucoup, surtout couplé avec IFS.
en gros un
IFS='#'read _ id _ prenom nom _ <<<"$MESCHAMPS"
sera bien plus lisible qu'une succession de
id=$(...)prenom=$(...)
mais j'ai comme présupposé que # n'apparait pas dans les champs utilisés; une parade peut être en entrée de chaine un sed -r 's/#/YAUNDIESEDANSLECHAMP/' et son opération inverse en sortie, mais dans ce cas on remplace le présupposé que y'a pas la chaine YAUNDIESEDANSLECHAMP en entrée; on peut aussi donner 3 coups de tête sur le clavier pour générer la chaine de remplacement, ça devrait éviter les accidents.
Bien évidemment on peut remplacer # par autre chose, mais faut s'assurer que ce n'est pas présent dans le flux.
pour revenir à la validation d'un code postal ou d'un email, je pense qu'il est illusoire de chercher à valider à 100%, que la saisie est correcte; mais juste que le champs ressemble bien à l'attendu en gros pour une adresse mail .+@.+ devrait suffire à gérer le plus gros, car de toutes façon on ne peut pas savoir si le mail est bon, pour ça faut une validation en envoyant le mail, et au vu de la véritable validation d'une adresse de courriel, c'est plus simple.
Pour le code postal, a moins d'avoir une règle par pays, un code de plus de 2 caractères devrait suffire.
enfin faut pas hésiter a sortir d'autre outils comme le perl, quitte à les instrumenter via du shell, des choses se font très bien en bash, et sont plus galère à gérer avec le perl (et inversement)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Résultat
Posté par fearan . En réponse au lien The Programming Language compiled to Bash.. Évalué à 5.
je comprends ce point de vue, et j'abonde sur le fait que le shell c'est pas fait pour faire des choses complexes; y'a toujours un présupposé quelque part qui peut tout foutre en l'air cependant je trouve aussi que les gens ont tendance à se compliquer la vie à coup de sed/awk/grep alors que read fait beaucoup, surtout couplé avec IFS.
en gros un
sera bien plus lisible qu'une succession de
mais j'ai comme présupposé que # n'apparait pas dans les champs utilisés; une parade peut être en entrée de chaine un sed -r 's/#/YAUNDIESEDANSLECHAMP/' et son opération inverse en sortie, mais dans ce cas on remplace le présupposé que y'a pas la chaine YAUNDIESEDANSLECHAMP en entrée; on peut aussi donner 3 coups de tête sur le clavier pour générer la chaine de remplacement, ça devrait éviter les accidents.
Bien évidemment on peut remplacer # par autre chose, mais faut s'assurer que ce n'est pas présent dans le flux.
pour revenir à la validation d'un code postal ou d'un email, je pense qu'il est illusoire de chercher à valider à 100%, que la saisie est correcte; mais juste que le champs ressemble bien à l'attendu en gros pour une adresse mail .+@.+ devrait suffire à gérer le plus gros, car de toutes façon on ne peut pas savoir si le mail est bon, pour ça faut une validation en envoyant le mail, et au vu de la véritable validation d'une adresse de courriel, c'est plus simple.
Pour le code postal, a moins d'avoir une règle par pays, un code de plus de 2 caractères devrait suffire.
enfin faut pas hésiter a sortir d'autre outils comme le perl, quitte à les instrumenter via du shell, des choses se font très bien en bash, et sont plus galère à gérer avec le perl (et inversement)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent