Initially, I didn't think of requesting this as a feature for Rclone because I was under the impression that the proposed part of the topic was already in place. I was trying to add the email address in the config name, which led me to create an issue under 'Help and support.'
Feature request:
To include special characters (or at least the "@" character) support while creating a config name.
Usability once implemented:
The "@" character can help differentiate between the remotes since it will allow users to include their email addresses (valid for popular cloud services). The current set of characters can allow many combinations, but this particular addition can help in the instance mentioned.
A user can better understand which one drive account is connected to the remote if the name can be odbusiness - user@example.com instead of the current implementation odbusiness.
May contain numbers, letters, _, -, . @ and space. (if the character "@" is only implemented)
I can help make the implementation possible only to a limited scale as I am still learning the tool and in the initial stages of its usage. However, if I can help in any way possible, I am happy to do so.
Remote names are case sensitive, and must adhere to the following rules:
May contain number, letter, _, -, . and space.
May not start with - or space.
May not end with space.
Starting with rclone version 1.61, any Unicode numbers and letters are allowed, while in older versions it was limited to plain ASCII (0-9, A-Z, a-z). If you use the same rclone configuration from different shells, which may be configured with different character encoding, you must be cautious to use characters that are possible to write in all of them. This is mostly a problem on Windows, where the console traditionally uses a non-Unicode character set - defined by the so-called "code page".
There are quite a few constraints on remote names
easy to type at the command line (must not contain a shell metacharacter for all OSes, can't be !$%*()[]{}<>?| - not an exhaustive list!)
mustn't be a character rclone uses as paths (eg : and / and \)
they can be file names under every OS (can't be /\"*:<>?|)
it must work in the config file (rules out [ and ])
These rules rule out nearly every character in !"#$%&'()*+,-./:;<=>?@[]^_{|}~. The most likely to pass would be @,+^;
If we were to add @ it would need to pass these rules.
OK for unix shells - not sure about Windows - @Ole@albertony ?
OK - rclone doesn't have special meaning for @
I believe that @ can be in file names under Windows, Linux and Mac.
Not sure about the config parser - need to check but likely OK
@albertony - you were involved with the increase from ascii characters - what do you think?
The special use in CMD is well spotted, and a reminder that adding special characters may have wider implications that one may initially think. As an example we should probably also consider valid URLs and JSON when used in things like the API or rclone serve combinedRemote:
Excellent analysis!
I would be tempted to add them all to avoid repeating this again in a week when we get a good argument to add e.g. +
That would also make a well rounded list of legal characters, in my eyes:
May contain letters, numbers, _, -, +, ., ;, @, ^ and spaces.
Note that use of ; needs quoting in Linux, and PowerShell on Windows, as it is used to separate multiple commands on a single line.
Also ^ needs quoting in Windows Command Prompt, it is actually an escape character:
C:\Temp>echo hello&world
hello
'world' is not recognized as an internal or external command,
operable program or batch file.
C:\Temp>echo hello^&world
hello&world
To me, quoting is kind of given as soon as moving beyond letter, number and _, but using an escape character sounds more scary. Perhaps pull ^ from the list and add "," which I happened to forget - useful for "OneDrive - Frost, Ole"
Yeah, I can agree with that. I didn't say we can not use those symbols, I haven't really thought it through if this would lead to real problems, just wanted to make sure we are aware of the possibility at least.
Perhaps pull ^ from the list and add ","
Sure, then I don't have to "think it through"... Perhaps better to be on the safe side, and also I think ^ is not exactly the symbol that is missed the most...
I had these in mind but was unsure whether the implementation could be made possible. Point 4 was something that didn't cross my mind.
Essentially, the @ character itself can tremendously improve the config naming convention. Although the inclusion of the possible characters during the testing period can rule out the possible problem causing characters.
Well spotted! I should have put , in my original list. If we allowed , it would make parsing config strings impossible.
I want to keep the potential metacharacters in config names to the minimum so that we don't interfere with unknown systems!
We added . recently which allowed config names to be domain names, adding @ will allow them to represent nearly all email addresses so that seems like a good change.
The utility of adding + is probably marginal, though you do get email addresses with + in.
It is good to be optimistic and it looks like @albertony is very kind with this small change. It will however typically take a lot longer without contributing with sponsorship or development. There are 700+ open issues and you can get an impression of the number of issues implemented per release by looking in the change log.
Thanks, and well said. And that link contains a link to beta builds, so if @yolobnb would like to contribute with testing that would be appreciated. As discussed we are not 100% confident there isn't some caveat so the more regression testing the better.
Thanks, @albertony, for merging the necessary commits to the repo and doing it at lightspeed. I will upgrade to the beta release now and start testing.
I am a bit confused about the beta version. Is the command below the right one to be used?
Hm, I'm not really sure about the selfupdate argument, but seems to me it doesn't consider beta builds from branches, i.e. only considers beta builds from master at root of https://beta.rclone.org/. But its as simple as manually downloading the zip with your browser, extracting to a temp folder and start testing from there. It will then re-use your existing config file if it is in a standard location. If you would have it completely stand-alone you can also customize it to use its own config file, see https://rclone.org/docs/#config-config-file.
Perhaps better to be on the safe side, and also I think 
