open bracket in password caused sh syntax error

[itati01]

Hi,

I wanted to use getHdf() to download M*D16A2GF files. In contrast to non-GF files, the attempt resulted in authentication errors and empty hdf files before I used Earthdatalogin(). However, my original password contained an open bracket. This caused a "sh: 1: Syntax error: "(" unexpected" error. After changing the password, the download is now working. May be an "escape" is needed? The issue could be related to #102.

I tested the latest development version with remotes::install_github("MatMatt/MODIS", ref = "develop").

[fdetsch]

Thanks, I am able to reproduce this with a new password starting with $. MODIS:::checkEarthdataLogin() then returns:

sh: 1: not found

[fdetsch]

So here's my findings:

curl doesn't seem to care whether or not there's metacharacters in the Earthdata password. curl::handle_setopt(..., userpwd = paste0(usr, ":", pwd) likely handles this internally. So as long as dlmethod = "curl" (which hasn't been the default so far, but I am thinking about changing this permanently), you should be fine.

For all other download methods, including wget, things get more complicated and the only viable solution that I could come up with was to wrap username and password in single quotes before passing them on as download.files() extras. As a consequence, it is no longer permitted to have single quotes in your Earthdata password to avoid

sh: 1: Syntax error: Unterminated quoted string

errors. If you want to try this yourself, remember to

remotes::install_github(
  "fdetsch/MODIS"
  , ref = "105-open-bracket-in-password-caused-sh-syntax-error"
)

before re-running your code.

[itati01]

I added a $ and a ( to my current password and the code works, i.e. starts to download HDFs (I stopped the process after the first HDFs appeared in the temp folder):

EarthdataLogin()
MODISoptions(check_earthdata_login=TRUE, dlmethod="curl", MODISserverOrder="LPDAAC")
getHdf(product="MOD16A2GF", begin=modis_dates$beginDOY, end=modis_dates$endDOY, tileH=18:20, tileV=4)

However, there seems to be an issue in MODISoptions: Without MODISserverOrder="LPDAAC", the error Error in match.arg(server, several.ok = TRUE) :'arg' should be one of '“LPDAAC”, “LAADS”'` is raised. Is this intended, or should I open a new issue?

[fdetsch]

That's intended. My plan is to handle arguments passed to MODISoptions() a bit stricter using assertions, e.g. via checkmate. Nothing that's ready for release just yet, though.