Date: Wed, 28 Feb 2001 23:59:25 -0600 From: "Michael C . Wu" <keichii@iteration.net> To: Jonathan Graehl <jonathan@graehl.org> Cc: freebsd-Arch <freebsd-arch@FreeBSD.ORG>, i18n@freebsd.org Subject: Re: Unicode, command line options, and configuration files, oh my! Message-ID: <20010228235925.B4359@peorth.iteration.net> In-Reply-To: <NCBBLOALCKKINBNNEDDLAELNDLAA.jonathan@graehl.org>; from jonathan@graehl.org on Wed, Feb 28, 2001 at 01:48:49PM -0800 References: <NCBBLOALCKKINBNNEDDLAELNDLAA.jonathan@graehl.org>
next in thread | previous in thread | raw e-mail | index | archive | help
People, there is an freebsd-i18n@freebsd.org for a reason. On Wed, Feb 28, 2001 at 01:48:49PM -0800, Jonathan Graehl scribbled: | How much change would be needed to have a Unicode-capable FreeBSD system? A lot. and a lot more. | Supposing the variable-length encoding is used, all existing text output, | filenames, and string-based kernel interfaces should be compliant (although not No, they are not that easy. | capable of understanding multiple-byte-char input/output); would command line | options be passed as byte-strings by a Unicode-capable shell? No. | There doesn't seem to be any impetus to systematically adopt Unicode (especially | the fixed-two-bytes-per-char variant, which for most cases would simply double | the storage/bandwidth requirement), although there are user-applications which Not that easy :) Trust me. | operate on multibyte text. I am sure that by now admins and programmers in | country XYZ are used to working with ASCII and pseudo-English (no matter how | inconvenient it might be to generate from their keyboards). It is the "assuming" part that got us in this I18N dilemma. | [snip XML] I really do not think using XML is the way to go, too much crud. The K.I.S.S. principle should prevail here, especially in kernelland. | Parsing of command line options (and positional parameters) is also largely | ad-hoc. Looking through /usr/src, I see that for the most case, it consists of | a getopt loop with hand-coded cases, a hand-written usage string, and a | hand-written man-page-usage. Much like the XML DTD, it would make sense to | generically specify (to the extent possible, and with user-defined code to the | extent not) the syntax and semantics, and generate variable definitions, | parsing/checking code, usage(), man page synopsis ... While it would be Do you realize that this means a rewrite for the 300mb of the src/ that we have now? | possible to have an expressive grammar for command line options, typically | the -opts are order-independent, and there are only a few positional parameters | (or else you put the mess into a configuration file). There are a variety of | packages out there, which I am seeking opinions on, not having tried any of | them: | [snip *freshmeat* stuff] I have looked at those, not suitable, and they are GPL. | any others? | | ifconfig seemed to have one of the more enlightened-looking option parsers (an | array of parameter information processed in a loop, rather than a bunch of Because it needs to parse many many things. But why do you need so called "smart" parsers when you only have one or two options to parse? | hard-coded cases) out of several FreeBSD programs I examined ... are there any | other good examples? ipfilter. | It's also amusing to see how many different ways various servers in the tree can | open a configuration file (path read from command line), write a pid file (path | read from command line), daemonize, read an IP address/hostname and port (read | from command line) and listen there, mask nonfatal signals, relinquish It happens in a large code base. However, to rewrite all of that takes many many man-hours. I really do not think we are up to that. | priveleges - although I appreciate that different servers want to do things | slightly differently. Naturally, each of us is easily able to reuse our own | code (preferably by libraries/macros/#include rather than copy/paste), but I | think that there is a lot of common configuration/command-line code that could | be coalesced behind a good-enough-extensible interface that we could reuse code Glad to hear that people care about I18N. -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010228235925.B4359>