• (cs)

    I got as far as the substitution of "www.thecompany.com" for "inetpub" and was wondering where the WTF was. Had I missed it? I scrolled down to the next line of code and WHAM!

    It was like keeping my head focused on the pavement as I walked around (watching for the odd dime or nickel) and smashing my skull into the brick wall I had completely not seen. Damn, that hurt.

  • Erik (unregistered)

    I can only assume that all of the Perl code (as simple as it is) was generated by cutting and pasting various lines of code found on the web, because I can't think of any other explanation why you would need to use some canned script in ASP rather than using Perl to send email. Sending email in Perl is dead simple, even if you don't know about any of the modules designed to do exactly that.

  • (cs)

    There's plenty of Real WTF to go around here but does it bother anyone else when the see stuff like:

    DEFINE VARIABLES

    or

    // GETTERS ///////////////////////////

    or

    /**** DATABASE STUFF *************************/

    If you're using comments like this to break up your code you probably need to either:

    1. Step up to a real IDE that lets you navigate through code easily.
    2. Split this guy up into more classes because it's doing too much. ( 3) ??? 4) Profit etc etc)

    I guess it looks good when you're first writing the code but it doesn't hold up after the first refactoring.

  • use Table::Wooden qw( :VBScript); (unregistered)

    It's OK. I have fixed this script. Please see below.

    print "Content-Type: text/html\n\n";


# parse form 

read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
    ($name, $value) = split(/=/, $pair);
    $value =~ tr/+/ /;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    $FORM{$name} = $value;
}

# Define variables ###########################################


$quiz_name = $FORM{'quiz_name'};
$my_score = $FORM{'my_score'};
$email = $FORM{'stu_email'};
$name = $FORM{'stu_name'};
$prof_email = $FORM{'prof_email'};
# $email_message = "$answ";
$message = 'mailer_d_alt.asp';
$answ = $FORM{'answ'};
$new_answ = $answ;
$new_answ =~ s/"//g;
$new_answ =~ s/\n/\" \& vbcrlf \& \"/g;
$new_answ =~ s/\r//g;
$final_answ = "(\"$new_answ\")";
$final_page = $FORM{'final_page'};
$final_page =~ s/\\/\//g;
$final_page =~ s/e://g;
$final_page =~ s/\/Inetpub\/wwwroot/http:\/\/www.thecompany.com/ig;
# $final_page =~ s/\/inetpub\/wwwroot/http:\/\/www.thecompany.com/g;
$page = $final_page;



# Print asp page that will process and mail quiz response
#   NOTE: this seems a little ridiculous to me. why are we even using this 
#         script if all it's going to do is just create another script? 
#         -- XXXX XXXX, 2003-10-17
open(FILE,">$message") || print "Error: Could not create temporary file.";
print FILE "<\%\n";


# The comment above is correct. This is the scalable solution.

use Win32::OLE;
$cd = Win32::OLE->new("CDONTS.NewMail") || die $!;
$cd->{From}="$name <mailer@thecompany>";
$cd->{To}="$email";
$cd->{Cc}="$prof_email";
$cd->{Subject}="Results for $quiz_name";
$cd->{Body}="$final_answ";
$cd->Send;

  
print FILE "response.redirect strPage\n";
print FILE "response.end\n";
print FILE "\%>";
close FILE;


# mail.BodyFormat = MailFormat.Html\n

print "<HTML><HEAD><META HTTP-EQUIV=\"Refresh\" CONTENT=\"1;";
print "URL=http://www.thecompany.com/scripts/mailer_d_alt.asp\">";
print "<TITLE></TITLE></HEAD><BODY></BODY></HTML>";
  • (cs)

    Why do people have to make sending an email so friggin complicated?

  • (cs) in reply to Outlaw Programmer

    I've seen the code fragment at the top before, including the Define Variables line, but I don't remember where.

    I know the form parsing code was actually a pretty common code block in its time, though.

  • Scott (unregistered)

    It looks remarkably like something an old boss of mine might have done...

  • (cs) in reply to dpm
    dpm:
    I got as far as the substitution of "www.thecompany.com" for "inetpub" and was wondering where the WTF was. Had I missed it?

    That says something about you.

    I wonder where this script is being used, that it's okay to completely blow up if two web users submit emails at the same time. (I assume the generated page is called *_alt_d because alt_a, alt_b, and alt_c are used on some other page.)

    The real head scratcher is how did somebody have the mental capacity to dream up this rube goldberg design, but didn't have the sense to consider refactoring?

  • (cs)

    I can sometimes see the point of doing this sort of thing with one server- and one client-side language. But wtf is to be gained from using 2 server side? I despair

  • (cs)

    NOTE: this seems a little ridiculous to me.

    Step 1 of the 12 step program.

  • glwtta (unregistered)
    This method was used time and time again, leaving several of the Perl scripts to accept a form submission, initiate another HTTP connection from the server, and then submit the same form values to the ASP page.
    What on earth is wrong with that? If you'd rather only manage a single MTA, that's a perfectly reasonable thing to do (they call them "Web Services" these days).
  • (cs)

    Around early 2001, at my first programming job out of high school, I wrote my own SMTP queue in VB using winsock, and a COM control for adding mails to the queue, for use in a website I was building in ASP. After I got it all working well, and showed it off to my coworkers, one of them asked, "Why didn't you just use CDONTS?"

  • (cs) in reply to savar
    savar:
    dpm:
    I got as far as the substitution of "www.thecompany.com" for "inetpub" and was wondering where the WTF was. Had I missed it?

    That says something about you.

    What, pray tell, does it say? Up to that point there is just normal sloppy Perl code, nothing that should make an experienced programmer shout "what the fsck?!?". Grimace, yes, but no real WTF.

    I wonder where this script is being used, that it's okay to completely blow up if two web users submit emails at the same time.
    That was the first thing that smacked my virtual forehead. It wasn't the last.
  • (cs)

    I'm embarassed for the amount of bad Perl code that has gotten out there over the years, when in fact, there's also a lot of good enterprise-grade Perl software running our networks and major websites and mom-and-pop shops as well. It really gives Perl a bad name. Perl was a bit too easy to use... deceptively so, so that people who were not professional programmers could actually think they could accomplish something. That was Perl's Achilles Heel... that it could be used by quasi-programmers.

  • SomeCoder (unregistered) in reply to realmerlyn
    realmerlyn:
    I'm embarassed for the amount of bad Perl code that has gotten out there over the years, when in fact, there's also a lot of good enterprise-grade Perl software running our networks and major websites and mom-and-pop shops as well. It really gives Perl a bad name. Perl was a bit too easy to use... deceptively so, so that people who were not professional programmers could actually think they could accomplish something. That was Perl's Achilles Heel... that it could be used by quasi-programmers.

    I agree and the same could be said for VB, VBScript (which includes MS Access), PHP, etc. Even C# to some degree.

    I'm not saying we should get rid of all these languages. However, easier programming languages help the industry, but it's a bit of a double edged sword as well.

  • (cs)

    One Script to rule them all, One Script to find them, One Script to bring them all and in the darkness bind them.

  • Slater (unregistered)

    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

  • (cs)

    Nevermind the glaring WTF - this is a huge security hole! With a hand crafted form one could write an entire asp script to do whatever you want on the web server!

  • Brad (unregistered)

    The scary thing is.. we have a program here that does precisely the same thing, only its written in VB6 and generates ASP instead of Perl to ASP.

  • Anon (unregistered) in reply to Slater
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.
    Huh? If you're talking the $scalar, @array, %hashtable, &function, *retarded, or BRAINDEAD notation, that's part of the Perl language. Otherwise, what are YOU smoking?!
  • Soviut (unregistered) in reply to SomeCoder
    SomeCoder:
    realmerlyn:
    I'm embarassed for the amount of bad Perl code that has gotten out there over the years, when in fact, there's also a lot of good enterprise-grade Perl software running our networks and major websites and mom-and-pop shops as well. It really gives Perl a bad name. Perl was a bit too easy to use... deceptively so, so that people who were not professional programmers could actually think they could accomplish something. That was Perl's Achilles Heel... that it could be used by quasi-programmers.

    I agree and the same could be said for VB, VBScript (which includes MS Access), PHP, etc. Even C# to some degree.

    I'm not saying we should get rid of all these languages. However, easier programming languages help the industry, but it's a bit of a double edged sword as well.

    That's what people said about the camera when it was first introduced to the public. "Nobody will paint anymore, they'll just take a photo". But like anything, the good photographers float to the top; the wheat DOES separate from the chaff.

  • (cs) in reply to Slater
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

  • LukeG (unregistered) in reply to Anon
    Anon:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    Huh? If you're talking the $scalar, @array, %hashtable, &function, *retarded, or BRAINDEAD notation, that's part of the Perl language. Otherwise, what are YOU smoking?!

    I think slater is referring to

    The One Script:
    ...
print FILE "Dim objCDO\n";
print FILE "Dim strFromName\n";
...
    etc
  • awfawef (unregistered)

    I'd go to Mordor and throw The One Script into the fires.

  • Franz Kafka (unregistered) in reply to DeLos
    DeLos:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.

  • Jesse Donat (unregistered)

    We've got a different mailer script for almost every site, though many of them are identical

  • Chad M (unregistered)

    The first thing that caught my eye was actually this: "the Web folks mostly do non-technical like designing websites, creating simple databases, and configuring web servers." Since when was creating databases and configuring servers not technical? Granted it's not the hardest task in the world, but it does still take some knowledge to pull off.

    Of course, I work in a shop where people think being a web developer just means I'm "FrontPage Certified". sigh Some day us web devs will get the respect we deserve.

  • Anon (unregistered) in reply to LukeG
    LukeG:
    I think slater is referring to [the generated VBScript]
    Oops, oh, right, that. I managed to see that the Perl script was generating an ASP file but missed that there was VB in it. Heh. And the Hungarian notation as used in the VB in the ASP is totally worthless.
  • Andrew (unregistered) in reply to powerlord
    powerlord:
    I've seen the code fragment at the top before, including the Define Variables line, but I don't remember where.

    I know the form parsing code was actually a pretty common code block in its time, though.

    In the ancient Web days, that form parsing code was pretty common. Perl4 programmers used pack() to parse a query string. Proper modules, like CGI.pm are Perl5 features.

    It looks like someone searched for Perl CGI, and got an old-style code fragment.

  • J (unregistered) in reply to Franz Kafka

    Good variable names==good programming practice, regardless of what notation you prefer. Hungarian requires you to specify your data type, but people who choose good variable names with it will choose good variable names without it (same with bad). While I'd rather dig through bad code with Hungarian than bad code without, Hungarian doesn't make code worse.

    Personally, the only reason I like Hungarian notation is for use with intellisense when I can't remember exactly what I named a variable. I just type in the prefix and I can immediately see which one it is.

  • Andrew (unregistered) in reply to glwtta
    glwtta:
    This method was used time and time again, leaving several of the Perl scripts to accept a form submission, initiate another HTTP connection from the server, and then submit the same form values to the ASP page.
    What on earth is wrong with that? If you'd rather only manage a single MTA, that's a perfectly reasonable thing to do (they call them "Web Services" these days).

    The ASP (IIS?) server is another web server, not a Mail Transfer Agent! The Perl script sends control back to the web client which must repeat the request.

    Anyone can write a short Perl script to send an E-mail to a Mail Transfer Agent with or without any webserver. E-mail existed just fine before the Web.

  • (cs)

    I suppose the title of the site invites people to criticise, rather than make a constructive comment. However, there's really nothing wrong with this.

    I've tried embedding SMTP in C/C++ using Perl, and I've tried it using Python. With Perl, I haven't found a module that's significantly better than back-quotes or a system call. Even Python is a bit of a pain (although an elegant pain). Both of them fall down on the basic premise of sendmail:

    clively:
    Why do people have to make sending an email so friggin complicated?
    Because it is. But it shouldn't be. See http://research.microsoft.com/~daniel/unix-haters.html.

    It's just like that. Wanna send mail through your local servers? Naw, you've got to persuade the sysadmins to allow you to redirect. Good luck on that. The whole system is a god-awful 1970's mess, and needs a redesign, right now.

    Given that, I have no problem with using ASP and (hawk, spit) Visual Basic. You pick the tools that are available Me, I'd have used a "here-doc," but that's just syntactic sugar.

    So, tell me again. What's wrong with this little snippet? And how would you make a significant improvement?

  • Rich (unregistered)

    I see a wtf that most people haven't commented on. This script assumes POST, though, depending on the webserver config, GETs may also be allowed. In that case, you'd either get a DOS attack (if the perl instances just hung around waiting for input never to come) or the script logic would totally blow up because the non-existent variables are never checked for existence. This is a specific case of the general "trust all inputs from client, what could possibly go wrong" of the script.

    As far as sending email goes, MIME::Lite is a fairly common module and isn't that hard to use. It does need a SMTP server though, but then at least the IT guys could maintain it.

  • (cs) in reply to real_aardvark
    real_aardvark:
    I suppose the title of the site invites people to criticise, rather than make a constructive comment. However, there's really nothing wrong with this.

    Of course then there are the people that come here to laugh at the post while not understanding it and assuming if they don't laugh at it other people will think they aren't smart enough to be here.

    What a culture we have created huh? I'm leaving my fire retardant suit off because I want to get a head start on this summer's tan.

    Helpdesk girl forever; she even has a tattoo.

  • (cs) in reply to Franz Kafka
    Franz Kafka:
    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.
    Well that is what I meant to say, unfortunately not as eloquently as you did. However my point remains, it still makes it easier to read others code.
  • (cs)

    I prefer Austro-Hungarian notation.

  • Offf (unregistered)

    Maybe this script was written by an old DOS batch programmer (if there is such thing). Generating a batch file within batch file and then callign it was a pretty common technique to work around command.com's absolute clumsyness.

  • Crash Magnet (unregistered)

    which method is a wtf?

    1. vbs -> perl -> email
    2. vbs -> vbs -> email
    3. perl -> vbs -> email
    4. perl -> perl -> email
    5. perl -> .txt -> printer -> wooden table -> digital camera -> paper envelope -> us mail
    6. None of the above

    There are more possibilities, but I can't bring myself to enumerate them all.

  • WTF yourself (unregistered) in reply to Rich

    WTF yourself. If there's nothing on STDIN, there's nothing on STDIN. A CGI program doesn't wait for input, it just reads it (and should read up to Content-Length and stop). A proper CGI library like CGI.pm would make it all moot, so the advice would be to just use what's out there until you can do better for your specific task.

  • anon (unregistered)

    Not to start any flame wars here (the news groups are for that) but I've never had a problem parsing without cgi.pm - a habit I got into back in the day when it would break Flash e cards (don't ask, I needed the money). I also wish perl hadn't passed out of buzz-word-dom as I still prefer it to PHP but suggesting it instead of PHP is a great way to get a blank stare before losing a bid for non-buzzword compliance. I've had to say 'XML' about twenty times to dig myself out of that hole recently.

    captcha: validus wikipedia: A fictional DC comics bad guy.

  • Congo (unregistered) in reply to J
    J:
    Good variable names==good programming practice, regardless of what notation you prefer. Hungarian requires you to specify your data type, but people who choose good variable names with it will choose good variable names without it (same with bad). While I'd rather dig through bad code with Hungarian than bad code without, Hungarian doesn't make code worse.

    I agree always us i, j, k for integers and start a$ through g$ for strings.

  • Congo (unregistered) in reply to J
    J:
    Good variable names==good programming practice, regardless of what notation you prefer. Hungarian requires you to specify your data type, but people who choose good variable names with it will choose good variable names without it (same with bad). While I'd rather dig through bad code with Hungarian than bad code without, Hungarian doesn't make code worse.

    I agree always us i, j, k for integers and a$ through g$ for strings.

  • JAlexoid (unregistered)

    Wow! That script looks incredibly familiar... I think the last piece of code that I wrote with Perl without CGI in 1998... This brings back memories....

  • (cs) in reply to Crash Magnet
    Crash Magnet:
    5) perl -> .txt -> printer -> wooden table -> digital camera -> paper envelope -> us mail
    You forgot " -> scanner -> jpg -> ocr"
  • use Table::Wooden qw( :VBScript) (unregistered) in reply to real_aardvark
    real_aardvark:
    So, tell me again. What's wrong with this little snippet? And how would you make a significant improvement?

    Hmm...

    • You might use the CGI module, as it's not 1996 any more

    • As a result, you could then avoid using that antediluvian hairball of code to interpret the client request

    • You could maintain application state on the server, rather than passing lots of hidden form fields, many of which need likely never go near the client, through multiple client requests

    • You could properly check and sanitize inputs, rather than allowing the script to be used as a spam gateway for the rest of the world

    • You might want to use e.g. Mime::Lite to send the mail message. You already have SMTP running to make CDONTS work, so this will work. However, unlike CDONTS, you don't need SMTP running on the same box as IIS

    • You could display whatever you wanted to display to the user as a result of the submission, rather than having to redirect them twice

    • You might want to limit the number of programming languages and technologies involved in this trivial task beyond one

    • You would perhaps try to avoid creation of an unnecessary file to do something that is completely unnecessary

    • Even if you did do that, for some extraordinary reason, you might want to avoid writing to a "temp" file with the same name each time, leading to concurrency issues

    • Even if you were dumb enough to do that, you might want to avoid client-side redirects to send the user to the temp file, although this would be the very least of your worries

    Apart from that it's a pretty good solution though.

  • Robin Goodfellow (unregistered)

    The real WTF is the use of form mailers in the modern age. Often times these can be hijacked by 3rd parties and used as SPAM relays. This is because most form mailers are poorly written and don't contain adequate safe guards against being used to send arbitrary data or being used to send email to arbitrary addresses.

  • SomeCoder (unregistered) in reply to Soviut
    Soviut:
    SomeCoder:
    realmerlyn:
    I'm embarassed for the amount of bad Perl code that has gotten out there over the years, when in fact, there's also a lot of good enterprise-grade Perl software running our networks and major websites and mom-and-pop shops as well. It really gives Perl a bad name. Perl was a bit too easy to use... deceptively so, so that people who were not professional programmers could actually think they could accomplish something. That was Perl's Achilles Heel... that it could be used by quasi-programmers.

    I agree and the same could be said for VB, VBScript (which includes MS Access), PHP, etc. Even C# to some degree.

    I'm not saying we should get rid of all these languages. However, easier programming languages help the industry, but it's a bit of a double edged sword as well.

    That's what people said about the camera when it was first introduced to the public. "Nobody will paint anymore, they'll just take a photo". But like anything, the good photographers float to the top; the wheat DOES separate from the chaff.

    That's not really the best analogy for this situation. I'm just saying that having really low barrier programming languages can encourage people to code who have no business coding. And - if this site is to be believed - the chaff tends to float the top as management, causing more WTFs.

    Again, this isn't an argument for removing easy programming languages, but it is definitely a concern.

  • GF (unregistered) in reply to Franz Kafka
    Franz Kafka:
    DeLos:
    Slater:
    God, I hate Hungarian Notation. What a horrible, horrible crutch for a young programmer to take up. It's as bad a smoking, really.

    I disagree. It is quite useful when you are looking at other people's code. It can help guide you into the other person's thought process and figure out what variable do.

    I redisagree. hungarian notation as it's used is worthless and can be an impediment if datatypes have been changed without updating variable names. Proper hungarian notation means decorating names with app-level info about what the variable represents, not the datatype.

    Ah, the old "what if the data type changes" argument. You know, in 15 years of professional programming, I think I've seen that maybe 5 or 10 times. The benefits of Hungarian notation 'as it's used' far outweigh the supposed 'risks', especially when you're trying to scan through unfamiliar code.

    Here's a secret - it doesn't even matter what the prefixes are, as long as they're consistent with each other. Though I guess if you're tripped up by Hungarian, that concept may be too much..

    captcha: abico, usage: abico-ld on this chilly night.

  • GF (unregistered) in reply to anon
    anon:
    Not to start any flame wars here (the news groups are for that) but I've never had a problem parsing without cgi.pm - a habit I got into back in the day when it would break Flash e cards (don't ask, I needed the money). I also wish perl hadn't passed out of buzz-word-dom as I still prefer it to PHP but suggesting it instead of PHP is a great way to get a blank stare before losing a bid for non-buzzword compliance. I've had to say 'XML' about twenty times to dig myself out of that hole recently.

    captcha: validus wikipedia: A fictional DC comics bad guy.

    Actually, mentioning 'perl' or 'php' for any large-scale job will lose you a contract with me. For small utility scripts, quick-n-dirty work, they're both great. For batch processing, perl is awesome. But for maintainability? The only thing worse than PHP is perl. Or maybe I've simply just never stumbled across any well-written perl/php.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Even Python is a bit of a pain (although an elegant pain).
    "Elegant pain"? Sounds sexy. Perhaps I should look into this Python thing.

Leave a comment on “The One Script”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article