Main Stories
Slash Boxes

Slash Open Source Project

Slashcode Log In

Log In

[ Create a new account ]

Followup to Port to NT post

posted by Krow on 12:54 PM October 31st, 2000   Printer-friendly   Email story
GeoShine writes "Hey folks,

For those that asked, I've got the log of my progress in getting slash ported to NT up at:

Trippy.org

No, it isn't fully working yet, but I'm making good progress, and I thought that maybe someone can lend some insight to some of the problems I've run into. The first block at the top shows current status, and what follows is a detailed rundown of what I've done to install afterwards.

Please feel free to email me commentary or questions. I'll answer them as soon as I'm able. And yes, now that I have the server installed at home, I've considerably more time to get this working.

As I mentioned before, I'm not sure exactly *why* I'm so persistent on this since I've already got it running quite well on Linux, but I figure maybe I'm just a masochist at heart.

Cheers,
Geo"
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • Yeah, it is absolutely unnecessary. If the program is executable -- which it should be -- then it makes no difference. Well, I guess the difference might be that you don't have a /usr/bin/perl, but instead have a /usr/local/bin/perl or something. In that case, the simple solution is ln -s /usr/local/bin/perl /usr/bin/perl ...
  • Oh wait ... I guess there are no symlinks in Windows. But shouldn't it still be able to execute the program without a "perl" prefix? The problem is that putting "perl" in front may break in some places (also note that -w should be entirely unnecessary since -w is on the #! line, which NT perl should recognize for flags even if not for invocation).

    The way many programs do things is to have an EXECPERL variable or some such. So we could have:

          "$I{execperl} $I{basedir}/portald &"

    and then execperl can be set to anything you want it to be.

    In bender this will be easier; we really need to convert all the scripts to be ".PL" scripts, so that you can call "perl portald.PL" during install, and have it create "portald" for you, which will have the proper invocation at the top of it (I imagine this could even be made to work with NT ... but I don't know for sure). Maybe if NT needs to have the "perl" in front we can still have an execperl variable.
  • The site you posted, geo.trippy.org/nt-slashcode/ ain't working ... do post a valid website where I can download the source
  • I note that a big chunk of the changes consist of changing lines like these:
    • system("$I{datadir}/portald &");
    • system("$I{datadir}/dailyStuff &");
    • system("$I{datadir}/moderatord");
    into lines like these:
    • system("perl -w $I{datadir}/portald &");
    • system("perl -w $I{datadir}/dailyStuff &");
    • system("perl -w $I{datadir}/moderatord");

    Can anyone think of any reason why this shouldn't be a permanent part of slash?

  • The problem is that Windows has a feature that allows files to be mapped to applications that can open them on the basis of file name extensions (i.e. ".pl" maps to Perl). Installers for applications often mess around with this by remapping file name extensions to themselves (with or without permission for the user at the console at the time of installation). This is a common complaint of Windows users that use both Netscape and Internet Explorer, for example.

    The version of Slash 0.3 that we run at CTDATA [ctdata.com] has been modified to use the $^O Perl variable to determine the host operating system before deciding the syntax of calls to system() and other things that may need to be configured differently when running them on a non-UNIX platform.

    Our experience has been that prepending the word "perl" on any argument passed to system or eval (or a subroutine that calls them) is required if the script's file name does not end in ".pl". This can be worked around, however, if you are using MKS Toolkit or one of the other OS enhancements that makes NT and 2000 appear to be more UNIX-like. These tools provide support for hash-bang notation at the beginning of script files, if you want to use it.
    --

    Dave Aiello
    Chatham Township Data Corporation

    --

    --

    Dave Aiello
    Chatham Township Data Corporation [ctdata.com]

  • I'm pretty sure that if the script has a .pl extension, it will be called and execute correctly. It is just the daemons (slashd, moderatord, etc) that don't have that. I'm about to redo the perl libraries again to get XML::Parser back, so I'll try that this go 'round.

    - Geo