Existe uma razão técnica para isso? Esse é um artefato dos primórdios do Linux ou Unix e, se houver, existe uma razão pela qual persiste?
Não consigo pensar em uma razão técnica - historicamente, é apenas ASCII. Como é lido e digitado está nas mãos do codificador.
unix-history-repo / usr / src / cmd / passwd.c
char *uname;
insist = 0;
if(argc < 2) {
if ((uname = getlogin()) == NULL) {
printf ("Usage: passwd user\n");
goto bex;
} else {
printf("Changing password for %s\n", uname);
}
} else {
uname = argv[1];
}
Como passei algum tempo navegando nas páginas de manual do arquivo (por exemplo: 1BSD foi a primeira Berkeley Software Distribution de Bill Joy ), não vi nada que especifique nomes de usuário. Isso não quer dizer que não exista, mas eu não o vi.
Então, ficamos com o contexto humano histórico. Quando eu comecei a tecnologia em 1980, sempre usamos nosso nome real para logins. Geralmente o primeiro nome e o sobrenome completos, a menos que haja algum limite de comprimento. Isso foi importante, pois seu nome de login foi usado como endereço de email. Ninguém na época enviou e-mails anônimos. Claro que deve ter havido algumas exceções, não as recordo. No geral, porém, acredito que seja esse o caso.
E de acordo com o rfc5321 # page-63, não há nenhuma restrição para que um "nome" de e-mail comece com um numérico. O gmail criará todos os nomes de usuário numéricos. (pegue agora, eles estão indo rápido).
Portanto, se houver algum código que rejeite um nome de usuário que comece com [0-9], ele provavelmente surgiu mais tarde com algum programador pensando "por que você teria um número como nome?". Mais uma vez, devo dizer que pode muito bem haver código unix histórico que rejeitou um nome de usuário começando com um número. Eu apenas não vi isso. As tabelas de senhas iniciais foram editadas à mão; certamente me lembro disso com frequência, mesmo no começo dos anos 90.
Quanto a por que isso persiste, citarei stroustrup, C ++ 11FAQ. Quando as novas bibliotecas padrão estarão disponíveis?
Para tornar o problema mais difícil, lembre-se de que não é possível eliminar os recursos mais antigos, mesmo que o comitê concorde que eles são ruins: a experiência mostra que os usuários forçam todos os implementadores a continuarem fornecendo recursos reprovados e banidos em opções de compatibilidade (ou por padrão) por décadas.