how can I invoke the rclone config reconnect REMOTE: command from the command line?
at present I have a script that send a couple of answers to rclone (first yes, then no) in order to get to the token submission phase, and then provide my own token there.
something goes wrong, though:
user@host ~$ rclone config reconnect REMOTE: << EOF
Already have a token - refresh?
y) Yes (default)
y/n> Use auto config?
* Say Y if not sure
* Say N if you are working on a remote or headless machine
y) Yes (default)
y/n> 2020/05/29 20:21:53 Failed to read line: EOF
until my problem with Box.com tokens keep expiring? is solved -- either I'm doing something wrong there, or it's a bug -- I have devised a way to automatically reauthorize my Box logins.
I'd like to use a combo of rclone authorize and rclone config reconnect to manually repeat the oauth process.
I was trying to run: 1) rclone authorize box --auth-no-open-browser to get a local webserver url for oath redirection, 2) manually opening the browser and typing user/pass and granting the oauth, 3) inserting the token in rclone config reconnect.
the global flag you suggested prevents me from using this process: ideally, I'd imagine a flag to do everything but avoid rclone opening the browser on its own but I haven't found it.
I've also taken a look at the remote parameters such as config_refresh_token=false and config_is_local=false but neither of those use cases are helpful.
I'd like to, ideally, execute a: rclone config reconnect REMOTE: --auto-confirm --dont-open-browser
Already have a token - refresh?
Auto confirm is set: answering Yes, override by setting config parameter config_refresh_token=false
Use auto config?
Say Y if not sure
Say N if you are working on a remote or headless machine
Auto confirm is set: answering Yes, override by setting config parameter config_is_local=false
If your browser doesn't open automatically go to the following link: http://127.0.0.1:53682/auth?state=ZZZZZZZZZ
Log in and authorize rclone for access
Waiting for code...
which is not what I'd like to do!
am I missing another piece of the puzzle?
NOTE: this flow has the disadvantage that the remote is also modified with config_refresh_token=false, which is not really what I want.
also, rclone config update MYBOX config_refresh_token true does not reset the flag as it was, but starts the oauth process again.
in any case, I would suggest to make sure that every interactive command has an exact counterpart for command-line execution, so the user does not have to reinvent the wheel depending on how the interface to rclone happens.
regarding my issues, I'll still try and understand what's going awry with refresh tokens, but in case I need it I now know how to automate the token refreshing process. thanks!
yeah, no worries!
it's quite difficult as it is to keep track of changes in the docs, let alone enhance the entire user interface.
my suggestion is, roughly, to make sure to have a non-interactive rclone command, for each and every rclone command.
I was, and still am, pretty confused by the rclone docs -- another example of my doubts was How to create new "crypt" remote from command line.
also, if I may be honest, the "global flags" page is not really helpful, because it coalesces stuff together that not necessarily belongs together, and makes the user go there fishing for possible parameters.
it would be a lot more readable if all the flags applicable to a certain command were in its doc page.
The basic config stuff works reasonably well, but each backend is entitled to have a config hook which runs code. These config hooks are the ones which renew tokens and ask the user stuff. They are potentially unique to each backend - for example the google drive one configures the token then asks if you want to configure a team drive.
Making a uniform command line interface for those isn't something I've figured out yet. I could make them use the same configuration machinery as the main configuratiion - that might work - then at least all the possible parameters would be documented in advance even if not all of them were relevant.
Ideally there needs to be a bit of back and forth - the google backend needs to get the token before it can ask you to choose from a list of team drives.
Potentially I could do
define all the possible questions in advance so they go in the docs
have a config state so you can have more than one config callback and you need to provide the number of the one you want next
when rclone returns from the config and there are still questions to ask, then return a JSON blob with the question(s) in and a state for the config to use on the next call...
You are right, rclone shouldn't really be storing the config_magic strings in the config, but there is no-where else to put them at the moment.