lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/16/91)
A beta version of perl 4.0 is available from jpl-devvax.jpl.nasa.gov (128.149.1.143), in ~ftp/pub/perl.4.0/4.0.beta.tar.Z. I want a real short beta period, so get your comments to me early next week, or don't bother. Please don't copy the beta all over the world... Sorry, only ftp'ers allowed. Larry
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/16/91)
Incidentally, our machines will be down Saturday and maybe Sunday, so don't be surprised if you can't get through then. I also just realized I didn't put any of \a \e \x1b \c[ \l \L \u \U \E into the man page. But then again, they aren't in the book, either. :-) I'm looking for three kinds of testing on this beta: 1) Does it install reasonably easily? 2) Does it break any of your existing scripts? 3) Do the new features (see above, and the ADDENDA section in the man page) work the way you think they should. Also, I haven't had a chance to write any regression tests for the new features. If in testing you come up with any, feel free to send them. If you get the beta working on a particular architecture, you might post something to that effect to save someone else from duplicating. Thanks. Larry
meissner@osf.org (Michael Meissner) (02/23/91)
In article <11461@jpl-devvax.JPL.NASA.GOV> lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: | A beta version of perl 4.0 is available from jpl-devvax.jpl.nasa.gov | (128.149.1.143), in ~ftp/pub/perl.4.0/4.0.beta.tar.Z. | | I want a real short beta period, so get your comments to me early next | week, or don't bother. Please don't copy the beta all over the world... I brought it up under OSF/1, and noticed that it wasn't finding anything in the library. The problem is if nm's output isn't what Configure is expecting, it's supposed to go and use ar. However, there was a missing ';' so that it never failed and did the ar. *** Configure.~1~ Fri Feb 15 17:58:28 1991 --- Configure Fri Feb 22 16:55:09 1991 *************** *** 1680,1686 **** $contains '^printf$' libc.list >/dev/null 2>&1; then echo done elif $sed -n -e 's/^.*|FUNC |GLOB .*|//p' -e 's/^.*|FUNC |WEAK .*|//p' \ ! <libc.tmp >libc.list \ $contains '^printf$' libc.list >/dev/null 2>&1; then echo done else --- 168i,1686 ---- $contains '^printf$' libc.list >/dev/null 2>&1; then echo done elif $sed -n -e 's/^.*|FUNC |GLOB .*|//p' -e 's/^.*|FUNC |WEAK .*|//p' \ ! <libc.tmp >libc.list; \ $contains '^printf$' libc.list >/dev/null 2>&1; then echo done else -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
marc@athena.mit.edu (Marc Horowitz) (02/25/91)
|> We're weird because we run AFS.
So are we. This message sounds really familiar :-)
The workaround I devised for this is certainly a crock, but it does
work. (I'm about to plunge into AFS details. Skip the rest of the
paragraph if you don't care.) In our root.afs volume, .root.afs is a
read-write mountpoint for the root.afs volume. Therefore,
/afs/.root.afs/athena is the same as /afs/.athena. The trick is that
given a machine I can hack on, when it's time to install perl, I can
change the cacheinfo file to mount AFS on /afs.ro, and make /afs a
symlink to /afs.ro/.root.afs. Then, all installs to
/afs/athena/contrib/perl indirect to the r/w volume, and normal users
get the backup volume once it's been released.
It seems that the ``right'' solution is to have two configure
variables, one for where the binaries/scripts/libraries should be
installed, and one for where they should be read from. It should be
possible to make the defaults clever enough that they are correct on
most normal systems.
I'd be glad to try to do this, since I have afs, or I can arrange a
guest account here for Larry.
Marc