You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pass --ask-password=false to rclone listremotes in the shared remote generator. When a user has an encrypted rclone config, the generator was running rclone listremotes synchronously and rclone blocked on an interactive password prompt — freezing the terminal session as soon as the user typed rclone about (or any other subcommand that takes a remote: arg).
Root cause
src/rclone.ts defined a single remote: Fig.Arg whose generator script was ["rclone", "listremotes"]. That arg (and its generators) is reused by cryptedremote, remotePath, sourcePath, and destPath, so every subcommand that accepts a remote inherits the same shell-out. With an encrypted config, rclone defaults to --ask-password=true and reads from the controlling tty, which the autocomplete generator has no way to feed — so the call hangs and the shell appears frozen until rclone is killed.
Fix
One-token change: append --ask-password=false to the script array. --ask-password is a long-standing rclone global flag; with =false and no password available via RCLONE_CONFIG_PASS or --password-command, rclone exits non-zero instead of prompting. The generator then yields an empty list rather than freezing — which is the desired UX when we genuinely can't enumerate remotes. The change stays scoped to the shared remote generator, so all four reusing args (cryptedremote, remotePath, sourcePath, destPath) pick it up with no duplication.
npx tsc --noEmit on the project — no new errors in src/rclone.ts (pre-existing at() lib errors in other specs are unrelated and present on master)
Manually verified rclone's behavior: with an encrypted config and no RCLONE_CONFIG_PASS, rclone listremotes --ask-password=false exits non-zero immediately instead of prompting; on an unencrypted config it behaves identically to the bare command.
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.
I have read the CLA Document and I hereby sign the CLA
root seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Pass
--ask-password=falsetorclone listremotesin the sharedremotegenerator. When a user has an encrypted rclone config, the generator was runningrclone listremotessynchronously and rclone blocked on an interactive password prompt — freezing the terminal session as soon as the user typedrclone about(or any other subcommand that takes aremote:arg).Root cause
src/rclone.tsdefined a singleremote: Fig.Argwhose generator script was["rclone", "listremotes"]. That arg (and itsgenerators) is reused bycryptedremote,remotePath,sourcePath, anddestPath, so every subcommand that accepts a remote inherits the same shell-out. With an encrypted config, rclone defaults to--ask-password=trueand reads from the controlling tty, which the autocomplete generator has no way to feed — so the call hangs and the shell appears frozen until rclone is killed.Fix
One-token change: append
--ask-password=falseto thescriptarray.--ask-passwordis a long-standing rclone global flag; with=falseand no password available viaRCLONE_CONFIG_PASSor--password-command, rclone exits non-zero instead of prompting. The generator then yields an empty list rather than freezing — which is the desired UX when we genuinely can't enumerate remotes. The change stays scoped to the sharedremotegenerator, so all four reusing args (cryptedremote,remotePath,sourcePath,destPath) pick it up with no duplication.Testing
npx eslint src/rclone.ts— cleannpx prettier --check src/rclone.ts --parser typescript— cleannpx tsc --noEmiton the project — no new errors insrc/rclone.ts(pre-existingat()lib errors in other specs are unrelated and present onmaster)RCLONE_CONFIG_PASS,rclone listremotes --ask-password=falseexits non-zero immediately instead of prompting; on an unencrypted config it behaves identically to the bare command.Fixes #2102.