Forum Programmation.shell enlever les fins de ligne du résultat de curl

Posté par freem le 16 mai 2014 à 13:02. Licence CC By‑SA.

Étiquettes :

mai

2014

Bonjour.

Je souhaite récupérer le retour d'une API web interne via curl, pour la comparer à un résultat prédéterminé ( en fait, de jouer des tests sans me casser les pieds à devoir me retaper le copier/coller partiel en fonction du serveur ni devoir lire le résultat pour être sûr qu'il est bon ).
Donc, j'ai créé un fichier contenant mes listes de paramètres et un script qui appelle l'URI voulue ( un serveur ou l'autre, principalement ) en ajoutant la liste des paramètres.
Jusqu'ici, pas de souci.

Problème: pour faciliter les tests, ces APIs renvoient un code avec des fins de ligne "\n", ce qui rend la comparaison scriptée avec un résultat attendu pénible.
J'ai pensé le faire avec sed, mais ça ne semble pas marcher:

while read params; do
  curl -s "$uri""$params"|sed 's/[\n]//'
done < $input_file

Je suppose que j'ai dû me rater quelque part, mais où?

# mauvais outil

Posté par Zylabon le 16 mai 2014 à 13:19. Évalué à 6.

sed travaille ligne à ligne, c'est sûrement possible de le faire mais super chiant.

tr -d '\n' fait le boulot :)

Please do not feed the trolls
- [^] # Re: mauvais outil
  
  Posté par freem le 16 mai 2014 à 14:22. Évalué à 1.
  
  Ahhhh!!
  Bien, en effet, ça marche tout seul :)
  
  Merci beaucoup.
# retour chariot

Posté par NBaH le 16 mai 2014 à 13:49. Évalué à 1.

ces APIs renvoient un code avec des fins de ligne "\n", ce qui rend la comparaison scriptée avec un résultat attendu pénible.

peut-on voir le test que tu fais ?
peut-on voir la sortie de curl en la passant par od -c ?

est-ce bien le retour à la ligne normal sur *n?x, qui pose problème, ou le \r qu'y ajoute W$ ?
- [^] # Re: retour chariot
  
  Posté par freem le 16 mai 2014 à 14:21. Évalué à 1.
  Pas de \r, parce que pas de Windows ni de Mac derrière ( et pour le coup, c'est plutôt les unix et les mac qui enlèvent un morceau de la fin de ligne: LF signifie nouvelle ligne, et CR retour chariot, donc il faut logiquement combiner les 2… pour une fois que MS fait un truc plus propre que les autres… )
  
  Pour le test, pour le moment je ne teste rien, je veux d'abord récupérer le retour sur une seule ligne, afin de pouvoir facilement comparer, justement. Et si un test ne passe pas, il me suffirait ainsi de juste regarder quelle ligne pose problème pour connaître le test ( puisque j'aurais alors d'un côté une liste de lignes contenant les requêtes, et de l'autre côté une liste ou chaque ligne correspondrait à la requête de même ligne ).
  
  Enfin bref:
  Sans "od -c" ( je connaissais pas cette commande, ça à l'air utile ):
```
{"CorrelationID":"test","MessageResponse":[
{"ResponseCode":4,"ResponseComment":"LineColor too long, it will be truncated"},
{"ResponseCode":0,"ResponseComment":"success"}]
```
  Avec:
```
0000000   {   "   C   o   r   r   e   l   a   t   i   o   n   I   D   "
0000020   :   "   t   e   s   t   "   ,   "   M   e   s   s   a   g   e
0000040   R   e   s   p   o   n   s   e   "   :   [  \n   {   "   R   e
0000060   s   p   o   n   s   e   C   o   d   e   "   :   4   ,   "   R
0000100   e   s   p   o   n   s   e   C   o   m   m   e   n   t   "   :
0000120   "   L   i   n   e   C   o   l   o   r       t   o   o       l
0000140   o   n   g   ,       i   t       w   i   l   l       b   e    
0000160   t   r   u   n   c   a   t   e   d   "   }   ,  \n   {   "   R
0000200   e   s   p   o   n   s   e   C   o   d   e   "   :   0   ,   "
0000220   R   e   s   p   o   n   s   e   C   o   m   m   e   n   t   "
0000240   :   "   s   u   c   c   e   s   s   "   }   ]  \n   }
0000256
```
  - [^] # Re: retour chariot
    
    Posté par NBaH le 16 mai 2014 à 14:40. Évalué à 1. Dernière modification le 16 mai 2014 à 14:40.
```
var='{"CorrelationID":"test","MessageResponse":[
{"ResponseCode":4,"ResponseComment":"LineColor too long, it will be truncated"},
{"ResponseCode":0,"ResponseComment":"success"}]'

echo "`{mathjax} {var//`'\n'/}"
{"CorrelationID":"test","MessageResponse":[{"ResponseCode":4,"ResponseComment":"LineColor too long, it will be truncated"},{"ResponseCode":0,"ResponseComment":"success"}]```
:)

¿ mathjax ? kesako ? il faut lire `echo "${var//$'\n'/}"`
```
    - [^] # Re: retour chariot
      
      Posté par freem le 16 mai 2014 à 16:19. Évalué à 1.
      
      Hum… je ne suis pas sûr de comprendre. Tu me dis d'utiliser un outil spécialisé, j'imagine?
      
      Mais bon, aujourd'hui il se trouve que c'est du json ( dont je ne suis pas sûr qu'il soit complètement conforme en plus ) et demain ça pourrait très bien devenir du xml ou du yaml.
      
      Mon objectif, là, c'est vraiment de trouver un mécanisme pour tester le retour d'une API web modulo les retours à la ligne, et pour ça je ne connais, pour le moment, que curl + un fichier de requêtes monolignes + un fichier de résultats monolignes de référence, et on compare le retour des requêtes transformé en monoligne au fichier de résultats de référence.
      Quand on sait quelle ligne diffère, on sait que telle requête pose un problème ( reste à trouver lequel et déboguer, mais bon… )
      - [^] # Re: retour chariot
        
        Posté par NBaH le 16 mai 2014 à 16:38. Évalué à 1.
        
        Hum… je ne suis pas sûr de comprendre. Tu me dis d'utiliser un outil spécialisé, j'imagine?
        
        non, non, c'est le formatage du code par le moteur du forum qui ch..!
        
        ${paramètre//motif/chaîne} : il s'agit, parmi les Remplacements de paramètres bash, d'une substitution de motif, qui évite l'emploi d'une commande externe (justement).
        
        [^] # Re: retour chariot
        
        Posté par freem le 16 mai 2014 à 18:53. Évalué à 1.
        
        Ah ok merci.
        
        Je me garderai ça dans un coin de mémoire, ça peut servir :)
  - [^] # Re: retour chariot
    
    Posté par wismerhill le 17 mai 2014 à 15:03. Évalué à 5.
    
    ( et pour le coup, c'est plutôt les unix et les mac qui enlèvent un morceau de la fin de ligne: LF signifie nouvelle ligne, et CR retour chariot, donc il faut logiquement combiner les 2… pour une fois que MS fait un truc plus propre que les autres… )
    
    Non, c'est juste un reste ridicule de l'époque des premiers téléscripteurs, qui imprimaient le texte sur du papier au fur et à mesure qu'ils le recevaient.
    Il avait été décidé d'utiliser deux caractères pour représenter une nouvelle ligne, car sans ça le caractère suivant la fin de ligne arrivait trop vite, la tête d'impression n'avait pas eu le temps de revenir en début de ligne et le caractère se retrouvait au milieu de la page.
    Et malheureusement pour nous cette convention est restée dans différents systèmes.
    
    cf http://en.wikipedia.org/wiki/Newline#History

Suivre le flux des commentaires

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