<p>It's not a curl problem.  (The <a href="https://curl.se/libcurl/c/libcurl-errors.html#CURLEHTTPRETURNEDERROR" rel="nofollow noreferrer">22 error</a> is just passing along the server-side HTTP 400 error, which is because it dumped an error message into a URL.)  I think terdon is right and there's something wrong with your edirect installation.  You have esearch and efetch on your PATH but apparently not xtract and/or xtract.Darwin.</p>
<hr />
<p>More detail:</p>
<p>Look toward the end of the error message, at the text being passed to curl's <code>-d</code> argument:</p>
<pre><code>db=pubmed&amp;id=Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin&amp;rettype=medline&amp;retmode=text&amp;tool=edirect&amp;edirect=16.1&amp;edirect_os=Darwin&amp;email=mariocatalano%40MBP-di-Mario.lan&quot;
</code></pre>
<p>It's putting this in the <code>id=</code> part:</p>
<pre><code>Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin
</code></pre>
<p>which is maybe something like (trying to guess which characters got turned into <code>%2C</code>):</p>
<blockquote>
<p>Unable to locate xtract executable. Please execute the following: nquire -dwn ftp.ncbi.nlm.nih.gov entrez/entrezdirect xtract.Darwin.gz; gunzip -f xtract.Darwin.gz; chmod +x xtract.Darwin</p>
</blockquote>
<p>But you should already have xtract and xtract.Darwin from the same edirect install that gave you esearch and efetch.</p>
<p>For what it's worth the official Entrez Direct install on Mac OS looks a little goofy.  When I try it myself it ends with:</p>
<pre><code>Entrez Direct has been successfully downloaded and installed.

-e In order to complete the configuration process, please execute the following:

  echo &quot;export PATH=\\\${PATH}:&quot; &gt;&gt; <span class="math-container">$HOME/.bashrc
  echo "export PATH=\\\${PATH}:" &gt;&gt; $</span>HOME/.zshrc

or manually edit the PATH variable assignments in your .bashrc and .zshrc files.

Would you like to do that automatically now? [y/N]
</code></pre>
<p>Those commands don't look right (what's getting added to the path? an empty string?) and if I say y, I get this at the end of .bashrc and .zshrc which definitely isn't right:</p>
<pre><code>export PATH=${PATH}:
</code></pre>
<p>It seems like an empty string at the end of PATH behaves like <code>.</code> (current directory), so I can go into ~/edirect and run your command and it <em>does</em> actually work.  So this isn't exactly your problem... but still, that seems wrong.</p>

CC BY-SA 4.0
2021-10-20T09:19:36.700Z
Note that macOS uses login shells by default for historical reasons, which means that if the OP is using bash (which is no longer the default on macOS), then `~/.bashrc` is irrelevant and they should use `~/.profile` instead. Either way though, that command is quite wrong, as you point out.
terdon
CC BY-SA 4.0
2021-10-20T16:52:42.340Z
This was an issue with the Edirect installation script. The `install-edirect.sh` script has been updated to fix this issue. Please follow the instructions [here](https://www.ncbi.nlm.nih.gov/books/NBK179288/) to install.
vkkodali
CC BY-SA 4.0
2021-10-20T17:51:05.890Z
Thanks!  The install still seems to misbehave on Mac OS, though.  When I say `y`my `~/.bashrc` is now untouched and my `~/.zshrc` contains literally`export PATH=${PATH}:/Users/jesse echo export PATH=${PATH}:/Users/jesse`
Jesse
CC BY-SA 4.0
2021-10-20T20:11:52.133Z
@Jesse thank you for trying it out. This is yet another issue that needed a quick fix. The updated script is already on FTP so if you try again it should work. Sorry for the inconvenience.
vkkodali
CC BY-SA 4.0
2021-10-21T14:19:35.567Z
No trouble, thanks for working on this.  Still behaving strangely for me but when I look at the script I think I see one reason.  It references DIR when setting up PATH, but that's the original working directory / the directory containing the install script, not the destination directory, right?  Should that instead be a `$PWD` or something once inside the ~/edirect location, maybe? We might be drifting from OP's question but I'm happy to help debug this via email or a github gist or something.
Jesse
CC BY-SA 4.0
2021-10-21T19:05:01.350Z
@Jesse, turns out this is yet another issue that had to be fixed. The new installation script was derived from the old `setup.sh` file, which was run within the `edirect` folder. In that context the `DIR` variable was correct. The new code now sets `DIR` after calling `cd edirect`, so its value is now also correct. Sorry for the inconvenience, and thanks again for your reports.
vkkodali
CC BY-SA 4.0
2021-10-21T19:14:34.713Z
Yep, works as expected now on Mac OS.  Thanks!
Jesse
CC BY-SA 4.0
2021-10-19T19:02:12.003Z
2021-10-19T19:02:12.003Z
Jesse
<p>I've just dowloaded entrez direct on my Mac and I was trying to perform some simple queries like:</p>
<pre><code>esearch -db pubmed -query &quot;tn3 transposition immunity&quot; | efetch -format medline
</code></pre>
<p>but I keep getting this error</p>
<pre><code>curl: (22) The requested URL returned error: 400 Bad Request
 ERROR:  curl command failed ( Mar 19 Ott 2021 13:02:26 CEST ) with: 22 
https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi -d db=pubmed&amp;id=Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin&amp;rettype=medline&amp;retmode=text&amp;tool=edirect&amp;edirect=16.1&amp;edirect_os=Darwin&amp;email=mariocatalano%40MBP-di-Mario.lan&quot;
</code></pre>
<p>I'm using bash scripts on my Mac's terminal</p>
<p>How should I fix this?</p>

CC BY-SA 4.0
2021-10-19T11:57:22.880Z
update your curl or esearch version, use the miniconda/brew versions. If you already have conda, you can create an environment and install it on it.
zorbax
CC BY-SA 4.0
2021-10-19T12:31:46.850Z
Looks like you haven't installed it correctly. The error is saying it cannot locate/extract the executable.
terdon
CC BY-SA 4.0
2021-10-20T16:55:21.027Z
@zorbax -- it is recommended to use the official version of Edirect instead of the  ones from miniconda, brew, etc as they often tend to be quite behind the latest, official version.
vkkodali
<bash><entrez><curl>
curl: (22) The requested URL returned error: 400 Bad Request when using entrez direct
# curl: (22) The requested URL returned error: 400 Bad Request when using entrez direct

(Asked by: username_0 on 2021-10-19)

I've just dowloaded entrez direct on my Mac and I was trying to perform some simple queries like:
esearch -db pubmed -query "tn3 transposition immunity" | efetch -format medline

but I keep getting this error
curl: (22) The requested URL returned error: 400 Bad Request
 ERROR:  curl command failed ( Mar 19 Ott 2021 13:02:26 CEST ) with: 22 
https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi -d db=pubmed&id=Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin&rettype=medline&retmode=text&tool=edirect&edirect=16.1&edirect_os=Darwin&email=mariocatalano%40MBP-di-Mario.lan"

I'm using bash scripts on my Mac's terminal
How should I fix this?

**Tags:** bash, entrez, curl
> **Comments:**
> **username_1**: update your curl or esearch version, use the miniconda/brew versions. If you already have conda, you can create an environment and install it on it.  
> **username_2**: Looks like you haven't installed it correctly. The error is saying it cannot locate/extract the executable.  
> **username_3**: @zorbax -- it is recommended to use the official version of Edirect instead of the  ones from miniconda, brew, etc as they often tend to be quite behind the latest, official version.  

---

## 1 answers

### Answer by username_4 on 2021-10-19. Score: 2

It's not a curl problem.  (The 22 error is just passing along the server-side HTTP 400 error, which is because it dumped an error message into a URL.)  I think terdon is right and there's something wrong with your edirect installation.  You have esearch and efetch on your PATH but apparently not xtract and/or xtract.Darwin.

More detail:
Look toward the end of the error message, at the text being passed to curl's -d argument:
db=pubmed&id=Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin&rettype=medline&retmode=text&tool=edirect&edirect=16.1&edirect_os=Darwin&email=mariocatalano%40MBP-di-Mario.lan"

It's putting this in the id= part:
Unable%2Cto%2Clocate%2Cxtract%2Cexecutable.%2CPlease%2Cexecute%2Cthe%2Cfollowing%2Cnquire%2Cdwn%2Cftp.ncbi.nlm.nih.gov%2Centrez%2Centrezdirect%2Cxtract.Darwin.gz%2Cgunzip%2Cf%2Cxtract.Darwin.gz%2Cchmod%2Cx%2Cxtract.Darwin

which is maybe something like (trying to guess which characters got turned into %2C):

Unable to locate xtract executable. Please execute the following: nquire -dwn ftp.ncbi.nlm.nih.gov entrez/entrezdirect xtract.Darwin.gz; gunzip -f xtract.Darwin.gz; chmod +x xtract.Darwin

But you should already have xtract and xtract.Darwin from the same edirect install that gave you esearch and efetch.
For what it's worth the official Entrez Direct install on Mac OS looks a little goofy.  When I try it myself it ends with:
Entrez Direct has been successfully downloaded and installed.

-e In order to complete the configuration process, please execute the following:

  echo "export PATH=\\\${PATH}:" >> $HOME/.bashrc
  echo "export PATH=\\\${PATH}:" >> $HOME/.zshrc

or manually edit the PATH variable assignments in your .bashrc and .zshrc files.

Would you like to do that automatically now? [y/N]

Those commands don't look right (what's getting added to the path? an empty string?) and if I say y, I get this at the end of .bashrc and .zshrc which definitely isn't right:
export PATH=${PATH}:

It seems like an empty string at the end of PATH behaves like . (current directory), so I can go into ~/edirect and run your command and it does actually work.  So this isn't exactly your problem... but still, that seems wrong.

> **Comments:**
> **username_2**: Note that macOS uses login shells by default for historical reasons, which means that if the OP is using bash (which is no longer the default on macOS), then `~/.bashrc` is irrelevant and they should use `~/.profile` instead. Either way though, that command is quite wrong, as you point out.  
> **username_3**: This was an issue with the Edirect installation script. The `install-edirect.sh` script has been updated to fix this issue. Please follow the instructions [here](https://www.ncbi.nlm.nih.gov/books/NBK179288/) to install.  
> **username_4**: Thanks!  The install still seems to misbehave on Mac OS, though.  When I say `y`my `~/.bashrc` is now untouched and my `~/.zshrc` contains literally`export PATH=${PATH}:/Users/jesse echo export PATH=${PATH}:/Users/jesse`  
> **username_3**: @Jesse thank you for trying it out. This is yet another issue that needed a quick fix. The updated script is already on FTP so if you try again it should work. Sorry for the inconvenience.  
> **username_4**: No trouble, thanks for working on this.  Still behaving strangely for me but when I look at the script I think I see one reason.  It references DIR when setting up PATH, but that's the original working directory / the directory containing the install script, not the destination directory, right?  Should that instead be a `$PWD` or something once inside the ~/edirect location, maybe? We might be drifting from OP's question but I'm happy to help debug this via email or a github gist or something.  
> **username_3**: @Jesse, turns out this is yet another issue that had to be fixed. The new installation script was derived from the old `setup.sh` file, which was run within the `edirect` folder. In that context the `DIR` variable was correct. The new code now sets `DIR` after calling `cd edirect`, so its value is now also correct. Sorry for the inconvenience, and thanks again for your reports.  
> **username_4**: Yep, works as expected now on Mac OS.  Thanks!  

---

