On Sun, Jun 29, 2008 at 11:28:54PM +0100, Neil Mitchell wrote:

...

1. word-wrap the description to fit in 80 columns

(+1). 70 and 80 are defensible, anything else seems a bit of a weird choice for line length...

79 is also defensible, as some terminals wrap if you use the 80th column.

On Mon, 30 Jun 2008, Jon Fairbairn wrote:

Making it read the terminal width is clearly the best option.

It should be the maximum of the terminal width and 80 columns. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL: MAINLY SOUTHERLY 5 TO 7, OCCASIONALLY GALE 8 IN SHANNON, PERHAPS GALE 8 LATER IN ROCKALL, BECOMING CYCLONIC FOR A TIME. ROUGH OR VERY ROUGH. RAIN THEN FAIR. POOR BECOMING GOOD.

On 2008 Jun 30, at 15:17, Henning Thielemann wrote:

On Mon, 30 Jun 2008, Tony Finch wrote:

...

On Mon, 30 Jun 2008, Jon Fairbairn wrote:

...

Making it read the terminal width is clearly the best option.

It should be the maximum of the terminal width and 80 columns.

Did you mean the _minimum_ ?

Maximum, I suspect. As in "don't go nuts trying to fit it into someone's 16x22 pssh". -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Hello Ross, Monday, June 30, 2008, 12:40:28 PM, you wrote:

79 is also defensible, as some terminals wrap if you use the 80th column.

including windows:

type 80

12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 12345678901234567890123456789012345678901234567890123456789012345678901234567890 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Brandon S. Allbery KF8NH wrote:

On 2008 Jun 29, at 19:40, Isaac Dupree wrote:

...

maybe these can be resolved somehow without keeping really verbose documentation: what do other people think? Are these cases obscure but nevertheless standard cases of getopt since Unix/GNU history? (e.g. it seems that compilers behave differently from "normal programs", behave differently from everyone else's slightly different implementations of arguments)

On of the points of getopt is that -fFLAGS and -f FLAGS both work without any extra code. Standard getopt doesn't do optional arguments at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random options -v, -x, the former taking an optional argument; the latter two cases are recognized as argument omitted).

ah-ha, so it is an unpleasant behaviour of ambiguity resolution. Oh, well, I don't know what I want. But then saying "-v[n]" to me seems a little more misleading to say than "-v [n]" although they really mean the same thing (what if "-v[n]" makes me think "-v foobar.txt" would pass foobar.txt as a positional argument rather than a verbosity level?). Proposal #3 is to just say "-v". It took me a while to figure out how passing arguments to short and long options worked at all (one requires the presence of "=", the other requires its absence... again, except for exceptions such as ghc), so I might err on the side of being more verbose, less obscure. -Isaac

On Wed, 2008-07-02 at 06:40 -0400, Isaac Dupree wrote:

(which, incidentally, I was doing to try to find out why 'cabal fetch' doesn't seem to do anything. And failed miserably. No messages, no new directories in ~/.cabal/packages/hackage.haskell.org/ or in ./ ... Oh wait, fetching uvector works. Maybe it's because GHC comes with random-1.0.0.0 so cabal erroneously thinks it already has the source code that I want to look at, i.e. "for later installation *or study*" as `cabal --help` says?)

http://hackage.haskell.org/trac/hackage/ticket/297 "cabal fetch command don't fetch packages those have already been installed" It shouldn't be too hard to fix, so you're most welcome to send in a patch :-) Duncan

On 2008 Jul 2, at 6:40, Isaac Dupree wrote:

Brandon S. Allbery KF8NH wrote:

...

On of the points of getopt is that -fFLAGS and -f FLAGS both work without any extra code. Standard getopt doesn't do optional arguments at all; GNU getopt handles -vn, -v n, and -v -- or -v -x (for random options -v, -x, the former taking an optional argument; the latter two cases are recognized as argument omitted).

and we say cabal uses a getopt equivalent to this? Yet it doesn't work that way for me, in

We've apparently reinvented the situation that led to AT&T freeing the original getopt() code, I see :) People who roll their own getopt() clone usually miss the corner cases.

cabal-install 0.5.1:

...

cabal fetch -v 3 random cabal: Failed to parse package dependency: "3" cabal fetch -v3 random Reading installed packages... ("/usr/bin/ghc-pkg",["list"]) Reading available packages...

(which, incidentally, I was doing to try to find out why 'cabal fetch' doesn't seem to do anything. And failed miserably. No messages, no new directories in ~/.cabal/packages/ hackage.haskell.org/ or in ./ ... Oh wait, fetching uvector works. Maybe it's because GHC comes with random-1.0.0.0 so cabal erroneously thinks it already has the source code that I want to look at, i.e. "for later installation *or study*" as `cabal --help` says?)

-Isaac

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Jun 30, at 2:00, Johan Tibell wrote:

On Sun, Jun 29, 2008 at 11:46 PM, Duncan Coutts wrote:

...

So if people think this is sensible I'll send three patches: 1. word-wrap the description to fit in 80 columns 2. use less padding between columns 3. omit the args on short options when there is also a corresponding long option

What does GNU getopt do in all these cases? I'd prefer if the programs I use on the command line are consistent in their `--help' display and GNU getopt seems to be the standard here. Trying to follow what other people do also makes shell scripting easier.

Options are indented by two spaces. Short options are separated from long by ", ", and that column is left empty if there is no corresponding short option. Option descriptions begin one space after the longest option that doesn't extend past column 30, and word wrap with wrapped lines indented by two additional spaces. If any options go past column 30, their descriptions start one space after the options without attempting to align with the other descriptions, except that wrapped lines are aligned. Practical example: GNU sort

Ordering options:

Mandatory arguments to long options are mandatory for short options too. -b, --ignore-leading-blanks ignore leading blanks -d, --dictionary-order consider only blanks and alphanumeric characters -f, --ignore-case fold lower case to upper case characters -g, --general-numeric-sort compare according to general numerical value -i, --ignore-nonprinting consider only printable characters -M, --month-sort compare (unknown) < `JAN' < ... < `DEC' -n, --numeric-sort compare according to string numerical value -r, --reverse reverse the result of comparisons

Other options:

-c, --check check whether input is sorted; do not sort -k, --key=POS1[,POS2] start a key at POS1, end it at POS 2 (origin 1) -m, --merge merge already sorted files; do not sort -o, --output=FILE write result to FILE instead of standard output -s, --stable stabilize sort by disabling last-resort comparison -S, --buffer-size=SIZE use SIZE for main memory buffer -t, --field-separator=SEP use SEP instead of non-blank to blank transition -T, --temporary-directory=DIR use DIR for temporaries, not $TMPDIR or /tmp; multiple options specify multiple directories -u, --unique with -c, check for strict ordering; without -c, output only the first of an equal run -z, --zero-terminated end lines with 0 byte, not newline --help display this help and exit --version output version information and exit

Note --help and --version (no short options; also, they're boilerplate and apparently GNU getopt makes no attempt to match their descriptions' indentations with the other options, instead using a tab) and --temporary-directory (ends at column 31; word wrap matches the following option); also note the option groups are aligned independently. Also note the explanatory text about option arguments before the first option group. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Hi

Anyway, the maximum output width, as well as a maximum indentation for the option descriptions should be arguments to (new, additional) functions getOptExt and usageInfoExt, with the old getOpt and usageInfo being defined in terms of the new variants.

I think thats a really bad idea. We want options that work and do the sensible thing. When would a user want to set these options to different values? Without a use case, and a potential user, these extra variants are a waste of hard-drive space. Thanks Neil

Hi

...

I think thats a really bad idea. We want options that work and do the sensible thing. When would a user want to set these options to different values? Without a use case, and a potential user, these extra variants are a waste of hard-drive space.

I thought the use case I had in mind was apparent from the context: finding out the terminal width and then setting the wrap-width accordingly. And the max. description indentation could be set as a percentage of the terminal width. This is all quite similar to what pretty printing libs allow.

I'd suggest a much better idea would be to have one function which did all this, in the IO Monad. Some sort of showTheGetOptHelpWithTheRightWidth :: IO (). Before adding a function I think its important to ask "what will this function be used for" - if there are no particularly good answers, then its best not to add it. If it happens to be a general case of something where everyone will want a specific case then the specific case seems more appealing.

Generally I think that hard-coding numerical constants in code is nearly always a very bad idea.

Agreed :-) Thanks Neil