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