Robert Spier wrote:
Yes, but not with those names. They're somewhat meaningless. Also,
for the first one, do you have a path to perl hardcoded?
How about qpsmtd_debug and qpsmtpd_test? And I don't have to hardcode the path,
because both of them run as a logged in user (and hence don't have a limited
path to begin with). I don't want to pretend that these are particularly clever
scripts, just that for development purposes, I use debug_qpsmtd all the time,
and when I am rolling out new releases, I always run a live test on an alternate
port.
I'd also like to pitch my alternate ./run file, which uses DJB's envdir to
seperate the runtime configuration (which lives in ./env) from the application
configuration (which lives in ./config like before). So the script I use is this:
#!/bin/sh
exec 2>&1 \
envdir ./env \
sh -c '
exec \
softlimit ${DATALIMIT+"-d$DATALIMIT"} \
${PERL-perl} -T ./qpsmtpd-forkserver \
--listen-address "${IP-0}" \
--port "${PORT-25}" \
--limit-connections "${MAXCLIENTS-15}" \
--user "${QPUSER-smtpd}"
'
where all of those environment variables are assigned in ./env, so that ./config
contains only those values loaded by $self->config(). It would be easy to swap
that to using tcpserver instead, if that is desireable. Personally, I think we
should be recommending forkserver as the default method until Matt's work on
trunk becomes the default.
John
