On Thu, Jul 21, 2011 at 21:03, Karel Zak <kzak@xxxxxxxxxx> wrote: > On Thu, Jul 21, 2011 at 08:37:52PM +0200, Sami Kerola wrote: >> > * I think that >> > -c, --class NUM >> > is better than >> > -c, --class=NUM >> >> With equals sign is FSFism, which seemed like good starting point... > > :-) > > The '=' is required only for optional arguments, the it's probably > the best to use > > --foo[=NUM] I've already forgot what was the original switch did, but that is exactly how optional argument should be marked up to make *nix command line tools to look & feel the same. Which IMHO is important for users. >> > I have fixed this in ionice man page, but not in usage(). It would be >> > nice to use in all man pages and usage() functions the same syntax. >> > Maybe we can create any template or so to have it documented. >> >> ...but you are absolutely right again. Converting README.devel in >> small chunks to a Documentation directory might be a way to go. > > Good idea! I'll propose in future something, unless someone else is quicker. >> BTW what would you think about having a util-linux.h with inline > > Should be enough to use c.h ? Possibly. >> function to print in usage help & version option descriptions and >> proper version output function. The first would make translation teams >> happier when they do not need to write time after time the same >> translations. Second would simply unify how version is printed, and if > > Well, .po files never contains duplicate strings. Yes and no. What I mean is this: util-linux/po grep -c 'display this help and exit' util-linux.pot 27 By writing the strings once & reusing the separated stings in usage() functions should fix the issue. >> In practice the file would be similar to coreutils system.h. > > Hmm... I don't like > > #define case_GETOPT_VERSION_CHAR(Program_name, Authors) > case GETOPT_VERSION_CHAR: > > We don't use the same char everywhere and hide keywords (e.g. case) > to macros is not nice too. > > It would be enough to use > > case 'V': > ul_print_version(); > break; > > The result should be readable C language, not any gnulib meta-language :-) Yup, I agree. Doing the very same as coreutils is possibly not a good match. Partially copying good ideas seems better, but that just requires bit of thinking which ideas apply well. Uh, programming is difficult. -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
