use Perl

What happened to File::Find::Rule? It apparently hasn't been updated since 2006. Once upon a time, it was the hottest module on CPAN.

Is it still a good idea to use this instead of File::Find/find2perl? Have I got the right module?

"git-style paging" is addictive. After having your interactive results automatically paged whenever needed, you start to get a little critical of your other tools, even old venerable tools that expected pagers to be applied separately by the user if necessary, and even high-quality newer tools like ack.

Turns out ack supports git-style paging. Just add this to your ~/.ackrc:

--pager
more  # or less, if you lean that way

Everybody but me probably already knew this.

Now, if somebody could just tell me how to make git on Windows automatically page like git on Linux does, that would be great, because that's what I was originally googling for...

In Java, String.match() conveniently takes a regular expression, not just an ordinary String. However, I just found the following:

"2".matches("2");  // returns true; good
"2007".matches("2");  // returns false -- huh???

Turns out it looks like matches() is anchored; it's implicitly acting as if the regular expression is wrapped in ^ and $. So the regular expression I supply to matches() has to consume the entire string, from beginning to end, or it doesn't match. Sigh.

"2007".matches("2.*");  // returns true -- sigh

This of course is not specified in the documentation anywhere that I can see. At least, not in the Javadocs for the String.matches() method.

To set the TDS protocol version when using FreeTDS, without modifying a freetds.conf file, set the TDSVER environment variable.

I previously dealt with an issue that had to be resolved by setting the tds version setting for the connection to 8.0. Using DBD::Sybase, I can bypass the need for a freetds.conf file to specify servers, except that I cannot set tds version from DBD::Sybase. Thus, this issue required me to use a freetds.conf file. Using TDSVER, I can specify everything in my program instead of a semi-global configuration file.

Of course, if I had to connect to two different servers in the same program, say an old Sybase server and a newer MSSQL Server, and both needed me to set different values for tds version, I would likely be up a creek, if neither happened to be the default.

A class is a noun: Ball.

An interface is an adjective, usually of the form verb-"able": Serializable. Shootable.

A mixin is a gerund: Serializing. Encrypting.

Too bad there's no mixins in the language I have to speak every day. :)

Warning: I've got no clue about this stuff, and I'm a learner expressing an analogy that occurred to him which is likely dead wrong.

I'm busy being disgusted with MySQL today for its case-sensitivity. I'm only slightly disgusted with it for being case-sensitive (against the standard, I think) on Linux. I'm more disgusted with it for turning around and not being the same on Windows!

Isn't case-insensitive table and column names the SQL standard? Is it better for a database to support the extra "feature" of allowing case-sensitive names, or is it a nightmare?

I'd appreciate intelligent comments added to this Stack Overflow question on the subject.

There's also this question about the SQL standard.

Update: I'd also appreciate it if people would vote up those two SO questions so as to (hopefully) get them more exposure and commentary. Although I'm not sure what the real chances are of old SO questions becoming "hot."

In keeping with the maxim "Be strict in what you emit, and liberal in what you accept," isn't writing a method to convert an ISO standard YYYY-MM-DD date into MM/DD/YYYY format a violation of my religious principles?

How do you set environment variables in Java? You can't, because you shouldn't want to do that. Of course, I would really, really like to do that.

Perl is the only truly portable language I know. (I know there are others; I just don't know them.) It manages to do things as similarly as possible across an incredible range of platforms.

It seems that with JNI you could extend Java to do a lot of things it doesn't want to do. Most of these could be done quite portably, too. [Not being able to do them portably is the only reason I can see for these features to be kept out of Java itself.]

So, if I had a little extra time, I'd like to spend it releasing a jar full of classes to support simple portable extra features for Java, like:

Copying/renaming a file without having to read it block by block

Setting environment variables

Changing the current working directory

I guess if I was really flush for time I'd go see what it would take to get this going in the Java Community Process. Or fork the JDK.

My last complaint was minor and debatable. This one isn't: as I'm trying to install modules, I'm provoking some attempt to install perl-5.8.9-RC1.tar.gz . I wouldn't want that even if I were running an earlier version of 5.8, and even if this were a production distribution and not a release candidate. I particularly don't want this since I'm running 5.10.0.

I think this is a CPAN indexing problem. It used to be a big issue circa the transition from 5.6 to 5.8, I think.

I knew that Java's regular expressions would come with a horrible syntax I wouldn't want to use. I didn't know that the syntax would appear to be designed by someone who completely misses the point.

In order to use a precompiled regex pattern, you get it to produce a Matcher object ... which is constructed with the String you want to match against! Then you call matches() on the Matcher object.

Pattern p = Pattern.compile("a*b");
Matcher m = p.matcher("aaaaab");
boolean b = m.matches();

For what mind numbing purpose was it decided that a Matcher object should have a String to match against as a piece of instance data? Are you going to construct one of these Matchers and pass it around so that different pieces of code can check over and over again if the same String matches?

This could have simply been implemented as Pattern.matches(String), or, if you simply must have a Matcher class, then get your Matcher from Pattern.matcher(), taking no parameters, and then require a String parameter to Matcher.matches(String).

What possible reason could there be for not following either of those approaches, instead of what they gave me?

As a sop, you get a static Pattern.matches(String pattern, String) method, but that completely prevents you from using precompiled patterns.

Clueless, Sun. Just clueless. Or is it the Java community that I have to blame for this? I've seen so many features elegantly added into Java, and then I see stuff like this.