I had a program once which failed every time it was 8 or 9 minutes past the hour and worked the rest of the time.
It parsed a string containing the time and sscanf treats "08" and "09" as invalid octal numbers. Argh.
Perl code that is syntactically correct only on Fridays
81–90 of 233 posts
Re: Perl code that is syntactically correct only on Fridays
#82Earlier quoted context omitted.
> Well, to be a little pedantic, Perl cannot be statically parsed, since some constructs require runtime context. If you're going to be pedantic, it's important to be correct; there's no such thing as dynamic parsing. > If it could not be parsed it could never work! What's the logic here? An interpreter doesn't have to operate on an AST, a language doesn't have to have a nontrivial grammar (consider Brainfuck). Perl…
> there's no such thing as dynamic parsing As long as we're indulging in pedantry, this is incorrect presuming dynamic means what it usually means. Any regular expression constructed at runtime contradicts you. Modifying your core parser at runtime though, who would do such a thing? Other than reader macros in Common Lisp I mean. Are we going to argue this means Common Lisp doesn't parse if we add reader macros at ru…
> Modifying your core parser at runtime though, who would do such a thing?
Perl? Its numerous language extensions allowed it to stay competitive for such a long time. Every time someone says "language X can do Y but Perl doesn't have that syntax", a new CPAN module is born to amend the shortcoming.
Re: Perl code that is syntactically correct only on Fridays
#83Why only things like these float up to the front page, and not elegant and/or wholesome things written in Perl?
Because with its declining popularity, most people here are unfamiliar with the language except for its meme status as "that weird line noise language". Things that confirm pre-existing beliefs are easy to accept and upvote, whereas good Perl code would require (a) some actual thinking, and (b) challenging the socially accepted narrative - both of which are relatively much harder.
True, most Gen-Z ers know nil.
First they should try Perl as if it was a tuned up AWK, and then, read the Orelly Perl books as if they were a religion.
Re: Perl code that is syntactically correct only on Fridays
#84Earlier quoted context omitted.
Bash parses as it runs so something as simple as this works if [ $(date +%u) -ne 5 ] then exit fi (
Bash even reads the file as it goes, so if you run a "long-running" script (a sleep is enough), edit far enough down, and write the file again, the previously started bash will end up running the new content once it gets up to reading where the change happened.
You can exploit it do distinguish whenever script is `curl | bash`'ed.
Add `sleep 1`, and detect pause on server. Then, if pause detected - serve attack payload. If not - somebody is careful enough to download and audit, so serve just the script.
Re: Perl code that is syntactically correct only on Fridays
#85Earlier quoted context omitted.
Most other languages would require `eval` and having incorrect code as syntactically correct string literal. But because Perl is parsed as it is executed, incorrect code raises syntax error only when it is reached by execution.
>incorrect code raises syntax error only when it is reached by execution. That's not generally true for Perl. The BEGIN block is used to get in that state here. "Some incorrect code raises syntax error only when it is reached" is true. It's generating this on Fridays: &f() / 1; And this on other days: f(/1;#/+); If you run the same code, but without BEGIN blocking the assignment to *f, it isn't incorrect code. It eva…
What happens if you run this code in a loop Thursday night just before Friday?
Does the parse that happens on Thursday take precedence or is it reparsed every single time through the loop?
Re: Perl code that is syntactically correct only on Fridays
#86Earlier quoted context omitted.
Thank you for this. I hate trying to read Perl so much. What is the "#/+" for?
Worked as a Perl dev for 15 years and enjoyed it. The hardest thing was the number of ways to do OO Perl using Perl5. Everyone has their own flavor. And TMTOWTDI was a motto the community was proud of. Having said that, nothing could touch mod_perl performance under Apache in the late 90s. Massive web apps were built on this including eToys dot com where I worked before it imploded in the dot-com bust.
> Worked as a Perl dev for 15 years and enjoyed it. The hardest thing was the number of ways to do OO Perl using Perl5. Everyone has their own flavor. And TMTOWTDI was a motto the community was proud of.
One of my frist dev jobs was slinging perl script, I loved that attitude and it made for a fantastic learning environment. I really dislike the feeling of having to write code in a straightjacket because tHe TeAm CaN't UnDeRsTaNd iT!!!
We minimized the negatives of TMTOWTDI by incorporating a house style, but it was flexible because we were all smart people whose minds didn't crash because we saw a statement we didn't expect.
Re: Perl code that is syntactically correct only on Fridays
#87I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.
I had a coworker working on a data-pipeline sort of thing once. They for some reason wrote their own date parser (Akamai logs) and used a regular expression to find the month. For whatever reason, the RegExp didn't work for March (I think) and so at midnight 1 March the year of first deploy, we started dropping all the logs as un-parseable (causing the NOC to think the traffic had gone to 0 or our system was buggy). We all got paged and eventually figured out it. It had been running in live for several months without problems at that time.
Re: Perl code that is syntactically correct only on Fridays
#88Earlier quoted context omitted.
Personally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.
This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?
Re: Perl code that is syntactically correct only on Fridays
#89Earlier quoted context omitted.
>incorrect code raises syntax error only when it is reached by execution. That's not generally true for Perl. The BEGIN block is used to get in that state here. "Some incorrect code raises syntax error only when it is reached" is true. It's generating this on Fridays: &f() / 1; And this on other days: f(/1;#/+); If you run the same code, but without BEGIN blocking the assignment to *f, it isn't incorrect code. It eva…
What happens if you run this code in a loop Thursday night just before Friday? Does the parse that happens on Thursday take precedence or is it reparsed every single time through the loop?
The BEGIN block only runs once. That is:
while (1) {
BEGIN {print "hello\n"}
sleep 1;
}
You could loop inside the BEGIN block and then drop out of the loop at some point. If you dropped out on friday, after the code assigning *f, it would run correctly. So:
BEGIN {
sleep 86400;
*f = (localtime->wdayname eq 'Fri')
? sub() {}
: sub {};
}
f/1;#/+
Re: Perl code that is syntactically correct only on Fridays
#90Why only things like these float up to the front page, and not elegant and/or wholesome things written in Perl?
I loathe perl still (based on having to SSH (or telnet?) into people's systems and debug their perl scripts in the 90s) but, Higher Order Perl, https://hop.perl.plover.com/ is a truly excellent introduction to the power of functions that generate functions, more accessible and more immediately useful than Paul Graham's On Lisp. The lessons are immediately applicable at least to Javascript and Python. Strongly typed things like Go make it a bit more work, but still you'll understand why the work is worth doing.