I am tweaking the Install_65_linux.sh file that sets up the Dantz client for my G5 iMac's running Dantz Retrospect "server" app. I'm going from a script built for Red Hat to the Debian GNU/Linux v3.1 os configuration. I find the Debian init.d at the same level as rc0.d through rc5.d. Is this my simple substitute path or are there other tweaks to be made?

line in question (plus succeeding line with the "ln" command):

/bin/mv -f .rcl /etc/rc.d/init.d
ln -sf /etc/rc.d/init.d/rcl $CLIENTDIR/rcl

Notes:
CLIENTDIR=/usr/local/dantz/client
since there is no /etc/rc.d, hence no init.d, there is no rcl

So friends of the porting world, what is an equivalent for Red Hat's rc.d/init.d ?

thanks,
Chris Gray
rasputin@teleport.com

Try /etc/init.d.

Thanks reddazz! I tried that last night and got it to work. I used to have to port Syustem 5 and BSD to UTek (Tektonix's UNIX) in the late 1980s and early 90s. The same old cross-porting song'n'dance again with "1000 flavors of vanilla", except different thieves getting rich. I appreciate your quick response. Has anyone bothered to write a cross-Linux porting guide to show the variant format and content of each "open source"? This community has learned littl from the past it sadly would appear. perhaps we ought to launch an open source porting doc that also shows how the "open source" languages differ in call stacks, expression and argument parsing order, etc. The standards seem lost in the community heavily doesd with the false consciousness that (a) it is different, (b) that it is new, and (c) that decentrilism/spontaneity is the way to beat monopoly and centralism. Primitivist idiotology.

chris

Well, that makes you "Teh Only One" capable of spearheading that effort then. Go ahead, I'd say.


Unless you're one of those ranting radical I-R-not-part-of-it-all anarchists, then for using GNU/Linux and interacting with other GNU/Linux users you've become part of the community. if you want to or not. So basically you're calling yourself a "follower of a primitivist idiotology". I don't mind as long as your highly technical, totally objective, typo-free, long-awaited cross-Linux porting guide will not suffer from it...