The Daily WTF: Curious Perversions in Information Technology

2006-01-11 Reply Admin

masklinn:
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")

Bang On!

As far as I can see, perl is designed for quick_n_dirty on-off fixes.

The WTF is that it's a WTF

The derivative of the WTF is that too many commenters don't get it.

1. It's not Windows.   Windows would had required date /t > some.file.name
otherwise, you'd be looking at a screen, with a "huh"

2. The Guy (maybe a "Babe") is a genius.
A quick-and-dirty solution to a problem.    I wish I had the intuition to come up with a solution like that.

I'd bet that most of the commenters wouldn't know that 2038 was a really significant number.

Earth calling Alex:   We need some real TWFs

Old-Not-Quite-Rich-Curmugeon-Somewhat-Saner-Than-Richard-Nixon.

"I am not a crook"

2006-01-11 Reply Admin

Anonymous:
masklinn:
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")

Bang On!

As far as I can see, perl is designed for quick_n_dirty on-off fixes.

The WTF is that it's a WTF

The derivative of the WTF is that too many commenters don't get it.

1. It's not Windows.   Windows would had required date /t > some.file.name
otherwise, you'd be looking at a screen, with a "huh"

2. The Guy (maybe a "Babe") is a genius.
A quick-and-dirty solution to a problem.    I wish I had the intuition to come up with a solution like that.

I'd bet that most of the commenters wouldn't know that 2038 was a really significant number.

Earth calling Alex:   We need some real TWFs

Old-Not-Quite-Rich-Curmugeon-Somewhat-Saner-Than-Richard-Nixon.

"I am not a crook"

Hopefully, I'm not a crock.

I meant to say,

Alex: We need some real WTFs.

ps. This one's pretty lame.

felix · 2006-01-12 Reply Admin

Anonymous:
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.

But you see, that's not Unix's fault. Unix has this function called tmpfile() which returns - guess what - an available temporary file name. If the programmer chooses to ignore it and hardcode the file name, that's his problem entirely.

mcrbids · 2006-01-12 Reply Admin

Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

I've produced (and still produce) my share of crap code, when I "know" that whatever I write will be thrown away soon, or at least, not used outside a narrowly defined context. Sometimes, it's better to get something done fast than done right, if it works "this one time" or in "this particular case".

There's nothing wrong with that. 10 minutes of research isn't justified when you have a 5-minute hack that will be used once or twice and then tossed. In these cases, performance isn't much of a concern, and "the right thing" is whatever you can slap together the fastest.

2006-01-12 Reply Admin

mcrbids:
Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

I've produced (and still produce) my share of crap code, when I "know" that whatever I write will be thrown away soon, or at least, not used outside a narrowly defined context. Sometimes, it's better to get something done fast than done right, if it works "this one time" or in "this particular case".

There's nothing wrong with that. 10 minutes of research isn't justified when you have a 5-minute hack that will be used once or twice and then tossed. In these cases, performance isn't much of a concern, and "the right thing" is whatever you can slap together the fastest.

Amen

ammoQ · 2006-01-12 Reply Admin

Stupid code like today's WTF allows symlink attacks. It's not only slow and complicated, but also extremely insecure.

WWWWolf · 2006-01-12 Reply Admin

Well, ignoring the fact that the whole thing is pretty silly when we have localtime and DateTime stuff, but still:

* raw shell system() makes me wince, even when the argument is a string with no variable expansions.
* Temporary file is same for every invocation. Most people have the sense to use something like $tempfile = "/tmp/$0.$$"; or something (ie, program name and process id).
* Perl 101: The recommeded syntax is open(...) or die(...); (Same for people who don't know Perl: A classic example of not handling errors. At all.) Hell, writing that is kind of automatic for me. I think I once forgot that. At four am in the morning when I woke up to write some Perl for that cool idea I had once.
* chop; used instead of chomp;.
* Doesn't unlink() the temp file, which is kind of silly if someone else uses the program and the temporary file isn't writable.

JohnO · 2006-01-12 Reply Admin

mcrbids:
Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

I've produced (and still produce) my share of crap code, when I "know" that whatever I write will be thrown away soon, or at least, not used outside a narrowly defined context. Sometimes, it's better to get something done fast than done right, if it works "this one time" or in "this particular case".

There's nothing wrong with that. 10 minutes of research isn't justified when you have a 5-minute hack that will be used once or twice and then tossed. In these cases, performance isn't much of a concern, and "the right thing" is whatever you can slap together the fastest.

Come on.

1) The guy that submitted this wouldn't have seen it if it was truly throw away, one-time-use code.

2) This code is embarassingly bad even if it's to be run only one time or only under limited circumstances.

3) 10 minutes of research leads to a lifetime of not shelling to get the date. We'd all still be cavemen using your philosophy.

RoKe · 2006-01-12 Reply Admin

Anonymous:
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) ;)

You don't know perl, do you?

my @datevals = split / /, date;

though the correct way would be...

my @datevals = localtime;

2006-01-12 Reply Admin

Anonymous:
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

You think this is a joke. Check out the IRC client X-Chat. It has a built-in command that lets you perform a DNS lookup on an arbitrary name. Until very recently (within the past few versions), it performed this lookup by shelling out to the 'host' command found on Linux systems. And when it didn't work on Windows, it was "Windows fault for not having obvious commands like `host`'. :x

--Mike

2006-01-12 Reply Admin

There are better ways to do this, yes.
Race conditions and other bad stuff are here, yes.

Using standard modules are a must when you can, yes.

Sometimes you have a job where the admins don't let you install anything except for your one little script (not even modules) on their box. I am ashamed of the code that I was forced to write.

2006-01-12 Reply Admin

Damn you! Where did you hijack my code?!!

This is merely #273 of the 5000 different ways you can do the same thing in perl. I'm not saying it's the BEST way...or the RIGHT way...

(and yes, I've since discovered the timedate module...)

emjot · 2006-01-12 Reply Admin

great minds think differently, it's all about that.
but does this mind thought about changed locale? that is the question!
anyway, pure wtf...

2006-01-12 Reply Admin

I must admit. I have done almost that exact code back in the DOS batch file days. There was no other way to get the information I wanted to use. I don't remember the program I wrote, I just remember the triumphant feeling of solving the problem.

Now, only shame. :-)

mcrbids · 2006-01-12 Reply Admin

JohnO:
mcrbids:
Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

I've produced (and still produce) my share of crap code, when I "know" that whatever I write will be thrown away soon, or at least, not used outside a narrowly defined context. Sometimes, it's better to get something done fast than done right, if it works "this one time" or in "this particular case".

There's nothing wrong with that. 10 minutes of research isn't justified when you have a 5-minute hack that will be used once or twice and then tossed. In these cases, performance isn't much of a concern, and "the right thing" is whatever you can slap together the fastest.

Come on.

1) The guy that submitted this wouldn't have seen it if it was truly throw away, one-time-use code.

2) This code is embarassingly bad even if it's to be run only one time or only under limited circumstances.

3) 10 minutes of research leads to a lifetime of not shelling to get the date. We'd all still be cavemen using your philosophy.

... and what's wrong with caves?

ferrengi · 2006-01-12 Reply Admin

mcrbids:
Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

I've produced (and still produce) my share of crap code, when I "know" that whatever I write will be thrown away soon, or at least, not used outside a narrowly defined context. Sometimes, it's better to get something done fast than done right, if it works "this one time" or in "this particular case".

There's nothing wrong with that. 10 minutes of research isn't justified when you have a 5-minute hack that will be used once or twice and then tossed. In these cases, performance isn't much of a concern, and "the right thing" is whatever you can slap together the fastest.

I've done some things in less than ideal ways also.
However, when the hack that this guy came up with is harder to code than implementing any kind of normal solution, it kind of leaves you scratching your head.
It's almost like he was struggling to find the worst possible way of doing this.
I wouldn't be surprised if he sat for hours trying to figure out how to do this using only the knowledge he already had (and it doesn't appear that he knew a whole lot).
It doesn't look to me like one of those cases where a hack is justified because it will save time.
It's more like sheer stupidity.

2006-01-12 Reply Admin

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>");
<font color="#000099">while</font> (<thedate>)
{
<font color="#666666">chop</font>;
@datevals = <font color="#666666">split</font>(/ /,$_);
}
<font color="#666666">close</font>(THEDATE);</thedate>

If you don't need the timezone you can just do this:

@datevals = split / /, scalar localtime

easy!

sammybaby · 2006-01-12 Reply Admin

Anonymous:
user1> ln -s /etc/passwd /tmp/the.date root# ./script.pl *system pwnd*

Wouldn't that require user1 to have root privileges already?

Wire · 2006-01-12 Reply Admin

mcrbids:

... and what's wrong with caves?

They're infested with cavemen.

2006-01-12 Reply Admin

You really don't get the point of this site, do you?

2006-01-12 Reply Admin

The real WTF is that this was submitted at all... or maybe that Alex thought it worthy of posting.

Perl is a language for quick hacks, and for scripts which get run once. If this is such a script, what's the problem?

2006-01-12 Reply Admin

Agreed on most points. I do use the date command from the shell in my perl scripts mostly because localtime can be a real pita when I just need the current hour/day/etc... and using date from the shell is more portable than including a perl module on all of my servers. Of course, this all depends on useage, if I was writing something to distribute to someone else I wouldn't do that, and I've went to writing bash scripts for most of my internal stuff. Figured if I was just going to use shell commands, why use perl.

2006-01-12 Reply Admin

Date/time modules have been available on every Perl install I've seen on every platform in the last 15 years at least. Yet
system("date");
and
system("chmod 777 file");
are common despite built-ins that are faster and more portable.

Gene Wirchenko · 2006-01-12 Reply Admin

Anonymous:
The real WTF is that this was submitted at all... or maybe that Alex thought it worthy of posting.

Perl is a language for quick hacks, and for scripts which get run once. If this is such a script, what's the problem?

So why was it still available to send to this site? I write one-shots, too. I also delete them when they are finished.

Sincerely,

Gene Wirchenko

2006-01-12 Reply Admin

No /etc/passwd is world readable

Coughptcha · 2006-01-13 Reply Admin

Anonymous:
No /etc/passwd is world readable

I think there's some punctuation missing there. Or else a huge mistake: every /etc/passwd is world-readable.

2006-01-13 Reply Admin

Perhaps the programmer wasn't after the date, but rather what the Operating System 'DATE' command returned -- this could be handy in determining localization (in EMEA its "mm/dd/yyyy" not "dd/mm/yyyy"). And on Windows systems you can several things about the environment in which you're running based on the return from the 'DATE' command.

Ciao

dave · 2006-01-14 Reply Admin

sammybaby:
Anonymous:
user1> ln -s /etc/passwd /tmp/the.date root# ./script.pl *system pwnd*

Wouldn't that require user1 to have root privileges already?

You don't need the privileges to soft link to a file - hence the race condition... I like this - as long as we still have stupid programmers I remain in a job :-)

2006-01-15 Reply Admin

Anonymous:
Agreed on most points. I do use the date command from the shell in my perl scripts mostly because localtime can be a real pita when I just need the current hour/day/etc... and using date from the shell is more portable than including a perl module on all of my servers. Of course, this all depends on useage, if I was writing something to distribute to someone else I wouldn't do that, and I've went to writing bash scripts for most of my internal stuff. Figured if I was just going to use shell commands, why use perl.

If you're using perl and time related things, and you only need specific values, use an array slice to get the value you need. For instance, if you just need the current hour, use (localtime())[2].

2006-01-16 Reply Admin

mcrbids:
Was this found in a mission-critical application, or in some shell script found in ~root/bin?

The standards for excellence when writing mission-critical, application code are quite different than for some random sysadmin function run rarely and non-critical if it fails.

you have to be carefull with using temp files as a high privilage user though. if not you can end up with security holes depending on what you do with the file content.

2006-01-20 Reply Admin

Anonymous:
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).

Unless of course, this is part of a system that works with all sorts of scripting languages and they need to know what date/time this started and it was created with the assumption (I know it's bad) that it will fire off with a cron job or something like it once an hour or so. Having that written in a file makes it easy to see if it's running - you can easily just cat the file to see when the last time it ran. You can also easily read it if with python, ksh, bash, etc...

Without seeing the full picture, I can't see this as a WTF.

A Date of Infamy

Leave a comment on “A Date of Infamy”