1

I need to extract from a curl emitted:

  • the bash error message coming with a non-zero ?$ return code, in case my command would direly fail
  • the http status code returned by the server contacted
  • the error message accompanying a non-20x status code
  • the output message of the command

and dispatch all the four into four different variables.

Here is what I'm able to do, with the following request that creates a workspace if it doesn't exist:

URL=$1
USER=$2
PASSWORD=$3

WORKSPACE=ecoemploi


Créer un workspace ecoemploi (workspace par défaut)


CREATE_WORKSPACE_JSON=$(cat <<EOF
{
   "workspace":
   {
     "name": "$WORKSPACE"
   }
}
EOF
)


CREATE_WORKSPACE_RESPONSE=$(curl --silent -X POST --write-out "%{http_code}" 

   -H 'Content-type: text/json' -u "$USER:$PASSWORD" 

   "$URL/workspaces" -d "$CREATE_WORKSPACE_JSON")


if [ $? -ne 0 ]; then
   echo "La création de workspace dans geoserver a échoué avec le code $? : $CREATE_WORKSPACE_RESPONSE"
   exit $?
fi


echo "$CREATE_WORKSPACE_RESPONSE"

that sends a curl --silent -X POST --write-out '%{http_code}' -H 'Content-type: text/json' -u admin:geoserver http://localhost:8080/geoserver/rest/workspaces -d '{"workspace": {"name": "ecoemploi"}}', in example.

I am needing that dispatch among variables because the server I'm contacting has this behavior:

  1. If everything is ok, and the workspace doesn't exist, echo "$CREATE_WORKSPACE_RESPONSE" displays:
    ecoemploi201

  2. If the target workspace already exists, echo shows:

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
<title>Error 409 Workspace &apos;ecoemploi&apos; already exists</title>
</head>
<body><h2>HTTP ERROR 409 Workspace &apos;ecoemploi&apos; already exists</h2>
<table>
<tr><th>URI:</th><td>/geoserver/rest/workspaces</td></tr>
<tr><th>STATUS:</th><td>409</td></tr>
<tr><th>MESSAGE:</th><td>Workspace &apos;ecoemploi&apos; already exists</td></tr>
<tr><th>SERVLET:</th><td>dispatcher</td></tr>
</table>
<hr/><a href="https://eclipse.org/jetty">Powered by Jetty:// 9.4.48.v20220622</a><hr/>

</body>
</html>
409

If I add a --output /dev/null to my command, it will return:

  1. 201
  2. 409

but I loose the explanations for both cases, then.

  1. The 201 status code comes with the name of the workspace created in stdout
  2. The 409 failure message comes with an output that looks being an stdout, and I wonder what is in stderr

How may I write a statement causing the next variables, in bold, to be filled?

CREATE_WORKSPACE_ERROR=$(curl --silent -X POST --write-out HTTP_STATUS_CODE
-H 'Content-type: text/json' -u "$USER:$PASSWORD"
"$URL/workspaces" -d "$CREATE_WORKSPACE_JSON") 1>CREATE_WORKSPACE_STDOUT 2>CREATE_WORKSPACE_STDERR

in order to check and to compose the end user messages I am willing to send, with the $CREATE_WORKSPACE_ERROR, $HTTP_STATUS_CODE, $CREATE_WORKSPACE_STDOUT, $CREATE_WORKSPACE_STDERR variables produced?

muru
  • 72,889
Marc Le Bihan
  • 1,797
  • Does this answer your question? Redirect STDERR and STDOUT to different variables without temporary files – muru Aug 30 '23 at 05:53
  • If you can, just write them out into different files and extract the relevant data out using text processing tools. I feel it will be less painful that way – muru Aug 30 '23 at 06:00
  • @muru My question isn't only about stderr and stdout, which are two extracts among the four I am needing. I am not against extracting the four contents on four different temp files, and then reading these four files into four variables, if it has to be done this way (even if it's a bit clumsy), but I don't see how to write the parts --write-out HTTP_STATUS_CODE and CREATE_WORKSPACE_ERROR into two files if 1> and >2 are already redirected to two other files. – Marc Le Bihan Aug 30 '23 at 06:48
  • You really don't want to use CAPS for shell variable names. Since, by convention, global environment variables are capitalized, it is bad practice to also use caps for your own, local variables because this can lead to naming collisions and hard to find bugs. Here, you are actually using and setting USER, which is an environment variable. It isn't causing the problem you see, but it can cause all sorts of other issues. – terdon Aug 30 '23 at 11:10
  • @terdon I didn't know that rule. I've always seen linux variables capitalized everywhere, and did like I saw. But thanks. I will change this, now. – Marc Le Bihan Aug 30 '23 at 13:28

0 Answers0