Wiggins d'Anconia writes: > Robert Brown wrote: > > I posted this question once before, a couple of days ago, but never > > really got an answer... > > Not attempting a flame war or anything, and I don't necessarily have a > solution but your original post sounded very ungrateful towards the Perl > development team and maintainers and may have been the reason why it > didn't solicit any response. But that is just how I read it, maybe just > no one knows...
Please excuse my frustration. I am updating a bank of servers from various versions of RedHat, Mandrake, openBSD, and netBSD, so that they all run the same current version of RedHat 9. This is occurring concurrently with moving over 400 miles to a different state, changing the network topology, and having to get a new internet connection that involved 2 isp's, one of which is the phone company, who could not give me a cidr block of static ip addresses, and the other isp I have to tunnel to to get my cidr block and routing. It has been very painful. The perl thing is just a small part of the cumulative frustration. I did not mean to sound ungrateful to the perl developer's community. And no! M$ is not an option. I have been running emacs since 1986, Unix since 1989, and Linux since 1993. There is no way that I would switch to anything that was not open sourced and unix based now. It did suprise me that the documentation I was able to find indicated that dbmopen should be replaced with "tie", and that the construct was not a line for line change, but a methodology change. This is what I meant by breaking legacy code. And while one machine was running RH 6.1, the web server that the perl scripts in question run on was actually running RH 7.3. I guess what I am looking for is a dbmopen that will behave the same way the old one did, even if I have to unload and reload the old files into new ones using the technique you described -- unloading under the old version of Redhat, and reloading under the new version. My understanding was that dbmopen is no longer recommended, and that a single call to dbmopen now needs to be replaced with multiple lines of logic to determine if the file exists so it can be created if not, and then opened either way, and the whole thing was totally confusing to me. Does dbmopen still work, and it is the underlying database support tools that are called by default that have been changed, or is dbmopen out the window and tie is in in its place, or what? If it is only the default database implementation that has been changed, how can I determine what the old default was, and how can I force the new perl to use than mechanisim instead of whatever its new default is? Or is this even possible? It could at least save me downgrading a machine to dump the old database files. And yes, you are right about md5 hashes. They should port to the new implementaion even if they do look like alphabet soup. The md5 hash of a password is still the same, whatever it is implemented with and running under. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
