2019-12-24 12:16:41 -0500, Eli Schwartz:
[...]
> > Also note that sort -u and sort | uniq are not quite the same, the -u
> > option only considers the key fields when deciding which records (lines)
> > are unique (of course, with no key options, the whole line is the key,
> > in which case they are
Date:Tue, 24 Dec 2019 12:16:41 -0500
From:Eli Schwartz
Message-ID:
| Hmm, is that "more or less" the same, or actually the same?
It depends what other options are given (to each). With no options at all
they are probably the same.
kre
On 12/24/19 9:21 AM, Robert Elz wrote:
> The -u option appaeared in 7th edition Bell Labs Unix (1979) [I would
> assume it was actually implemented somewhat earlier, that's when 7th
> edition was released to the rest of the world.]
Thanks, the POSIX 2004 manual is just the earliest standard I can
Date:Tue, 24 Dec 2019 00:47:40 -0500
From:Eli Schwartz
Message-ID: <217b4a75-b79e-dc2a-a2b2-cc5133d7c...@archlinux.org>
| What is "recent" about sort -u? I can find it listed as a mandatory
| option in the POSIX 2004 manual.
The -u option appaeared in 7th edition
On 12/24/19 12:34 AM, L A Walsh wrote:
> I'm not sure what you want me to say about the range you chose,
> other than it would be about 128,000 characters. It would be about the
> same argument, for or against in using
> {241..128169}. I know you are trying to make some point, but
> I'm missing it
On 2019/12/23 12:58, Greg Wooledge wrote:
On Mon, Dec 23, 2019 at 12:52:00PM -0800, L A Walsh wrote:
But it wasn't. It was about generating characters between two
characters that were given. In unicode, that would be two code points.
Nothing about enumeration.
Please give an examp
On Mon, Dec 23, 2019 at 12:52:00PM -0800, L A Walsh wrote:
>But it wasn't. It was about generating characters between two
> characters that were given. In unicode, that would be two code points.
> Nothing about enumeration.
Please give an example, with a starting character and an ending
char
On 2019/12/23 05:20, Greg Wooledge wrote:
On Fri, Dec 20, 2019 at 04:35:05PM -0800, L A Walsh wrote:=
You can't simply translate $start and $end to single Unicode code point
values, enumerate the Unicode characters between those two points,
and translate those characters back to the user's lo
On 2019/12/21 22:38, Eli Schwartz wrote:
On 12/20/19 7:35 PM, L A Walsh wrote:
⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉
Q.E.D.
Is that sufficient proof?
It's sufficient proof that you're wrong, yes.
If you only knew how to use the tools you have on your machine.
Given the discussion was about collat
On Fri, Dec 20, 2019 at 04:35:05PM -0800, L A Walsh wrote:
> On 2019/12/18 11:46, Greg Wooledge wrote:
> > To put it another way: you can write code that determines whether
> > an input character $c matches a glob or regex like [Z-a]. (Maybe.)
> >
> > But, you CANNOT write code to generate all of
On 12/20/19 7:35 PM, L A Walsh wrote:
> On 2019/12/18 11:46, Greg Wooledge wrote:
>> To put it another way: you can write code that determines whether
>> an input character $c matches a glob or regex like [Z-a]. (Maybe.)
>>
>> But, you CANNOT write code to generate all of the characters from Z to
On 2019/12/18 11:46, Greg Wooledge wrote:
To put it another way: you can write code that determines whether
an input character $c matches a glob or regex like [Z-a]. (Maybe.)
But, you CANNOT write code to generate all of the characters from Z to a
This generates characters from decimal 8300
On 12/18/19 3:13 PM, Greg Wooledge wrote:
> On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
>> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
>> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
>> translate them into ascii. No locale awareness
On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
> translate them into ascii. No locale awareness is needed, no heuristics,
> no invocation of th
On 12/18/19 2:46 PM, Greg Wooledge wrote:
> Sorting these characters is also possible, once they have been generated.
> This is (I think!) what allows things like [Z-a] to work at all: you
> can check whether $c is >= 'Z' and <= 'a', without knowing what all of
> the characters in between are. But
On Wed, Dec 18, 2019 at 11:15:46AM -0800, L A Walsh wrote:
> On 2019/12/16 08:39, Greg Wooledge wrote:
> > The problem is, it is *not possible* to extract the set of characters
> > out of an arbitrary locale. The locale interfaces simply are not built
> > to allow it.
> >
> > You can do it in the
16 matches
Mail list logo
