51–60 of 128 posts
(This isn't a "look how cool command line junkies are" comment; I was just musing.)
On Linux, how could you make standard tools highlight or differentiate potentially misleading characters? I guess the solution would have to be in the terminal emulator? Would a blacklist of Unicode ranges be sufficient?
od -h -- I used to run into this problem a lot when I was writing grammars against different locales
I'm wondering if there's a way to make it more obvious that doesn't require running od. It should be immediately apparent any time there's a file with a whacky name, not something you find out two minutes into investigating a compromise.
I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ppa.emorhCelgooG
The solution was to implement a regex of whitelisted characters; since it's an English-only program, this works well and is future-safe. For multiple languages, a blacklist is probably okay, but the difficulty lies in keeping the blacklist both complete and up to date.
Earlier quoted context omitted.
Since Windows by default don't show hidden files, I must say that most of my engineer coleagues would fall in the trick. Sadly, most people that I worked open the files manually.
How is the real hosts file rendered hidden in Explorer?
Earlier quoted context omitted.
Are you sure? curling from Terminal, I get the same result.
That's probably because your terminal interprets the RLO character. Should it? I'm not sure.
I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ppa.emorhCelgooG
Earlier quoted context omitted.
That's a clever idea, but I don't know how one would determine what "unexpected" is an increasingly international world.
Code point has script property and mixing it inside strings which aren't likely to contain multiscript code points (like filenames) is a sign of trouble.
E.g.: "Архив.gz" (Archive.gz)