• ChiefCrazyTalk (unregistered)

    As Paula would say - "Brillant!"

  • [p] (unregistered)

    [:P]

  • (cs)

    Couldn't he have just used backticks to get the result of the date command.


    $thedate = date;

  • JC (unregistered)

    The good thing about this is that when the code doesn't work on windows, the coder can simply blame microsoft's "Stupid incompetent programmers" and claim that they did something non-standard to lock out the competition! :D

  • (cs)

    Wow, I'm not nearly smart enough to come up with something like that.

    I like the naming convention too. the.date, <THEDATE>
    Does he have a separate function to figure out the.time?

    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.

  • (cs) in reply to ferrengi
    ferrengi:
    Wow, I'm not nearly smart enough to come up with something like that.
    <thedate>
    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.


    A funny reply, but not correct.  Not that the path starts with '/' (as in /tmp).  This assumes a UNIX like system which has a /tmp directory that anybody can write to.  What could happen is that different users create the file with different permissions and the routine fails because the file already exists and is owned by another user that prevented world write.
    </thedate>
  • Terps (unregistered)

    Why not just use the localtime() function?  It returns the same as the UNIX date except it lacks the 3 letter code for the which time zone.

     

  • Colin (unregistered)

    Should have created a tempfile(), dumped the stat(2) output to a file, and then parsed that.

  • boohiss (unregistered) in reply to ferrengi

    Using 'theDate' or 'theTime' as a variable/file/etc name isn't a WTF, since 'Date' and 'Time' are often reserved words in many languages.

  • (cs)

    time()? feh, localtime().

  • (cs) in reply to boohiss
    Anonymous:
    Using 'theDate' or 'theTime' as a variable/file/etc name isn't a WTF, since 'Date' and 'Time' are often reserved words in many languages.


    Not a WTF just funny. He didn't use theDate, he used the.date
    Isn't that a little strange?
    If I must write my program this way, what's wrong with $today or something like that?
  • (cs)

    Heh, I did something similar on an asp webpage with the windows "ping.exe" awhile back to ping machines to see if they were up.  With 16 pings took about 50 seconds to load the page.  Pretty useless considering the page refreshes once every 60 seconds.

     

    ....Then I discovered the wonders of wScript.Shell's Exec method.

     

    Funny story about what happened in between those two events.  I tried messing around with winsock dlls to ping the machines.  It worked out pretty well as far as I could tell.  Well the same page also had a potential race condition on an unrelated portion of code so I put up about 10 copies of the page on two different computers, each page pinging about 16 machines, all set to refresh once per minute.  This is about at 9 in the morning.  Around 2 in the afternoon my boss gets a call from the head of our company's telecommunications division.  It seems their external firewall was seeing a massive increase in traffic all trying to find 192.168.0.123.  This was especially odd as our corporate network uses routers that use a 10.100.x.x standard for ip addresses.  The head of telco was able to track it to our division so he was trying to figure out what the hell was going on.  Well the webserver hosting the page that was doing all the pinging had two network cards, one for the plant network and one for a private network.  One on the corporate network with a 10.100.x.x type and one with, what else, 192.168.0.123.  Turns out that somehow the machine was broadcasting messages on the corporate network with the wrong ip address.  All the machines that saw the message passed the message on because it couldn't recognize the ip address and eventually all the messages tried to get routed out through the corporate firewall.  The security report for the firewall, which was normally about half a page to a page for a single day, was at about 4 pages by 2 pm.  So yea....not going to be messing around with winsock around here anytime soon.

  • buu (unregistered) in reply to sinistral
    sinistral:
    ferrengi:
    Wow, I'm not nearly smart enough to come up with something like that.
    <thedate>
    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.


    A funny reply, but not correct.  Not that the path starts with '/' (as in /tmp).  This assumes a UNIX like system which has a /tmp directory that anybody can write to.  What could happen is that different users create the file with different permissions and the routine fails because the file already exists and is owned by another user that prevented world write.
    </thedate>


    Note that this is not correct, any windows higher than'nt' will accept slashes as path delimiters. /foo would refer to the currentdrive, usually c:\foo.     
  • (cs) in reply to ferrengi
    ferrengi:
    Anonymous:
    Using 'theDate' or 'theTime' as a variable/file/etc name isn't a WTF, since 'Date' and 'Time' are often reserved words in many languages.


    Not a WTF just funny. He didn't use theDate, he used the.date
    Isn't that a little strange?
    If I must write my program this way, what's wrong with $today or something like that?


    I don't like using the, so whenever I do something like this, I use "da"... Resulting in daDate and daTime ;-)
  • (cs) in reply to sinistral
    sinistral:
    ferrengi:
    Wow, I'm not nearly smart enough to come up with something like that.
    <thedate>
    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.


    A funny reply, but not correct.  Not that the path starts with '/' (as in /tmp).  This assumes a UNIX like system which has a /tmp directory that anybody can write to.  What could happen is that different users create the file with different permissions and the routine fails because the file already exists and is owned by another user that prevented world write.
    </thedate>


    Didn't know that. So in UNIX everyone shares a global /tmp directory? In that case, the file would get created by user A, and then when user B runs the program, creating the file will not work because it already exists (unless this code will replace the existing file automatically).

    Either way, I find it surprising that the "programmer" that invented this didn't say to himself something like:

    There is a quite a bit that could go wrong if I write the program this way, maybe I should do a little research or ask someone if there is a better way.

  • blob (unregistered)

    meh, not that bad, my guess is the guy wasn't that familiar with perl but had to write a "temporary" program that ended up living longer than expected

  • Hmm (unregistered) in reply to ferrengi

    Either way, I find it surprising that the "programmer" that invented this didn't say to himself something like:

    There is a quite a bit that could go wrong if I write the program this way, maybe I should do a little research or ask someone if there is a better way.

    And there you go, the difference between a programmer and an analyst.
  • mcguire (unregistered) in reply to ferrengi

    Creating the file will work (and overwrite the file (Can you say "race condition"?)) if the permissions on the file from user A allow it.  If not, it'll just blow chunks all over the floor.

    What is this "say to himself" stuff?  Would you do that?  Would anyone?  Geez, if I don't know something, no one else will either, right?

  • (cs) in reply to ferrengi
    ferrengi:
    sinistral:
    ferrengi:
    Wow, I'm not nearly smart enough to come up with something like that.
    <thedate>
    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.


    A funny reply, but not correct.  Not that the path starts with '/' (as in /tmp).  This assumes a UNIX like system which has a /tmp directory that anybody can write to.  What could happen is that different users create the file with different permissions and the routine fails because the file already exists and is owned by another user that prevented world write.
    </thedate>


    Didn't know that. So in UNIX everyone shares a global /tmp directory? In that case, the file would get created by user A, and then when user B runs the program, creating the file will not work because it already exists (unless this code will replace the existing file automatically).

    Either way, I find it surprising that the "programmer" that invented this didn't say to himself something like:

    There is a quite a bit that could go wrong if I write the program this way, maybe I should do a little research or ask someone if there is a better way.



    Yes, the /tmp directory is world writeable; all users can write to it and create files.  If user A creates a file and makes it world writeable, user B can run this script and it will work.  The file will still be owned by A, but will have the date of when B ran it.  If A didn't make the file world writeable, nobody (but root) can overwrite the contents.  Which goes along with what you're saying... lots can go wrong.

    As another poster pointed out, on NT and later Win 32 systems, you can use '/' as a path separator, and the current drive will be assumed.  So, unless you have a X:\tmp, this will again fail (where X is any drive you may currently be on).

  • (cs)

    Not too unusual for Perl, unfortunately. You get so used to pulling info from shell commands, it becomes second nature to do it inside a Perl script.

    Why in Gods name he put it into a FILE though, I'll never know. There are a dozen better ways to do that, that don't leave random files lying around with cryptic crap like the date and nothing else in them.

  • (cs) in reply to Hmm
    Anonymous:

    Either way, I find it surprising that the "programmer" that invented this didn't say to himself something like:

    There is a quite a bit that could go wrong if I write the program this way, maybe I should do a little research or ask someone if there is a better way.

    And there you go, the difference between a programmer and an analyst.



    For me, whenever my thought process turns to something like, "Write this out to a file, then read it right back in from the file, and discard the file..." I know I'm moving into Rube Goldberg territory, and it's time to go get a soda, and check CPAN to see how other people did it.

    Lot of Perl code is written under stress though, so you see some wild stuff.

  • Matt (unregistered)

    If you're going to bother issuing a system command to get the date, why not pipe it its output with Perl's excellent IPC capabilities... this temporary file, thing is just silliness (of course, so is using a system call to get the date).

  • Michael Reitzenstein (unregistered)

    Obviously the real way to do this is to create the file and read back its creation date.

  • Seltsam (unregistered) in reply to Michael Reitzenstein

    Yeah...he could have called "touch /tmp/wtf_file" and then read in the file's ctime!

  • anonymous nobody (unregistered) in reply to Kooch
    Kooch:
    Couldn't he have just used backticks to get the result of the date command.

    $thedate = date;

    No, that's a bash feature. The code was probably meant to be generic (as in portable, platform agnostic) ;)

  • Somebody (unregistered) in reply to anonymous nobody

    No it isnt, try that on windows, and it will work.

  • foo (unregistered) in reply to SeekerDarksteel
    SeekerDarksteel:

    Heh, I did something similar on an asp webpage with the windows "ping.exe" awhile back to ping machines to see if they were up.  With 16 pings took about 50 seconds to load the page.  Pretty useless considering the page refreshes once every 60 seconds.

     

    ....Then I discovered the wonders of wScript.Shell's Exec method.



    That's why man invented nagios. 8-|
  • teambob (unregistered)

    Surely the real WTF is that someone wrote some perl code that could be deciphered. :)

    Don't get me wrong I use perl constantly but sometimes...

  • (cs)

    <FONT face=Georgia>Perls programmers just bust a nut ( [:P] )whenever they find the opportunity to read/write to files and parse the input/output. I know the language is good for that purpose, but it's often taken to the extreme.</FONT>

  • (cs) in reply to BiggBru

    BiggBru:
    <FONT face=Georgia>Perls programmers just bust a nut ( [:P] )whenever they find the opportunity to read/write to files and parse the input/output. I know the language is good for that purpose, but it's often taken to the extreme.</FONT>

    Make that Perl. Boy, does it look stupid...

  • (cs) in reply to teambob

    Sometimes what? Perl is as good as anything else in readability (unless you're trying to be difficult)

  • (cs) in reply to Shen
    Shen:
    Sometimes what? Perl is as good as anything else in readability (unless you're trying to be difficult)


    Not true at all.

    The whole family of Algol derived languages that make up 70% or so of what is used in the real world are fairly explicit.  Anyone familiar with any of those languages should be able to get the gist of what is going on with any of the others, short of dealing with things like nexted pointer operations in C.

    Perl is a very different beast.  Perl provides lots of "invisible state", variables that are set and examined by many operators without being explicitly mentioned.  No other language I'm familiar with utilizes invisible state quite as much a Perl.  People unfamiliar with Perl can't track that state in their mind, and so can have difficulty following a program that appears quite clear to a Perl developer.

    Perl can be mindblowing if you are trying to obfuscate, but can be irritatingly opaque even when well written.
  • spook (unregistered)

    use POSIX 'ctime';
    my $date = ctime( time() );



  • (cs) in reply to Shen
    Shen:
    Sometimes what? Perl is as good as anything else in readability (unless you're trying to be difficult)

    Duh, it's quite the opposide, Perl is completely unreadable (it hasn't been nicknamed "the write-only language" for nothing) unless you're trying to be readable.

    While you can write readable perl, it's not the usual state of a perl script, and experiments show that any Perl source above the 1k lines count quickly mutates into a gooey mess (just as, you know, any audio tape left in a car for more than a fortnight turns into a "Best of Queen")

  • Jinsaku (unregistered) in reply to masklinn

    Sadly enough, when I was a young perl-loving lad, I remember doing this exact same thing at my first job.

    Thankfully, I'm much more 'brillant' now.

    -- Jinsaku

  • (cs) in reply to masklinn
    masklinn:
    While you can write readable perl, it's not the usual state of a perl script, and experiments show that any Perl source above the 1k lines count quickly mutates into a gooey mess (just as, you know, any audio tape left in a car for more than a fortnight turns into a "Best of Queen")

    I'm currently enjoying listening to J. S. Bach's Mass in B Minor, with vocals by F. Mercury.


  • jimbob (unregistered) in reply to masklinn

    only if you are a sad programmer who writes terrible programs.

    perl has Test::Simple tests=>more than none;
    ok(some_crap_you_wrote() eq "the expected answer")

    most of the comments here just demonstrate that a lot of IT people that feel pretty confident about themselves know fuck all about anything that that they are crowing over.

    get some skills.



  • (cs) in reply to jimbob
    Anonymous:
    only if you are a sad programmer who writes terrible programs.

    perl has Test::Simple tests=>more than none;
    ok(some_crap_you_wrote() eq "the expected answer")

    most of the comments here just demonstrate that a lot of IT people that feel pretty confident about themselves know fuck all about anything that that they are crowing over.

    get some skills.



    I don't see what the Perl facilities for tests have to do with the fact that it's unreadable unless huge efforts are done to actually keep it readable (effort which would probably be better spent on languages that ease or enforce readability of the source without having to constrain oneself). No one said that it wasn't possible to use working code in perl (this would be false anyway)

  • Nataku (unregistered) in reply to masklinn
    masklinn:
    Anonymous:
    only if you are a sad programmer who writes terrible programs.

    perl has Test::Simple tests=>more than none;
    ok(some_crap_you_wrote() eq "the expected answer")

    most of the comments here just demonstrate that a lot of IT people that feel pretty confident about themselves know fuck all about anything that that they are crowing over.

    get some skills.



    I don't see what the Perl facilities for tests have to do with the fact that it's unreadable unless huge efforts are done to actually keep it readable (effort which would probably be better spent on languages that ease or enforce readability of the source without having to constrain oneself). No one said that it wasn't possible to use working code in perl (this would be false anyway)

    I have seen some really terrible code out there. 5000 line long C# functions with public members all over the place. Perl's stuff isn't any worse, there just tends to be more of it out there, as its more accessable and forgiving of a language.

    It doesn't require huge efforts to write good code either. Perl supports a similar syntax to most OO languages. If people choose to write it differently I can't stop that, and its not the languages fault, its the programmer.

  • (cs)
    Alex Papadimoulis:
    <FONT color=#006600>#write out date</FONT>
<FONT color=#666666>system</FONT>(<FONT color=#990000>"date >/tmp/the.date"</FONT>);

    <FONT color=#006600>#read it back in</FONT>
<FONT color=#666666>open</FONT>(THEDATE, <FONT color=#990000>"</TMP FONT the.date<>");
<FONT color=#000099>while</FONT> (<THEDATE>)
{
<FONT color=#666666>chop</FONT>;
@datevals = <FONT color=#666666>split</FONT>(/ /,$_);
}
<FONT color=#666666>close</FONT>(THEDATE);

    This coulda been any language. It's not restricted to perl. Why the author chose to 'write to file' is hard to say.  I suspect to "SHARE" the date with another application that could also read the file. Kinda like a crude single-value database.  Whatever the.date contains, it musta been important, almost GLOBAL in scope. Surely the.date was left for another application to consume. Otherwise WTF.</FONT>

  • Robbak (unregistered) in reply to sinistral
    sinistral:
    ferrengi:
    sinistral:
    ferrengi:
    Wow, I'm not nearly smart enough to come up with something like that.
    <thedate>
    What if the program is run from a directory that does not have a tmp subdirectory?
    I guess the open() will fail, the code in the while loop will not get executed and @datevals will not get set. Maybe Mike was called in to figure out why the program was not longer working and figured out that this stupidity was the cause.


    A funny reply, but not correct.  Not that the path starts with '/' (as in /tmp).  This assumes a UNIX like system which has a /tmp directory that anybody can write to.  What could happen is that different users create the file with different permissions and the routine fails because the file already exists and is owned by another user that prevented world write.
    </thedate>


    Didn't know that. So in UNIX everyone shares a global /tmp directory? In that case, the file would get created by user A, and then when user B runs the program, creating the file will not work because it already exists (unless this code will replace the existing file automatically).

    Either way, I find it surprising that the "programmer" that invented this didn't say to himself something like:

    There is a quite a bit that could go wrong if I write the program this way, maybe I should do a little research or ask someone if there is a better way.



    Yes, the /tmp directory is world writeable; all users can write to it and create files.  If user A creates a file and makes it world writeable, user B can run this script and it will work.  The file will still be owned by A, but will have the date of when B ran it.  If A didn't make the file world writeable, nobody (but root) can overwrite the contents.  Which goes along with what you're saying... lots can go wrong.

    As another poster pointed out, on NT and later Win 32 systems, you can use '/' as a path separator, and the current drive will be assumed.  So, unless you have a X:\tmp, this will again fail (where X is any drive you may currently be on).


    Just for completeness, /tmp is usualy sticky: That means that anyone can write to it, but only the owner of the file can delete the file. (Generally, anyone with write access to a directory can delete files from it.)
    So, yes, his code is liable to all sorts of racey conditions.

    Strange how, whenever you think code cannot get worse, someone shows you how.....

  • DrDoom (unregistered)

    I think I know what this code is meant to do.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    It is most likely extraction from larger code that is designed to test folder permissions. That is why he reads the date from file and then modifies it. How he does it does not really matters as this is an admin code, the only thing that counts is result. <o:p></o:p>

    <o:p> [H]</o:p>

  • Runtime Error (unregistered) in reply to olddog
    olddog:
    Alex Papadimoulis:
    <font color="#006600">#write out date</font>
<font color="#666666">system</font>(<font color="#990000">"date >/tmp/the.date"</font>);

    <font color="#006600">#read it back in</font>
<font color="#666666">open</font>(THEDATE, <font color="#990000">"<>");
    <font color="#000099">while</font> (<thedate>) 
    {
      <font color="#666666">chop</font>;
      @datevals = <font color="#666666">split</font>(/ /,$_);
    }
    <font color="#666666">close</font>(THEDATE);</thedate></font>

    <font color="#990000">

    </font>

    <font color="#990000">This coulda been any language. It's not restricted to perl. Why the author chose to 'write to file' is hard to say.  I suspect to "SHARE" the date with another application that could also read the file. Kinda like a crude single-value database.  Whatever the.date contains, it musta been important, almost GLOBAL in scope. Surely the.date was left for another application to consume. Otherwise WTF.</font>



    Nahhh, the WTF here is that the date is being stored as plain text.   Everyknows that the only suitable data format is XML.  The author should have created a DTD for validation and read the data back through a SAX parser.
  • (cs) in reply to Runtime Error
    Anonymous:
    olddog:
    Alex Papadimoulis:
    <FONT color=#006600>#write out date</FONT>
<FONT color=#666666>system</FONT>(<FONT color=#990000>"date >/tmp/the.date"</FONT>);

    <FONT color=#006600>#read it back in</FONT>
<FONT color=#666666>open</FONT>(THEDATE, <FONT color=#990000>"<>");
    <FONT color=#000099>while</FONT> (<THEDATE>) 
    {
      <FONT color=#666666>chop</FONT>;
      @datevals = <FONT color=#666666>split</FONT>(/ /,$_);
    }
    <FONT color=#666666>close</FONT>(THEDATE);</THEDATE></FONT>

    <FONT color=#990000>

    </FONT>

    <FONT color=#990000>This coulda been any language. It's not restricted to perl. Why the author chose to 'write to file' is hard to say.  I suspect to "SHARE" the date with another application that could also read the file. Kinda like a crude single-value database.  Whatever the.date contains, it musta been important, almost GLOBAL in scope. Surely the.date was left for another application to consume. Otherwise WTF.</FONT>



    Nahhh, the WTF here is that the date is being stored as plain text.   Everyknows that the only suitable data format is XML.  The author should have created a DTD for validation and read the data back through a SAX parser.

    hmmm.  we might have found a time-frame. Someone pitch in here. When was XML,DTD, and the SAX parser introduced? Perhaps this code pre-dates that?  Look at the perl calls. pretty core stuff. We could be looking at pre-xml efforts. This could have historic value.  Dibs on Ebay.

  • Kevin Mitnick (unregistered)

    user1> ln -s /etc/passwd /tmp/the.date root# ./script.pl

    system pwnd

  • (cs) in reply to Kevin Mitnick
    Anonymous:
    user1> ln -s /etc/passwd /tmp/the.date root# ./script.pl

    system pwnd



    I like it.

  • Moobar (unregistered) in reply to Shen
    Shen:
    Perl is as good as anything else in readability...


    WTF?
  • CraigM (unregistered)

    So, the real WTF is that he used chop instead of chomp, in case the date command stops providing a newline, right?

  • (cs) in reply to SeekerDarksteel
    SeekerDarksteel:
    So yea....not going to be messing around with winsock around here anytime soon.
    It's a good idea to avoid winsock at the best of times.  I would hope "they" have fixed it since, but there was a time when winsock demonstrably dropped any out-of-sequence packets.  So if you missed, say, packet 13 but got the rest of the window (say, 14-20), winsock demanded retransmission of each of 13-20.

    As for Perl, we've seen an ongoing evolution of the language featureset, and not all modules are available on every installation of the language.  So I can't speak to what might or might not have been available to this programmer (or what control he/she might have had over the execution environment) when the code was written, but I can understand the dilemma.
  • (cs) in reply to Coughptcha

    ... D'oh.  Meant to throw in the joke about using RE's.

Leave a comment on “A Date of Infamy”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article