rosenkra@convex.com (William Rosencranz) (03/21/91)
while on the subject of standards, can i throw in my 2 cents on another
plead for consistency?
it would be really nice if unix-like programs on the ST (or anywhere, for
that matter) would include the following command line switches:
-debug to turn on internal debugging, if any
-help to print a usage synopsis
-version to print current program version
-changes to print major changes since last rev (or indicate
that this is first rev)
it makes life a little easier and is no big deal to program, viz:
for (argc--, argv++; argc && (**argv == '-'); argc--, argv++)
{
switch (*(*argv+1))
{
case 'd':
if (!strncmp (*argv, "-debug", 6))
{
debugging++;
break;
}
/* otherwise handle any "-d" option */
break;
case 'v':
if (!strncmp (*argv, "-vers", 5))
{
printf"%s\n", versionon);
exit (0);
}
/* otherwise handle any "-v" option */
break;
case 'h':
if (!strncmp (*argv, "-help", 5))
{
usage ();
exit (0);
}
/* otherwise handle any "-h" option */
break;
case 'c':
if (!strncmp (*argv, "-chang", 6))
{
changes ();
exit (0);
}
/* otherwise handle any "-c" option */
break;
/* any other options... */
}
}
i like debugging++ rather than debugging = 1 since you could potentially
have severall levels (-debug or -debug -debug or ...). if you really want
more generality, change to:
case 'H': /* for desktop's benefit */
case 'h':
if (!strncmp (stolower (*argv), "-help", 5))
{
/* stolower returns (char *) ptr after lowercasing
the string arg */
...
}
does this sound reasonable? i have adopted this myself for both unix and
TOS. i just wish P1003.2 would say something about this...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comwarwick@cs.uq.oz.au (Warwick Allison) (03/21/91)
In <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >while on the subject of standards, can i throw in my 2 cents on another >plead for consistency? >it would be really nice if unix-like programs on the ST (or anywhere, for >that matter) would include the following command line switches: > -debug to turn on internal debugging, if any > -help to print a usage synopsis > -version to print current program version > -changes to print major changes since last rev (or indicate > that this is first rev) -debug - Very rarely used, so should be #IFDEFed out in releaase. -help - No way! I MUCH prefer "man <command>" - and again, save on program size. -version - I totally agree, it takes no effort or space, and is useful for updates. -changes - No, stick it in the manual. See. Standards only work if they are inarguably beneficial. Personally, I write more GEM stuff than TOS stuff, and in THAT CASE, "help", "version" and "changes" are good things to include - because the average GEM user is _potentially_ a dim wit - so it goes to make the program more User Friendly. People who use command lines are used to using "man" or just "more"ing the documentation. Warwick. -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
plinio@crowe.seas.ucla.edu (Plinio Barbeito) (03/21/91)
In article <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: > >while on the subject of standards, can i throw in my 2 cents on another >plead for consistency? > >it would be really nice if unix-like programs on the ST (or anywhere, for >that matter) would include the following command line switches: > > -debug to turn on internal debugging, if any In a beta release of something, but for a bugless program? > -help to print a usage synopsis It would be nice to standardize this. Do people prefer sticking to the cryptic (but quick to type and group) single-letter options names, and typing the command without arguments to get usage info, or to chuck that pseudo-standard and start using descriptive tokens? > -version to print current program version > -changes to print major changes since last rev (or indicate > that this is first rev) [Code deleted...] >does this sound reasonable? i have adopted this myself for both unix and >TOS. i just wish P1003.2 would say something about this... Think what you are doing! You are trying to make Unix user-friendly, and force programmers to document their code AT THE SAME TIME. One of these would be unreasonable enough :-) (back to reality) Anyway, my two cents is that it's a tad too baroque. Maybe the -help or -version options would be useful, but it seems like not all applications would benefit from the clutter of informing the user that he can use an option to see the debugging output, for example. In the interest of speed and size, debugging output should go by the wayside in most cases, IMHO. To sum things up, I think the usefulness of your suggestion will depend on the specific application in mind ("tiny" versus "big enough to have an option called -verbose"). plin -- ----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu I don't think, I'm crazy.
rosenkra@convex.com (William Rosencranz) (03/21/91)
[ after re-reading my response, i should mention this is not any sort of personnal attack. no offense intended. i just like to debate :-) ] In article <324@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: >In <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>it would be really nice if unix-like programs on the ST (or anywhere, for ^^^^^^^^^^^^^^^^^^ i was not refering to gem stuff. and nor would i assume people who prefer gem are "_potentially_ dim wits". to each his own... >-debug - Very rarely used, so should be #IFDEFed out in releaase. i use it alot. and it can often help users who just want to see what goes on behind the scenes (i.e. seeking knowledge not found in a manpage) or are trying to find out why the command is not working the way they expect. i leave in debug stuff, regardless how much larger it makes the code, especially in large, complicated codes (like nroff). i am thinking about saving MY time, not the computer's. >-help - No way! I MUCH prefer "man <command>" - and again, save on program >size. the "save on program size" argument was fine in the days of < 64k memory and 160k floppies. this is 1991 and we can get megabytes for real cheap these days. i think you should start thinking about *your* time and not a couple of dollars saved on disk/memory. i am talking about less than 1k for all this, text+data. 1k out of 4 MB memory is nothing. 1k * 100 programs out of 60 MB (or even 20MB) of disk is nothing. less than 2 spectrum or 3 degas pictures, to put it in perspective. >-changes - No, stick it in the manual. often the manual does not match the program. putting a few lines out to the screen does not hurt here. i'd rather do: gcc -changes than wade thru endless readme (or worse: source) files, if they even exist! >See. Standards only work if they are inarguably beneficial. i think u are argumentative just for the sake of argument... all these things ARE beneficial. tell me, just who does it hurt? if u don't want to type "cmd -help", so don't. but lots of times i just plain forget lesser used options. like on (my) cc(1) which has a zillion options. or are u suggesting that we limit functionality to make use easier? doing "cc -help" and getting the info in a very terse, concise way is much faster than using man and wading thru pages of docs. i work mostly from home at 2400 baud. and believe me, reading man pages is no great joy. having a "-help" option in no way hurts my (sizable) ego. in fact, just the opposite: i would call the programmer considerate for not making me try to remember every single scrap of information without openning a book, electronic or otherwise. >Personally, I write more GEM stuff than TOS stuff, and in THAT CASE, "help", > "version" >and "changes" are good things to include - because the average GEM user is >_potentially_ >a dim wit - so it goes to make the program more User Friendly. People who use >command lines are used to using "man" or just "more"ing the documentation. boy, i sure hope you are not trying to sell your codes, after demeaning your potential customers :-) you are defeating your own argument: making code user friendly, even for (or ESPECIALLY for) experienced users is why we have computers in the first place. i'd rather the computer be my slave than visa versa. i have been using command lines for over 15 years. i have been using "man" for 7 years and NOS equivilents long before that. believe me, i am very used to it. before that i used cards and lugged around pounds of paper for my "man" command (let my fingers to the walking :-). but i also am keenly aware of what makes people productive programmers and users. and not having to stop and look something up is of great value to me, at least. if i can't remember the switch on make(1) to print out the internal macros (is it "-m" for "macro" or is it "-p" for "print" or is it "-z" because it is unix :-), i'd rather, in 1.5 seconds, do: % make -help usage: make [options] [definitions] [targets] options: -i ignore error codes -s silent -r no built-in rules -n no execute mode -t touch target files -q question -p print out macros -d debug mode -f file alternate makefile (searches for "makefile" then "Makefile") % about 275 bytes data, and about everything an experience user needs to know, though adding environment variable info is also helpful. self documenting code is the best, IMHO. and see, make DOES have a debug option! not #ifdef'd (at least alliant's make the closest *MANUAL* i had available :-)... incidently it took 25 seconds to find it in paper manual (another 30 sec to find the manual). "man make" would take about the same, maybe somewhat faster, maybe slower, depending on how many times "macro" appeared befor your PAGER's /string search found -p (i use less). or do i have to remember the propper search string, too? i am not blessed with a photographic memory. with a "-help" option, there is only one thing to remember: use -help for a command synopsis. i would wager that the average programmer has to remember millions of rules and facts. my goal is to try and minimize this so that he can concentrate on creative programming and deductions rather than remembering still more rules and facts. anyway, thanx for the input. i am not going to stop doing this in my programs which i post. i was just hoping that others would start doing it in theirs. since i post source, you are free to remove all this seemingly wasted space :-) question: if posix 1003.2 had said something like this, would u still disfavor it? just curious... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
rosenkra@convex.com (William Rosencranz) (03/21/91)
In article <2231@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito) writes: >In article <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >> -debug to turn on internal debugging, if any > >In a beta release of something, but for a bugless program? i never saw one :-). what is a "bugless program"? >> -help to print a usage synopsis >It would be nice to standardize this. Do people prefer sticking to >the cryptic (but quick to type and group) single-letter options names, i say stick to POSIX, whatever it may be, no matter how cryptic. at least you would potentially only have to learn it once. i think few people would be interested in *removing* what they expect in favor of tokens. however, *adding* tokens (not really what i was thinking, but a reasonable idea for novices) is fine. >and typing the command without arguments to get usage info, or to chuck not all commands can be typed without args. stdin is usually inferred as source of input. >that pseudo-standard and start using descriptive tokens? don't chuck anything (just as i was gettin used to unix after 6-7 years :-) >Think what you are doing! You are trying to make Unix user-friendly, >and force programmers to document their code AT THE SAME TIME. One of >these would be unreasonable enough :-) yikes! did i really say that? infinite and humblest apologies!!!! :-) >Anyway, my two cents is that it's a tad too baroque. Maybe the -help >or -version options would be useful, but it seems like not all >applications would benefit from the clutter of informing the user that >he can use an option to see the debugging output, for example. In the >interest of speed and size, debugging output should go by the wayside >in most cases, IMHO. ok, so skip the debug, tho i really think it can be valuable in debugging user data errors, believe it or not, if you do the debug with that in mind. the alternative is...what IS the alternative? proofread 100k of data looking for a typo? i HOPE not... >To sum things up, I think the usefulness of your suggestion will >depend on the specific application in mind ("tiny" versus "big enough >to have an option called -verbose"). no. these are additional thinks which you can count on to exist in all unix-like commands. it should be implicit. and not get in the way. i think "cmd -help" does not get in the way, is very descriptive, easy to remember, etc. >plin >-- >----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu >I don't think, I'm crazy. no, you're not crazy... -bill rosenkra@convex.com (i am...) -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
david@doe.utoronto.ca (David Megginson) (03/21/91)
Gnu already seems to have a standard for long options. The Gnu fileutils use either -v or +verbose, -r or +recursive, etc., and they have a function getopt1() to deal with the longer options. We should probably standardise this way, instead of using -help which could be an option -h with the argument `elp'. David -- //////////////////////////////////////////////////////////////////////// / David Megginson david@doe.utoronto.ca / / Centre for Medieval Studies meggin@vm.epas.utoronto.ca / ////////////////////////////////////////////////////////////////////////
warwick@cs.uq.oz.au (Warwick Allison) (03/22/91)
In <1991Mar21.065817.1799@convex.com> rosenkra@convex.com (William Rosencranz) writes: >In article <324@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: >>In <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>>it would be really nice if unix-like programs on the ST (or anywhere, for > ^^^^^^^^^^^^^^^^^^ >i was not refering to gem stuff. and nor would i assume people who prefer >gem are "_potentially_ dim wits". to each his own... I only meant GEM programs are easier to use. I PREFER GEM for complex programs, and command line for simple, repetitive commands. >Doing "cc -help" and getting the info in a very terse, concise way is >much faster than using man and wading thru pages of docs. i work mostly >from home at 2400 baud. and believe me, reading man pages is no great joy. Huh? Are we using ST's or University computers here? Or are we writing portable code or WHAT? >having a "-help" option in no way hurts my (sizable) ego. in fact, just >the opposite: i would call the programmer considerate for not making me >try to remember every single scrap of information without openning a book, >electronic or otherwise. Clearly, you are NOW talking about a SMALL amount of informative text or the -help option - this is a GOOD idea! But why not have a SYNOPSIS section in your manual... NAME cc - C compiler SYNOPSIS cc [ -a ] [ -align _block ] [ -Bbinding ] [ -c ] [ -C ] [ -dalign ] [ -dryrun ] [ -Dname [=def ] ] [ -E ] [ float_option ] [ -fsingle ] [ -g ] [ -go ] [ -help ] [ -Ipathname ] [ -J ] [ -Ldirectory ] [ -M ] [ -misalign ] [ -o outputfile ] [ -O[level] ] [ -p ] [ -P ] [ -pg ] [ -pic ] [ -PIC ] [ -pipe ] [ -Qoption prog opt ] [ -Qpath pathname ] [ -Qproduce sourcetype ] [ -R ] [ -S ] [ -sb ] [ -target target_arch ] [ -temp=directory ] [ -time ] [ -Uname ] [ -w ] sourcefile ... [ -llibrary ] This appears on the FIRST PAGE of the manual entry, so "man cc" and "cc -help" take exactly the same amount of time to use, in fact, to be pedantic: 1. "man cc" has less keystrokes than "cc -help" 2. The "man" program loads quicker than "cc" - man is smaller! And with man, if the SYNOPSIS doesn't tell you enough, then you can keep browsing the entry, with -help, you have to go to man in the end! Also, and this is my main gripe, too many programs have a -help option, but no man entry: the developer is just too lazy it seems. Ciaos to you all! Warwick. Sorry to all who would rather this was mail rather than news. -- _--_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.--._/ University of Queensland, v AUSTRALIA.
plinio@turing.seas.ucla.edu (Plinio Barbeito) (03/22/91)
In article <1991Mar21.071029.2289@convex.com> rosenkra@convex.com (William Rosencranz) writes: >In article <2231@lee.SEAS.UCLA.EDU> plinio@crowe.seas.ucla.edu (Plinio Barbeito) writes: >>In article <1991Mar20.204257.26740@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>> -debug to turn on internal debugging, if any >> >>In a beta release of something, but for a bugless program? > >i never saw one :-). what is a "bugless program"? (I knew I shouldn't have said bugless) Programs that do only one thing. Therefore, if they don't work (they don't do that one thing how you want), you throw them away. An example of this kind of program: a utility that prints the date. Typing "date -debug" is not something most people would be inclined to do. >not all commands can be typed without args. stdin is usually inferred >as source of input. True, but as you probably know, there is also the '-' convention. Type 'command', and you get help. Type 'command - < file' and you are sending that file to the stdin. The trouble with this is that the original convention (a la 'cat') of 'command < file' is more elegant in its simplicity. >mind. the alternative is...what IS the alternative? proofread 100k of >data looking for a typo? i HOPE not... In a release, the debugging is taken out (or not compiled in), that doesn't mean that the programmer couldn't have his own separate version, for debugging purposes. I didn't mean to imply that programmers wouldn't be deprived of their debugging facilities (if that is what you are implying that I implied). >>plin >>-- >>----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu >>I don't think, I'm crazy. > >no, you're not crazy... > >-bill >rosenkra@convex.com > >(i am...) To avoid any possible misunderstanding, my .sig is an offshoot of the following scenario (I think it came from MAD magazine): Elementary School Teacher: What's the answer? Student: What do you think it is? Teacher: I don't THINK, I know! Student (shrugging): Well I don't think I know either. Any followups on this to rec.humor... -- ----- ---- --- -- ------ ---- --- -- - - - plinio@seas.ucla.edu This page intentionally left blank so that it could contradict itself.
rosenkra@convex.com (William Rosencranz) (03/22/91)
In article <352@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: > Huh? Are we using ST's or University computers here? Or are we >writing portable code or WHAT? i was generalizing. if POSIX (which by *definition* means PORTABLE) were to adopt these, then even poor slobs like me with low speed access to big boxes running POSIX OSs (at work, in my case) benefit from not always having to man around for simple memory lapses... > Clearly, you are NOW talking about a SMALL amount of informative text >or the -help option - this is a GOOD idea! But why not have a SYNOPSIS section >in your manual... i ALWAYS was talking about this. i mean 1 screen or less, just enuf to get by. >NAME > cc - C compiler > >SYNOPSIS > cc [ -a ] [ -align _block ] [ -Bbinding ] [ -c ] [ -C ] > [ -dalign ] [ -dryrun ] [ -Dname [=def ] ] [ -E ] > [ float_option ] [ -fsingle ] [ -g ] [ -go ] [ -help ] ^^^^^ SEE!!! > [ -Ipathname ] [ -J ] [ -Ldirectory ] [ -M ] [ more of the same deleted ] ok, so what. i still don't know what "-c" means, just that it exists. however: cc -help ... -c compile to .o only (no link) ... tells me EXACTLY what i want to know (and quickly, since with man, i still need to page to find the propper switch for the functionality i want - i know the latter, not the former). this way i get BOTH sides of the equation: option = function. i agree, that SYNOPSIS from man cc may jog my memory enuf to get the right info. but u and i are experienced. others are not. this is one or the reasons unix has a bad rap for being cryptic and difficult to learn. once u do get into the philosophy, however, it is, of course, very nice and productive. but that can take months or even years. so consider "-help" an aid to novices (and us older folks with degrading memories...). again, YOU don't have to EVER type "-help". so i still don't see the problem here. there is never a problem when you have a choice NOT to do something which you can. there are potential problems, however, when you want to do something but can't. >Also, and this is my main gripe, too many programs have a -help option, >but no man entry: the developer is just too lazy it seems. i don't know of many besides my own with -help. and i use precious few gem programs because i can usually type faster than mouse. and i hate cleaning the damn thing all the time. but i agree 1000% about the laziness of (some) developers. if you take the time to write something, you should also make the extra effort to have people remember your name with fondness :-). i'd rather have someone say "nice total package" rather than "nice program, but i can't figure out how it works...documentation basically sucks...". pardon my french. i think it is better that some functionality is lost at the sake of documentation. i think it is better to have whatever is working clearly explained than have a zillion extra functions that, without documentation, can't be used anyway. i think we are getting closer to agreement here... -bill rosenkra@convex.com (not .edu :-) -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
rosenkra@convex.com (William Rosencranz) (03/22/91)
In article <2246@lee.SEAS.UCLA.EDU> plinio@turing.seas.ucla.edu (Plinio Barbeito) writes: >how you want), you throw them away. An example of this kind of >program: a utility that prints the date. Typing "date -debug" is not >something most people would be inclined to do. obviously -debug is more useful as program complexity increases. but, let's look at date(1) for a second. there is more going on behind the scenes than you may think (in a "propper" implementation). date sets the time, too. and there is the issue of GMT vs local time. and then there is the issue of converting unix epoch time to atari format for Settime and friends. i can think of at least a couple of things with date which would be useful for USERS not only the developer. the option for access to information is NEVER a bad one, no matter how voluminous it may get. >>not all commands can be typed without args. stdin is usually inferred >>as source of input. >True, but as you probably know, there is also the '-' convention. >Type 'command', and you get help. Type 'command - < file' and you >are sending that file to the stdin. NO NO NO NO!!! do NOT change the way we currently do things with unix. i don't want to have to type "ls -^D" or whatever. add, do not change. that is the whole purpose of standards. and so far, for us cmdline types, unix IS our standard. if you propose to change the way the ST can look like unix, you will get lots of angry hate mail, i suspect, or else be ignored. however, i you want to propose an entirely new user interface, have at it. you may come up with something truly good. afterall, unix is not perfect. >The trouble with this is that the >original convention (a la 'cat') of 'command < file' is more elegant >in its simplicity. bingo... >doesn't mean that the programmer couldn't have his own separate >version, for debugging purposes. I didn't mean to imply that >programmers wouldn't be deprived of their debugging facilities (if >that is what you are implying that I implied). of course the developer is not deprived. but why deprive the USER or (implied) developer? he may help you ferret out bugs. not everyone is going to recompile an application. and not all the stuff posted here is perfect. if it were, it would be sold, not given away. ok, i suppose -debug can go, reluctantly. but i was thinking more globally in scope here. like a certain set of rules guaranteed to be available for these types of applications. i was hoping for more ideas from the community to help me write better applications which can be used by more people than seasoned experts. things that are intuitive with little or no knowledge. telling someone "if all else fails, type 'help'" or "if all else fails when u try to execute 'cmd', type 'cmd -help'" is the sort of thing alot of people could benefit from. maybe not gurus, but most all <= guru level. ok, i've had enuf of this. move along... -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (03/23/91)
> -debug to turn on internal debugging, if any > -help to print a usage synopsis > -version to print current program version > -changes to print major changes since last rev (or indicate > that this is first rev) As others have commented, debug stuff doesn't belong in a released product, help stuff belongs in a separate "man page" if you really want to be Unix-like, and "what" or "ident" can report version and change history information. >does this sound reasonable? i have adopted this myself for both unix and >TOS. i just wish P1003.2 would say something about this... It (or else XPG2 and XPG3) does say something about your choice of options: they are unacceptable. They bless "getopt" as the means of parsing arguments. This means "-debug" should be interpreted as "-d -e -b -u -g" if any (or all?) of "-e", "-b", "-u" and "-g" are defined as options, or else it could be interpreted as "-d ebug", where "ebug" is an argument to "-d", and optional arguments are forbidden (ie, either an option takes an argument or it doesn't). In general, multi-character options beginning with "-" are frowned upon. Instead, use something like -A,debug -A,help ... or +debug +help ... -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
rosenkra@convex.com (William Rosencranz) (03/23/91)
In article <7340099@hpfcso.FC.HP.COM> mjs@hpfcso.FC.HP.COM (Marc Sabatella) writes: >help stuff belongs in a separate "man page" if you really want to be Unix-like i still can't understand why you all think -help (or whatever it may be called) is such a lousy idea. really, what can it hurt? why can't we have both man for detailed explanations, and an option in the command itself for just a synopsis % command <help_option_whatever_it_may_be_called_but_common_to_all> usage: command [options] file ... -a this does something -b this does something else ... one screen, max. i have absolutely nothing against man. heck, i just posted a version a couple of weeks ago. i also wrote nroff, and use it daily, but also find it extremely nice to just type "command -help" if i forget a lesser used option. with man, i have to 1) search for a keyword with its pager (i use less), 2) hope that the keyword i chose is indicative of what i am trying to find *quickly*, 3) hope that in addition to finding the keyword, i find the switch i was looking for. perhaps i should have said % command -synopsis rather than "-help" which seems to strike a bad chord here. >and "what" or "ident" can report version and change history information. what looks for SCCS/RCS id strings. so only if they exist can what work. the what i have seen (4.2BSD) searches for "@(#)" and "$H", for example. i have a version of what on my ST. and i don't know about you, but MY atari does not have SCCS, a licensed product from at&t. yes, i know we now have RCS at least. remember: we are talking about a possible standard for TOS applications on the ST for cmd shell users, not redesigning unix. you are forcing developers to use RCS just so a user can find out if he has the latest version of a program. is that really what you are saying? personally i think more people would use cmd shells if it was not so intimidating or cryptic. i think we will both agree that doing any kind of serious programming is far easier and far more productive from cmd shells (like gulam, bash, ksh, etc, which all happen to be or patterned after unix). and what is too verbose, especially if it finds version strings in every libc routine. granted, most implementations don't have id strings in libc, but in a swiftly changing environment like gnu c, for example, it might not be a bad idea. i was refering more to the the application itself: % command <version_option_whatever_it_may_be_called_but_common_to_all> command 1.1 91/3/23 % is this really that painful? or do you prefer strings `which command` | grep command as more "true to unix"? >It (or else XPG2 and XPG3) does say something about your choice of options: >they are unacceptable. They bless "getopt" as the means of parsing arguments. no. i almost never use getopt, prefering to hand code the option parser. i don't particularly like getopt myself and have seen few BSD or even USG commands which use it. and no, i have not looked at every single source file in unix, but i have looked at 40 or 50 command sources over the years. >doesn't). In general, multi-character options beginning with "-" are frowned >upon. check your manpage on man itself: man -S<number> ... with number scrunched next to the switch. there are other unix commands like this, eg troff -man ..., etc. and yes, you can claim that troff is not part of unix per se (except it is in BSD). i also realize that there are as many implementations of man as there are unix vendors, so don't beat me up because 4 or 5 of the ones i know about use this particular style. and if you ever looked at the manpage for gnu c, you'd probably go crazy (i did the first time, with all those 10+ char long options, though they may be unique to some number of characters). > Instead, use something like > > -A,help > +help ok. i really don't care what we call these, i was really more interested in providing the funtionality. if you want to use "+opt" or "@opt" or whatever, i really don't care. let's not quibble over specifics at this point. what about the basic idea itself, to provide the functionality? personnally, i find -A,help really cryptic, just to satisfy a weak programming practice. i can live with "+help", though i still find it more cryptic than "-help". i give up. let's move on (but all programs i post will have these features, so there! :-) -bill rosenkra@convex.com -- Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.com
schlut@oski.toppoint.de (Olaf Schlueter) (03/24/91)
rosenkra@convex.com (William Rosencranz) writes: > > while on the subject of standards, can i throw in my 2 cents on another > plead for consistency? > > it would be really nice if unix-like programs on the ST (or anywhere, for > that matter) would include the following command line switches: > > -debug to turn on internal debugging, if any > -help to print a usage synopsis > -version to print current program version > -changes to print major changes since last rev (or indicate > that this is first rev) > > does this sound reasonable? i have adopted this myself for both unix and > TOS. i just wish P1003.2 would say something about this... The unix style is single letter. As for help, if you use the (posix) getopt routine, -? should (and normally will) display short usage info (since getopt returns the option ? for each not recognized option). Either -v or -V usually gives version info (it should be possible to determine the version of a program for bug infos). In GNU this is accompanied by verbose mode, which is all of "debug" info a user should get. -changes is not needed. Updating the online manual is to prefer. -- Olaf Schlueter, Sandkuhle 4-6, 2300 Kiel 1, FRG, schlut@oski.toppoint.de "Someone is always the evil in the land, and then the good guys are marching, the eyes full of sand, into a holy war." Konstantin Wecker