Re: Additional feature for the seq command

[Axel Liljencrantz]

On Fri, 2005-04-29 at 01:37 -0700, Paul Eggert wrote:
> Axel Liljencrantz <address@hidden> writes:
> > seq a 3 h
> >
> > should output
> >
> > a
> > d
> > g
>
> Hmm, suppose someone wants the characters from '9' through ';'?

The way I implemented it, seq quits with an error message if you
specify a non-alphabetic character. It also checks that if you
specify the starting point of the sequence, it has the same case as
the end, so that only letters of the alphabet are used. In my mind, a
sequence from 9 to ; is something rather arbitrary. If you want to be
able to define an arbitrary sequence of characters from the current
character set, that is ok with me, but I would not do it since this
ties down behaviour to your specific character set.

> What about non-ASCII locales?  What order should the characters
> appear?

This is an excellent question. I'm glad you asked, since I've given
it a fair bit of thought. It might seem like a good idea to use the
character ordering of the current locale, so you can generate
sequences with all the strange characters of your locale in them. My
seq patch is not implemented that way. It outputs the ASCII sequence.
I did this since the way I want to use this feature is for doing
things with sets of data that is split in multiple files with names
like sampa.asc, sampb.asc, sampc.asc, etc.. Such sets are usually
generated by software, and do not use the current locale to decide
the file name. Since this is what I imagine to be the cost common use
case, that is what I implemented.

One could of course implement both by defining a -l switch to use the
current locale for character ordering information. I guess it would
be a bit harder to do it this way, since AFAIK there is no function
to get the character after the current one in the current locale. You
would have to construct a table of all characters and sort them, I
guess. If you feel this is worthwhile, I'm willing to do this if that
is what it takes to get my feature in. But I don't really see any
common use cases for this.

-- 
Axel Liljencrantz <address@hidden>