> I would say that a password, at least on the web, should be seen as a Unicode character array, hopefully normalized so that surrogates don't screw things up.
Apparently there is a standard means of doing this; see RFC 7613 ("Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords"). 4.2.2 deals with password normalization (and cites RFC 6943 a little below that, cautioning not to do anything past a certain narrow set of transformations, like turning all non-0x20 spaces into 0x20).
> but no computer works with 21-bit bytes, so you have to pick a character encoding to actually serialize them.
I don't know why you say things like this. It's half-precise and the precise parts are wrong, and the imprecise parts are condescending.
The word size on nearly every general-purpose computing device is 32 or 64 bits. 21 bits fit inside either just fine. (Plan 9's libc uses 21-bit runes; the change is somewhat recent. POSIX libc has wchar_t.) Computers barely work with bytes (check the width of your memory bus and your registers): bytes are a step up the abstraction ladder. (x86 has some byte-level string-handling instructions but they're slow and only kept around for compatibility purposes, I don't think compilers from this century emit them.)
UTF-8 is a convenient method for encoding text on the wire. It doesn't have much to do with the hardware.
> A database containing hashes of passwords should either have some accompanying documentation, or an actual database field, that specifies the character encoding one is supposed to use for the passwords before hashing.
All of these years and all of these stupid encodings and UTF-8 won and now all we have to deal with are regular sequences of bytes and sequences of codepoints and you want to go back to the bad old days. This is a terrible idea and until you volunteer to come to my house to fix the stupid "Shift-JIS interpreted as Windows CP-1252 by someone using Napster in the 90s" mojibake in my ID3 tags, I'm going to have to decline. RFC 7613 should be more than sufficient for webshit.
> A sophisticated RDBMS may even provide built-in support for Unicode strings, and a pwd_hash() function that accepts a Unicode string argument rather than a byte string argument,
Zero hash functions work that way. Your pwd_hash() would just be "Normalize this sequence of characters into a predictable sequence of bytes and then run the actual hash function, which operates on bytes". Please show me the hash function that does not operate on a stream of bytes.
> I don't like it, but it doesn't seem to have introduced any inaccuracy.
> urldecode() { s="${*//+/ }"; echo -e "${s//%/\x}"; }
Well, it works. You could do echo %34+%35 | ruby -rcgi -pe '$_=CGI.unescape($_)' or the equivalent in Perl or something. I usually have irb open somewhere and can bash out something like CGI.unescape(xclip -o) or something like that, or I've got an equivalent in Limbo that I use in Inferno (but it's ~100 lines and I'm maybe only person on fedi that uses Limbo). I don't think I do this very often or I would have probably have written a Plan 9 equivalent (or more likely tried to dig one out of the rc-httpd code) by now.
> why the byte array got so much longer, because I was curious.
Yeah, that's fun.
> who knows how exactly these code points are represented in memory by Firefox.
It's UTF-16. (I wouldn't have been able to extract in-memory strings from the core dump otherwise.)
> If I'm reading the RFC correctly, it would also be legitimate to encode them as UTF-16 before percent encoding,
I'd be surprised if there is a server that accepts that or a browser that creates it.
> it indeed seems to be coincidence that it increased the length by exactly 50%.
Well, it's expected, right? If /dev/urandom is random enough, any bit has an equal chance of being off or on, representation for 0x80-0xFF would be 2 bytes, so you'd expect it to be 50%.
You can't parse HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the trangession of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer's consciousness into a world of ceaseless screaming, he comes~~, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing~~ will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼**OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
@metacpan I’m sorry, but messages addressed to @Perl are no longer reposted to the 492 members of the Perl community that followed it on the #fediverse. There is no longer any point in tagging posts with that address as the owner of https://chirp.social shut it down at the end of February.
You should continue to use the #Perl hashtag, though!
You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the transgression of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
You can’t parse [X]HTML with regex. Because HTML can’t be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the transgression of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer’s consciousness into a world of ceaseless screaming, he comes, the pestilent slithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expression parsing will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮omes he comes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ
Have you tried using an XML parser instead?</center>
I don’t have an actual answer to your question, but imma use the opportunity to let my age show.
Seeing as we’re not on instagram or twitter, and seeing as this space is somewhat more techy than the average platform, could we please do tagging without precomiler instructions (or perl inline comments if that’s more your thing)?
“#” deserves better than being referred to as “the hash tag sign”.
Per quest’anno abbiamo deciso di iniziare in maniera decisamente leggera proponendovi fino da subito uno dei nostri articoli sui Siti belli e basta. Per la precisione è la settimana parte di questa rassegna dedicata ai siti belli che troviamo in giro e che non c’entrano nulla con l’open source o con la privacy. Semplicemente ci sono piaciuti e li abbiamo selezionati per farveli conoscere!
Deposifire, un progetto italiano interessante e attento anche alla privacy (vengono usati LiberaPay per le donazioni e Counter.dev per le statistiche, ad esempio) per aggregare conti depositi e conti correnti;
https://neal.fun/wonders-of-street-view/, Neal.fun ci regala sempre delle perle bellissime. Su questo sito vi basterà fare un reload per vedere un’immagine Street View unica.
https://neal.fun/password-game/, altro gioco folle ma estremamente divertente. Avete presente quei siti che vi chiedono centinaia di bizzarre regole per impostare la password? Regole bizantine che alle volte riescono a rendere le cose piuttosto complicate? Ecco, immaginatelo come gioco.
Back Of Your Hand, quanto bene conoscete il quartiere in cui abitate? Riuscireste a identificare qualsiasi via o piazza?
estoy en demo de uno de los softwares que estoy reparando, y si bien es cierto que ya tronó como chinampina en un par de escenarios, también está llegando en el flujo de su uso más lejos de lo que lo había visto llegar jamás.
Es como ese niño malcriado de la primaria al que le iba hiper mal y de pronto lo ves sacar un 7. Así me siento.
@categulario ¡qué emoción! Me gusta tu tag, me recuerda ese año que me pasé hackeando Perl, haciendo piruetas en torno a un binario del que ya nadie tenía el fuente, pero que estaba en el centro de las operaciones de cierto gran comercio.
Ese era más un hijo perdedor que ya tiene 30 y sigue ahí en su cuarto. ¡Menos mal que no era mi familia!
Hi #Perl people. I would like your advice. I have a project[0] where I have hand-rolled a very simple logging system. It works, but I'd like to replace it with something better, at the worst to teach me more about best practices in Perl logging, at best to have a more flexible system.
My requirements are:
logging to stdout or whatever
when the process finishes (it's running from cron), it puts all logs for that run into a database row so I can see it later, and analyse on common issues.
What I'd like to be able to do:
logs only get emitted to stdwhatever if something happens that's WARN or ERROR (this way I can stop getting email if everything goes fine), but if that happens I want all the logs, including info and debug etc to be emitted.
an option to emit them all in realtime for when I have to run commands by hand so I can get progress info (given the above.)
How would you suggest I improve things? Please feel free to X/Y problem this if you think there's a better way I can approach it. I'm open to all ideas because I want to learn about them.
The bottom line is that there’s no need to roll your own. Each package listed there likely either has options or extensions to do what you want, or can be easily extended yourself.
Two small bugs were exposed by pure chance after #inxi 3.3.31 was released, one was a small #perl error I made in the release, and one has always been around since /sys based temp feature was added. The second has never appeared before and showed literally by pure chance, #mrmazda typed -vs instead of --vs, which tripped sensors on one system that has this issue.
Because this was 1 extra line to fix, and fixing a second, I did a 3.3.31-2 tagged version to make sure the fixed version is master
I‘m an environmental #physicist by training, but after three years of parental leave I started a new job as a consulting software #developer. I work(ed) with a lot of different technologies: #swiftlang, #java, #csharp, #cplusplus, #angular, #perl, … My preferred computing platform is the #Mac.
@heberle Consider following https://chirp.social/@Perl, the hub of the #Perl fediverse community. Followers tag it in their Perl-related posts to boost them to everyone else.
I've had this "CSS Crib Sheet" for probably 15+ years. I can't remember where it came from originally. If You know, please advise so I can add the correct citation.
Also, any #CSS gurus out there care to help me bring it up to speed w/ #CSS3? Even though it's old, some of the tips remain valuable:
@ajaxStardust I appreciate the desire for assistance, and unlike some group admins I’m not going to go on a tear about prohibiting even the slightest breath about another programming language.
But when tagging @Perl do try to keep it related to Perl somehow, even at first. This isn’t a help desk for everything web and programming related just because somebody might know something. I’d like to keep those somebodies subscribed.
@matsuzine@profoundlynerdy If you follow @Perl you’ll get boosts from the 350+ members of the #Perl fediverse community that tag that account, and everything you tag with it will get boosted to them. It’s a great way to learn and ask questions!
@tristan957 Follow @Perl, tag it with any questions as you go, and the 350+ members of the #Perl fediverse community will hear about it and hopefully help!
@Perl when I became Linux Server Amin 25 years ago, I learned Perl. Because I was looking for something beyond Bash and AWK.
I love this script language. Meanwhile I have the feeling that Perl is rather retrocomputing, is my feeling wrong?
Strings do too many things (buttondown.email)
Tales of RegEx: #42 (21 Feb 2017) (programming.dev)
source
**Where** should I discuss _"tagging"_ in websites?
I want to discuss a better means of organizing tags for websites that use a generic tagging system. I propose a tag hierarchy....
Ubuntu 23.10 is out (ubuntu.com)
Release notes:...
Create lightweight, hardened containers with Kubler (lemmy.srcfiles.zip)
cross-posted from: lemmy.srcfiles.zip/post/32334...
Make hardened, lightweight container images with Kubler
cross-posted from: lemmy.srcfiles.zip/post/3841...