On the display side, I'm sure most tools that display usernames won't make it easy to see if there are leading or trailing whitespace characters, double blanks, tabs etc in usernames.
This sounds like support hell to me.
On the display side, I'm sure most tools that display usernames won't make it easy to see if there are leading or trailing whitespace characters, double blanks, tabs etc in usernames.
This sounds like support hell to me.
Of course, in those days if an OS upgrade broke some third party software, the end user paid for an upgrade. So although Microsoft forced developers' hands, the developers all got paid for their trouble. And you'd only have your hand forced that way once or twice a decade.
Windows at the time was also all about the GUI file-pickers. Breaking the command line? Shell scripts? What are those?
Only if you assume that people rarely have spaces in their Windows login names (e.g. "Joe Smith").
Either that, or Windows users have learned to not be scared of spaces in filenames, usernames, and their own literal names.
non-Western Windows users always knew never to use anything outside ASCII for usernames, passwords, or any programmatically used identifiers. It's English users that haven't learned it.
The official workaround at runtime is to use the "\\?\" prefix with an absolute path to create an unrestricted verbatim pathname. For instance, the fs::canonicalize() function in Rust will always return such a pathname, to many programmers' dismay, since outside tools often choke on them.
The unofficial workaround is to set the undocumented IsLongPathAwareProcess bit in the process's PEB. The Go runtime does this, but silently falls back to "\\?\" prefixes if the Windows version is too old.
(Note that in general, canonicalizing paths is safer on Windows than on Unix-like systems, since open directories cannot be renamed.)
Meanwhile, DOS and Windows 3.1 applications that did run on Windows 95 could access files under a backward compatible 8.3 scheme, like C:\Progra~1\ instead of "C:\Program Files".
I agree they were famously accommodating in those days. But they also had enough market power that if they said users could only write to one folder and it had a space in the filename, developers who disliked it couldn't vote with their feet.
I just dont understand why they dont use part of the email address as the home folder name. And just because of this stupidity, user display names have to be without any of these characters
Microsoft ... PLEASE
[0] https://doitpshway.com/do-not-use-diacritics-in-aad-user-dis...
They didn't force anything.
Pretty clever if so :D
I was curious about a deep dive into this topic, and skimmed the MS doc pages after a Google search. They mentioned different Windows APIs and Long file names, but the only mention of the tilde compat layer I found was very superficial ("some file-systems" use the tilde as special character), so I abandoned my initial interest in getting up to speed on this during a 2min weeekend read.
And yet whenever I deal with a computer system I don't put the apostrophe in because even in 2024 it is completely jacked up. Sometimes it's just disallowed. Sometimes I get "\\'" showing up. Sometimes I get "'". I've seen "’". One time, one system accepted it, but another system that accessed the same data didn't allow apostrophes so the person using the second system couldn't access the record, and it took 2 phone calls and 3 people to come up with a workaround.
It doesn't work often enough that I don't even try anymore. There are just too many opportunities for it to get forgotten or handled improperly from all directions.
Not as bad as when I was once issued a first.o'last@corp email address though ..
Oh, man, that happened to me too, way back in the late 90s. I had forgotten about that.
It broke things all over the place. Even now you run into the occasional validator that is convinced that the plus sign is not valid in email addresses.
These are intentional IMHO - force people to use their actual email address so a potential breach can't be tied back to the service. That's the only reason why someone would use a + in the first place.
Other reasons folks use + in their email is to do mail routing (except where crappy web services disallow the + because they relied on a crappy regex) but then again I have no idea what "potential breach can't be tied back to the service" is meant to mean.
Easy. Say I subscribe as "username+servicename@gmail.com" everywhere, when I get spam at that email address that service must have been either breached or sold off my data.
I built the authentication system on our website and as a regular user of Gmail + aliasing I was very surprised when my brother pointed out our website didn’t allow them.
Turns out the default for Microsoft’s ASP.NET Identity Framework is to disallow special characters, but simply setting a flag in its configuration rectified this.
In usernames or in name fields for text generally?
I assume things like bank systems can deal with it because they should match things like IDs?
But sometimes I don't have control, e.g. another person is inputting the data and dutifully duplicates my name. That's how I ended up with the 2 phone calls/3 person situation, which happened about a month ago.
Hell, my driver's license is missing the apostrophe because the system doesn't accept it.
When somebody is trying to find me in a computer there's a whole litany of things they have to try, including assuming "First O'Lastame" got bashed into "First O. Lastname".
I think about this every time I read an article extolling the wonders of technology.
So, the reality is that you have to adapt to the country you're trying to live or do business in and the name systems that they can actually use. This can even mean you have to adopt a name that people can actually pronounce, as many Chinese people do when interacting with people outside East Asia
For example, Chinese is particularly sensitive to tone accent, which extremely few people outside that area can even distinguish, leading to hopeless mispronunciation. Consider that Ma2 and Ma4 are completely different words for a Chinese speaker, while a French speaker who hasn't studied this wouldn't even be able to tell that you are intentionally pronouncing things differently and not just your intonation.
And for a reverse example, if you want to move or do business in Japan, you should adopt a well-known Japanese pronunciation of your name, as otherwise Japanese speakers, who have an extremely limited syllable inventory compared to most other languages in the world, will just not be able to follow your name.
There's still a lot of organisations that somewhere in their e-mail processing chain cannnot deal with 4-letter TLD e-mail addresses*. Even worse is that the front-end is often a relatively new framework and will happily accept your e-mail, only to then have it silently fail forever. Mercifully a lot of those organisations have their customer service authorized to change your e-mail address manually, but if they don't.. good luck.
If we're admitting they're poorly-written, why can't we admit that they're already broken regardless of whether that brokenness is currently being triggered? Allowing symbols or spaces didn't break anything, it was broken from day one just no one noticed.
Why is the answer always "go out of your way to not upset the broken garbage that's been around forever" rather than "throw Zalgo at it and fix what breaks so it's no longer broken and won't be broken in the future"?
Bug compatibility is the worst behavior of the computing industry. Let the bad code break and more importantly call it out so everyone knows where the blame belongs.
Same for when people are being too clever and use a password generator with all the characters for things you need to call/pass on some types of config files
No, you're not being smart for adding double quotes to a generated password, in fact quite the contrary. And guess who needs to try all types of escapes for that?!
TFA seems like another of Debian's self inflicted problems by people trying to be "too smart"
While we have more modern shells the fact that bash (or even sh) is the "common denominator" 30 yrs on is both good and awful
We need a PowerShell for Linux
You'd have to be pretty darn important for an org to fix their scripts because of your name or the username you created. Of it would need to happen at a larger scale, but then that wouldn't be so controversial in the first place.