<div dir="ltr">Hi Olaf,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Apologies for the late follow-up. Shame on me for pinging you on the<br>
bug report for no follow-up for a long time and then ignoring it when<br>
you promptly send some. :-(<br>
<br></blockquote><div><br></div><div>No a<span style="color:rgb(33,33,33)">pologies needed. We know how it works.</span><div><span style="color:rgb(33,33,33)"><br></span></div><div><span style="color:rgb(33,33,33)">I was just waiting for your reply. My changes were already at github (and just rebased):</span></div><div><span style="color:rgb(33,33,33)"><a href="https://github.com/luizluca/sane-backends/tree/reorganize-saned-args">https://github.com/luizluca/sane-backends/tree/reorganize-saned-args</a></span></div><div> <br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>> If there is no clear use case, perhaps saned should not provide them.<br>
>> In that case, I'd remove:<br>
>> - -D and make running in the background the default because saned is<br>
>> normally meant to run as a daemon<br>
><br>
> I beg to disagree. It's not true for (x)inet, systemd nor procd. They do<br>
> expect process in foreground. Only running saned standalone might need it<br>
> to go background. Also, I think that changing the default behavior is even<br>
> more traumatic than changing any behavior of options.<br>
<br>
Rethinking this, I guess you're right. It's not much effort to manually<br>
background a daemon, simply add an `&` at the end of the command-line.<br></blockquote><div><br></div><div>An `&` is not enough as there are some extra logic when going backgroud. `-D` do just that.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Something for the Release Notes as Changelog is built from git log. Is<br>
> there any place to save relevant changes for the next release?<br>
<br>
Eh, I guess the NEWS file would be as good a place as any. Something<br>
like<br>
<br>
New with the development version, not yet released:<br>
<br>
@Allan> Does that look okay?<br>
<br></blockquote><div><br></div><div><div><font color="#212121">I'll just wait for the "NEWS" answered you asked </font><span style="color:rgb(33,33,33)">@Allan</span><span style="color:rgb(33,33,33)"> in order to update only that and send patches to ML.</span></div><br class="inbox-inbox-inbox-inbox-inbox-inbox-Apple-interchange-newline">>> You mention something about creating a PID file for the -u option. That<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> made me think a -p option to specify where you want that file might be a<br>
>> nice addition. The current location, /var/run/saned.pid, is hard-coded.<br>
>> It's not a bad location but one may want to change it.<br>
><br>
> I'll take a look. Normally PID file location is something for a<br>
> configuration file.<br>
> Sometimes init would like to take care of the PID file life cycle. Besides<br>
> being hard-coded, if a previous PID file exists, saned should do some<br>
> checks, and abort on failure. Today, if someone manage to run two instances<br>
> of a stand-alone saned, the last one would simply overwrite its own PID<br>
> inside the PID file. Also it should replace PID file instead of simply<br>
> rewriting it. At least it would avoid different code paths (and permission<br>
> requirements) whether a file at PID file exists or not.<br>
<br>
Looks like any user with write access to the directory holding the PID<br>
file can clobber it because<br>
<br>
pidfile = fopen (SANED_PID_FILE, "w");<br>
<br>
doesn't pass O_EXCL to the underlying open().<br>
<br>
On my devuan box, /var/run is a symlink to /run which has 755 perms and<br>
is owned by root. Digging further, /run is actually a mount point for a<br>
tmpfs. But anyway, not all systems are created equally.<br></blockquote><div><br></div><div>I'll leave PID_FILE as is for now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> Oh, about the code changes, there are a few places in the manual page<br>
>> I'd change to improve the English but I can do that for you. There is<br>
>> one mistake though, you document a -B option (as if it were -D).<br>
><br>
> Yeah, english skill aren't really my "expertise". :-) I do know my<br>
> limitations. Feel free to point me or correct them directly.<br>
<br>
I'll correct them directly (if there are any ;-). It's less overhead<br>
for both of us.<br></blockquote><div><br></div><div>OK for me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS: I'll be travelling a bit in the next two weeks so will probably be<br>
late again in following up.<br></blockquote><div><br></div><div>Nobody is at a hurry.</div><div><br></div><div>Regards,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27<br>
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9<br>
Support Free Software <a href="https://my.fsf.org/donate" rel="noreferrer" target="_blank">https://my.fsf.org/donate</a><br>
Join the Free Software Foundation <a href="https://my.fsf.org/join" rel="noreferrer" target="_blank">https://my.fsf.org/join</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><p dir="ltr">Luiz Angelo Daros de Luca<br>
<a href="mailto:luizluca@gmail.com">luizluca@gmail.com</a></p>
</div></div>