diff --git a/LDP/howto/docbook/HighQuality-Apps-HOWTO/HighQuality-Apps-HOWTO.xml b/LDP/howto/docbook/HighQuality-Apps-HOWTO/HighQuality-Apps-HOWTO.xml index 75f320ff..8e1e87c7 100644 --- a/LDP/howto/docbook/HighQuality-Apps-HOWTO/HighQuality-Apps-HOWTO.xml +++ b/LDP/howto/docbook/HighQuality-Apps-HOWTO/HighQuality-Apps-HOWTO.xml @@ -156,7 +156,7 @@ Let's make some exercise with separation using as example a system called MySoftware, in which the business logic is in and the configuration is in . A Shell program referring an external configuration file - + &externalconf; @@ -172,17 +172,17 @@ After reading the configuration file, all content directories -- user's + product's -- goes together in the $CONTENT_PATH, that will be used from now on. - + File containing only the configurations for <acronym>MySoftware</acronym> - + &conffile; These are user defined parameters. - +
One Body, Many Souls @@ -531,7 +531,7 @@
Turning Your Software Into a Subsystem Your Software's files will spread across the filesystems, but you'll want to provide a simple and consistent interface to let the user at least start and stop it. Subsystems architecture promotes this ease-of-use, also providing a way (non obrigatoria) to be automatically started on system initialization. You just have to create your /etc/init.d script following a standard to make it functional. Skeleton of a Subsystem control program in <filename class="directory">/etc/init.d</filename> - + &initscript; @@ -554,7 +554,7 @@ Here you put your Software's specific command. - + The mysystem subsystem methods you implemented will be called by users with the service command like this example: <command>service</command> command usage