How to implement new features in myschema?

Folk, I am working on adding some features to myschema and I'm running out of sensible single letter mnemonics. I figure I have two alternatives: Use a master flag with options ala the -g flag in onstat or go all the wasy to GNU/POSIX style long options. The first solution is messy and I still would need single character mnemonics for new flags that take arguments. The latter solves that problem but will require me to include GNU getopt with the utils2_ak package which I've resisted doing until now (one or two utils support additional functionality if you link with GNU getopt, but I don't require it). If I go this way I'd have to create long alternatives to the existing options which means more coding <sigh>. Anyone have any strong preferences? Why? Art

Art S. Kagel wrote: > Folk, I am working on adding some features to myschema and I'm running out of > sensible single letter mnemonics. I figure I have two alternatives: Use a > master flag with options ala the -g flag in onstat or go all the wasy to > GNU/POSIX style long options. The first solution is messy and I still would > need single character mnemonics for new flags that take arguments. The latter > solves that problem but will require me to include GNU getopt with the > utils2_ak package which I've resisted doing until now (one or two utils > support additional functionality if you link with GNU getopt, but I don't > require it). If I go this way I'd have to create long alternatives to the > existing options which means more coding <sigh>. Anyone have any strong > preferences? Why? I sympathize - SQLCMD currently uses 15 lower-case and 19 upper-case option letters (and there are plans to use 8 more when - if - I integrate the SQLUPLOAD functionality into SQLCMD). I've always been a bit reluctant to use other GPL source in SQLCMD. (Yeah, I know the versions of SQLCMD on the IIUG web site are themselves GPL licenced, but that's for simplicity -- I could change the licence if I chose to do so. If I made any GPL code a mandatory part of the build, it would probably not be possible to change the licence. GNU Readline is optional - but it's also why the GPL is the sensible licence for the time being.) There are (at least) two problems -- backwards compatibility and how to go forward. POSIX does not mandate GNU-style long options, AFAIK. It uses single- letter options, supported on occasion by getsubopt(). You can do quite a lot with that combination; an option such as this is feasible: -f lo=11,hi=20,type="date",in="dd/mm/yyyy",out="yyyy-mm-dd" The extent to which that is usable is debatable - the DBLDFMT command uses some variations on this theme; so does ISEXTRACT. GNU getopt_long is quite a powerful choice. You can use arguments with the long options: --use-compress-program=bzip2 is one I type rather too frequently (to tar). The argument is attached to the option by the equals sign. So, you don't have to use single-character mnemonics for options with arguments. I am facing the same issue - and will probably go with GNU getopt_long() once I have a full set of options (A-Z plus a-z). There's a joke in 'The UNIX-Haters Handbook' about 'ls(1)' being the command that is trying for the full set of options; it hasn't got there quite yet. I've another program, fl, an alternative to 'ls' with lots of options (I counted them - to my astonishment, it too has 19 upper-case and 15 lower-case options!) and it is a toss-up which of them (sqlcmd or fl) will attain the full set first; probably sqlcmd, but not guaranteed. The other option to consider (pun intended) is to change from command line options to a command file. DB-Load already does this; ISEXTRACT does too, and to a large extent, so does SQLCMD. Offhand, I can't think of an option in SQLCMD that can't also be included in a script (but a closer scrutiny suggests a few - such as -h, -C, -U, -R, -P, -I); it's easy to think of some commands that can't be set on the command line but can in a script. Personally, I still like the power of a command line - a cleanly designed one, any way. I would not base anything on what the Informix utilities do - though onstat has one of the least noxious of the command line interfaces. Having said that, having the same option used twenty times on the command line, once for each field in a data file, does begin to tax the idea (DBLDFMT), let alone data files with hundreds of fields. sqlcmd --database=stores --mode=unload --table=customers \\ --output=cust.unl --format=csv --date-format="yyyy-mm-dd" sqlcmd -d stores -U -t customers -o cust.unl -F csv -A "yyyy-mm-dd" Ah well, by the time you have over 30 options, the clarity from the long options might well outweigh the cost of having to type them. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/