Ralph wrote:
Aside, it would be nice if scan's -width grew an "infinite" value as
9999 is a little kludgy. I was thinking `0',
There's an old enhancement request for that:
http://savannah.nongnu.org/bugs/?15274
So then I played a little bit.
$ scan -format '%{subject}' .
123456
$ scan -width 3 -format '%{subject}' .
12
Huh?
I think -width is avoiding printing in the last column to avoid an
unwanted linefeed? Either that, or it's out by one. I don't suppose
it's deliberately counting the `\n'.
Anyway, it's a bit off-putting to get `12' for a `-width 3', especially
after reading the fine man page.
Agreed, but it's been that way a long time. And I'm reluctant
to change it because it could break user scripts.
I think that a fix for both of these should include:
1) Instead of callers allocating the space for the fmt_scan()
output, have fmt_scan() do it. Callers would pass a **char
instead of a char array and be responsible for free'ing the
space when they're done.
2) fmt_scan() would use some function of width as the initial
size of the space and realloc by 2X as needed.
3) To not break existing user scripts, width would continue to
include the trailing newline. Add support for an optional
profile setting to not include the trailing newline.
4) Add support for 0 width indicating infinite width.
Or, for now, just document that -width includes the newline and
wait for the next dive into the format code.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers