Patrick, I think that you can include
setenv.sh.sample setenv.bat.sample It's the way used for /build.properties Bernard > -----Original Message----- > From: Remy Maucherat [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 28 November, 2001 03:12 > To: Tomcat Developers List > Subject: Re: cvs commit: > jakarta-tomcat-4.0/catalina/src/binsetenv.shcatalina.sh tool-wrapper.sh > > > > on 11/27/01 3:09 PM, "Patrick Luby" <[EMAIL PROTECTED]> wrote: > > > > > Jon, > > > > > > What I could do is not distribute the "setenv.sh" file and, instead, > check > > > for the existence of this file. If it exists (which would > only occur if > the > > > user has created the file), then catalina.sh and > tools-wrapper.sh would > > > source it. > > > > > > I think that would comply with your requirement. > > > > Yes. > > > > > Also, should we put the setenv.sh somewhere else as well. > > > > In documentation. > > > > > If the above sounds OK, I can cvs remove the setenv.sh file > and make the > > > sourcing conditional. > > > > Yes. Thanks for the quick response. > > > > Just as a side note, we need to be more cautious about upgrades and how > > users perform them. The server.xml is a big sore spot as well > because that > > is another file that needs to be changed by the users. > > Yes. I'm very cautious in the Windows installer to not overwrite > the config > files. It has lots of problems (which are slowly getting > resolved), but not > that one ;-) > > Remy > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
