In article <87ttsxzxs7.fsf@fatphil.org>,
Phil Carmody <pc+usenet@asdf.org> wrote:
....
>> ls: h*: No such file or directory
>
>That I didn't know. Wow - if that's an actual interactive session being
>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?

Kinda hate to disagree with ya there, but running Linux on Apple hardware
is like buying a BMW, ripping out the engine, and changing it into a go-kart.

Now, before you think I'm some Apple Fanboy, let me assure you that just
the opposite is true. I run all Linux, but I consider it wrong to pay more
than $100 for the box upon which I run Linux. That's why I'm all Raspberry
Pi nowadays.

But if you've paid Apple's exhorbitant fee to buy their hardware, then you
might as well be running their OS. I don't want to have to dot all the I's
and cross all the T's on this, but I assume you get what I mean. If you
like Linux, you should not be paying Apple prices for your hardware.

Or, to put it another way, Apple stuff (hardware and software) is for
people who like that sort of thing. And they do indeed like it.

By the way, the car analogy is not accidental. I believe that the more you
pay for a car, the more problems you will have with it. You are literally
paying for the problems. And again, there are people who like that. So,
again, paying lots for a car is for people who like that sort of thing.
And they do indeed like it.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/IceCream

In comp.unix.programmer Muttley@dastardlyhq.com wrote:
> They both cause problems.

So do nuclear bombs and fentynyl, yet they have
not enough in common to make a sensible comparison
between them.

Similar reasoning applies to filenames with spaces
and the '-' stdin convention. Many people like
the former and are justified in doing so, but
nobody has the desire to use '-' as a filename.

I am tired of making this obvious point over and
over, so if it does not sink in now, I have to
give up.

br,
KK

On Thu, 17 Aug 2023 14:57:44 +0300
Phil Carmody <pc+usenet@asdf.org> wrote:
>Muttley@dastardlyhq.com writes:
>> Apple arguably are even worse right now - case aware but case insensitive
>> unless you use wildcards on the command line when suddenly case matters
>again.
>> Hopeless.
>>
>> eg:
>> fenris$ touch HELLO
>> fenris$ ls hello
>> hello
>> fenris$ ls H*
>> HELLO
>> fenris$ ls h*
>> ls: h*: No such file or directory
>
>That I didn't know. Wow - if that's an actual interactive session being

It is, its a cut and paste from the terminal.

>quoted, that's frightening. Thanks for reminding me why my installation
>of linux on my Apple G5 box wasn't moment too soon. How can people live
>with such wrongthink? Stockholm Syndrome?

I bought a Mac because I wanted a unix box that I could just switch on and
get coding rather than mess about installing some linux distro and hope the
bits all work. Plus MacOS has a bonus of lots of high quality apps on the
App Store. Though tbh if Solaris workstations were still a thing I'd have bought
one of them instead.

On Thu, 17 Aug 2023 13:52:23 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-08-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>
>> use spaces and non printing characters.
>
>That's simply false. 0 is the null terminator and is not actually part
>of the name. The path-component-separating slash cannot be contained in
>a path component; there is no escape mechanism to include it.

Ok, there are a couple of exceptions. Point still stands.

>POSIX defines a set of characters which are recommended for use in file
>names for portability; it is wise for applications and users to stick to
>that.

But they don't have to and when UTF8 filenames get used things can get messy
on non UTF8 terminals.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>In comp.unix.programmer Muttley@dastardlyhq.com wrote:
>> They both cause problems.
>
>So do nuclear bombs and fentynyl, yet they have
>not enough in common to make a sensible comparison
>between them.
>
>Similar reasoning applies to filenames with spaces
>and the '-' stdin convention. Many people like
>the former and are justified in doing so, but
>nobody has the desire to use '-' as a filename.
>
>I am tired of making this obvious point over and
>over, so if it does not sink in now, I have to
>give up.

It's like arguments about how many angels can dance
on the point of a pin - the use of a single hyphen
to denote stdin will _never_ change, it is pointless
to assume otherwise.

On Thursday, 17 August 2023 at 14:58:01 UTC+3, Phil Carmody wrote:
> Mut...@dastardlyhq.com writes:
> > On Tue, 15 Aug 2023 23:32:22 +0300
> > Phil Carmody <pc+u...@asdf.org> wrote:
> >>Mut...@dastardlyhq.com writes:
> >>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
> >>> kal...@kolttonen.fi (Kalevi Kolttonen) wrote:
> >>>>Kenny McCormack <gaz...@shell.xmission.com> wrote:
> >>>>> But do they know that???
> >>>>
> >>>>"They" probably don't know it. But let's face it,
> >>>>nobody really wants to create a file having '-'
> >>>>filename on purpose. The filename is not descriptive
> >>>>at all, it would be just an insane choice for anything
> >>>>useful.
> >>>
> >>> I used to think the same thing about spaces in filenames. Then along came
> >>> Windows.
> >>
> >>Your memory if flawed. Spaces were always allowed in unix
> >>filenames. Often used to hide things in plain sight on FTP sites, for
> >>example.
> >
> > Any character from 0-255 is allowed in unix filenames but only an idiot would
> > use spaces and non printing characters.
> >
> >>MS Windows didn't allow spaces until Windows 95. I remember the Apple
> >
> > DOS didn't like filenames more than 8 characters long and required a TLA.
> > So what?
> >
> > It has become a standard in windows to use spaces in filenames no doubt due
> > to the hopeless command line interface so there was no necessity to play nice
> > with command line tools that by default use whitespace as field seperators.
> >
> >>had it on my wall at work. Not because I was an Apple fanboi, far
> >>from it, but my disdain for all things MS Windows was already
> >>entrenched, and I was being forced to use it for the not-the-actual-work
> >>part of my job (which was on Sun workstations).
> >
> > Apple arguably are even worse right now - case aware but case insensitive
> > unless you use wildcards on the command line when suddenly case matters again.
> > Hopeless.
> >
> > eg:
> > fenris$ touch HELLO
> > fenris$ ls hello
> > hello
> > fenris$ ls H*
> > HELLO
> > fenris$ ls h*
> > ls: h*: No such file or directory
>
> That I didn't know. Wow - if that's an actual interactive session being
> quoted, that's frightening. Thanks for reminding me why my installation
> of linux on my Apple G5 box wasn't moment too soon. How can people live
> with such wrongthink? Stockholm Syndrome?
>
Software developers are not humans, but engineers. Need to build for
iPhone so you use mac. Actually device itself is quite good, only the OS is bit
garbage. Mixed case sensitivity / insensitivity is "feature" of HFS+ filesystem.
Majority of software aren't made to expect something so strange. So number
of common tools can be confused. But ... confusing tools can be avoided and
pranksters calmed down.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.
>
> That's simply false. 0 is the null terminator and is not actually part
> of the name. The path-component-separating slash cannot be contained in
> a path component; there is no escape mechanism to include it.
>
> POSIX defines a set of characters which are recommended for use in file
> names for portability; it is wise for applications and users to stick to
> that.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_282

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Muttley@dastardlyhq.com writes:

> On Tue, 15 Aug 2023 23:32:22 +0300
> Phil Carmody <pc+usenet@asdf.org> wrote:
>>Muttley@dastardlyhq.com writes:
>>> On Tue, 15 Aug 2023 16:12:19 -0000 (UTC)
>>> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>>> But do they know that???
>>>>
>>>>"They" probably don't know it. But let's face it,
>>>>nobody really wants to create a file having '-'
>>>>filename on purpose. The filename is not descriptive
>>>>at all, it would be just an insane choice for anything
>>>>useful.
>>>
>>> I used to think the same thing about spaces in filenames. Then along came
>>> Windows.
>>
>>Your memory if flawed. Spaces were always allowed in unix
>>filenames. Often used to hide things in plain sight on FTP sites, for
>>example.
>
> Any character from 0-255 is allowed in unix filenames but only an idiot would
> use spaces and non printing characters.

To some extent it depends on the file system, and to some extent it's
down to the kernel, but I don't know of any Unix/FS combination that
permits 0 (null) bytes in file names. I can't see how it could work.

And almost all file systems will prohibit the use of / in a file name,
though I've heard you can trick NFS into taking it.

Some file systems (depending on mount options) can have complex rules
such as rejecting any name with an invalid UTF-8 sequence.

--
Ben.

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <87ttsxzxs7.fsf@fatphil.org>,
> Phil Carmody <pc+usenet@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>>That I didn't know. Wow - if that's an actual interactive session being
>>quoted, that's frightening. Thanks for reminding me why my installation
>>of linux on my Apple G5 box wasn't moment too soon. How can people live
>>with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS.

Hahahah. Nah, never paid a penny. It was a "sponsorship" from Apple.
Top of the range kit at the time too. All I had to do was write fast
code and not insult them in public. Managed for several years.

Oh - my code ran faster under linux than OSX. The apple compiler seemed
to never want to use all 32 of the FP registers (and, more bizarrely,
the register it would mysteriously forget existed wasn't always the same
one). I later worked for Freescale and had access to their internal
tools, and could see how good or bad a job the various compilers were at
keeping the pipelines full, and it was clear that Apple weren't as smart
as they thought they were.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 17/08/2023 16:09, Kenny McCormack wrote:
> In article <87ttsxzxs7.fsf@fatphil.org>,
> Phil Carmody <pc+usenet@asdf.org> wrote:
> ...
>>> ls: h*: No such file or directory
>>
>> That I didn't know. Wow - if that's an actual interactive session being
>> quoted, that's frightening. Thanks for reminding me why my installation
>> of linux on my Apple G5 box wasn't moment too soon. How can people live
>> with such wrongthink? Stockholm Syndrome?
>
> Kinda hate to disagree with ya there, but running Linux on Apple hardware
> is like buying a BMW, ripping out the engine, and changing it into a go-kart.
>
> Now, before you think I'm some Apple Fanboy, let me assure you that just
> the opposite is true. I run all Linux, but I consider it wrong to pay more
> than $100 for the box upon which I run Linux. That's why I'm all Raspberry
> Pi nowadays.
>
> But if you've paid Apple's exhorbitant fee to buy their hardware, then you
> might as well be running their OS. I don't want to have to dot all the I's
> and cross all the T's on this, but I assume you get what I mean. If you
> like Linux, you should not be paying Apple prices for your hardware.
>
> Or, to put it another way, Apple stuff (hardware and software) is for
> people who like that sort of thing. And they do indeed like it.
>

I disagree completely.

Apple made good quality hardware, with a style that many people like.
(I personally do not, and have never owned anything Apple.) Sure, you
pay a premium for it, but that's the case for a lot of hardware - if you
draw a graph of processor speed against processor price, you'll easily
see a point where you pay a lot of extra cash for a very small increase
in price. Yet for some people, that large increase is worth it.

So your Apple hardware might be twice the price for a 10% thinner and
lighter laptop. But if that's what you want, go for it - just as it is
fine to want far lower prices and accept slower or weaker hardware.

Then if someone decides that they want the Apple hardware, they've got
the money, they have no moral qualms about paying the high markup Apple
charges (some people have strong opinions about that kind of thing),
that's fine - they've bought the Apple hardware.

And if they decide that they prefer Linux (or Windows) to MacOS, then
installing their preferred system makes the system better - it increases
the value to them. It would be absurd to use an OS that is inferior (at
least in that person's view) just because they had paid for it! You
would not expect a Linux fan to use the Windows installation that comes
with most off-the-shelf PC's - why would you expect them to use MacOS ?

Case in point - Linus Torvalds used a MacBook running Linux as his main
PC for a while, because the hardware (the screen in particular) was
better than alternative laptops.

On 17/08/2023 15:52, Kaz Kylheku wrote:
> On 2023-08-17, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Any character from 0-255 is allowed in unix filenames but only an idiot would
>> use spaces and non printing characters.

Only an idiot would think one rule fits all use-cases.

>
> That's simply false. 0 is the null terminator and is not actually part
> of the name. The path-component-separating slash cannot be contained in
> a path component; there is no escape mechanism to include it.
>
> POSIX defines a set of characters which are recommended for use in file
> names for portability; it is wise for applications and users to stick to
> that.
>

It is even wiser to use characters that are appropriate for the task in
hand.

If you are making software that will be shared amongst a wide variety of
systems, stick to ASCII letters, digits, and underscore - that will work
on everything, including Windows.

If you are writing a document in Thai that will be read by Thai speakers
on Thai computers, name the document in Thai using Thai script.

It's not hard to handle "complicated" filenames from the command line,
outside a few pathological cases (like "-"). Sensible filenames are
fine, even with spaces, brackets, or non-ASCII letters. If those
features are helpful to the main use of the names for the files in
question, use them. If they are unhelpful, don't use them.

Thus it makes sense to avoid inconvenient characters in the names and
paths of programs, and you'll very rarely want them in program source
code names or directories. But they are common and useful for things
like document filenames.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Some file systems (depending on mount options) can have complex rules
> such as rejecting any name with an invalid UTF-8 sequence.

Oooh, now I'm tempted to name files in Latin-1, to deliberately break
filesystems that make such assumptions!

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 8/19/23 1:33 PM, Phil Carmody wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!
Be careful with that attitude. The "memory-safe" sudo replacement
doesn't support non-UTF-8 input either:

https://github.com/memorysafety/sudo-rs/issues/213

On Sat, 19 Aug 2023 16:15:32 +0300
=?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>On 8/19/23 1:33 PM, Phil Carmody wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Some file systems (depending on mount options) can have complex rules
>>> such as rejecting any name with an invalid UTF-8 sequence.
>>
>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>> filesystems that make such assumptions!
>Be careful with that attitude. The "memory-safe" sudo replacement
>doesn't support non-UTF-8 input either:

Whats memory unsafe about sudo?

Phil Carmody <pc+usenet@asdf.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Some file systems (depending on mount options) can have complex rules
>> such as rejecting any name with an invalid UTF-8 sequence.
>
> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
> filesystems that make such assumptions!

Why?

--
Ben.

Muttley@dastardlyhq.com writes:
>On Sat, 19 Aug 2023 16:15:32 +0300
>=?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>>On 8/19/23 1:33 PM, Phil Carmody wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Some file systems (depending on mount options) can have complex rules
>>>> such as rejecting any name with an invalid UTF-8 sequence.
>>>
>>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>>> filesystems that make such assumptions!
>>Be careful with that attitude. The "memory-safe" sudo replacement
>>doesn't support non-UTF-8 input either:
>
>Whats memory unsafe about sudo?
>
https://www.cisa.gov/news-events/alerts/2021/02/02/sudo-heap-based-buffer-overflow-vulnerability-cve-2021-3156

On Sun, 20 Aug 2023 17:24:46 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Sat, 19 Aug 2023 16:15:32 +0300
>>=?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>>>On 8/19/23 1:33 PM, Phil Carmody wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> Some file systems (depending on mount options) can have complex rules
>>>>> such as rejecting any name with an invalid UTF-8 sequence.
>>>>
>>>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>>>> filesystems that make such assumptions!
>>>Be careful with that attitude. The "memory-safe" sudo replacement
>>>doesn't support non-UTF-8 input either:
>>
>>Whats memory unsafe about sudo?
>>
>https://www.cisa.gov/news-events/alerts/2021/02/02/sudo-heap-based-buffer-overf
>low-vulnerability-cve-2021-3156

One bug in one version doesn't make it generally unsafe.

Muttley@dastardlyhq.com writes:
> On Sat, 19 Aug 2023 16:15:32 +0300
> =?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com> wrote:
>>On 8/19/23 1:33 PM, Phil Carmody wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Some file systems (depending on mount options) can have complex rules
>>>> such as rejecting any name with an invalid UTF-8 sequence.
>>>
>>> Oooh, now I'm tempted to name files in Latin-1, to deliberately break
>>> filesystems that make such assumptions!
>>Be careful with that attitude. The "memory-safe" sudo replacement
>>doesn't support non-UTF-8 input either:
>
> Whats memory unsafe about sudo?

It's not written in a language whose extremely complicate runtime system
that's conjectured to be bug free in this respect by Really Wishful
Thinking[tm] is supposed to prevent simple memory access errors C
supports.

In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
....
>It's not written in a language whose extremely complicate runtime
>system that's conjectured to be bug free in this respect by Really
>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>C supports.

What language was this quoted paragraph written in?

Preumably one in which word order doesn't matter.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Reaganomics

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>Rainer Weikusat <rweikusat@talktalk.net> wrote:
>...
>>It's not written in a language whose extremely complicate runtime
>>system that's conjectured to be bug free in this respect by Really
>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>C supports.
>
>What language was this quoted paragraph written in?
>
>Preumably one in which word order doesn't matter.

Word order in German and English don't always agree.

Basically he is saying, somewhat mockingly, that because it is
not written in Rust, sudo written in C is inherently memory unsafe.

In article <g3zEM.718458$AsA.196497@fx18.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>...
>>>It's not written in a language whose extremely complicate runtime
>>>system that's conjectured to be bug free in this respect by Really
>>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>>C supports.
>>
>>What language was this quoted paragraph written in?
>>
>>Preumably one in which word order doesn't matter.
>
>Word order in German and English don't always agree.
>
>Basically he is saying, somewhat mockingly, that because it is
>not written in Rust, sudo written in C is inherently memory unsafe.

OK, thanks.

I am glad that you were able to intuit that "Rust" was "the other language"
involved in the comparison.

--
They say compassion is a virtue, but I don't have the time!

- David Byrne -

On Mon, 21 Aug 2023 01:26:36 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>...
>>>It's not written in a language whose extremely complicate runtime
>>>system that's conjectured to be bug free in this respect by Really
>>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>>C supports.
>>
>>What language was this quoted paragraph written in?
>>
>>Preumably one in which word order doesn't matter.
>
>Word order in German and English don't always agree.
>
>Basically he is saying, somewhat mockingly, that because it is
>not written in Rust, sudo written in C is inherently memory unsafe.

To do anything low level Rust has to disable memory protection (or whatever
they call it) anyway, so its no safer than C/C++ in these circumstances.

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <g3zEM.718458$AsA.196497@fx18.iad>,
> Scott Lurndal <slp53@pacbell.net> wrote:
>>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>>In article <87lee55t51.fsf@doppelsaurus.mobileactivedefense.com>,
>>>Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>...
>>>>It's not written in a language whose extremely complicate runtime
>>>>system that's conjectured to be bug free in this respect by Really
>>>>Wishful Thinking[tm] is supposed to prevent simple memory access errors
>>>>C supports.
>>>
>>>What language was this quoted paragraph written in?
>>>
>>>Preumably one in which word order doesn't matter.
>>
>>Word order in German and English don't always agree.
>>
>>Basically he is saying, somewhat mockingly, that because it is
>>not written in Rust, sudo written in C is inherently memory unsafe.
>
> OK, thanks.
>
> I am glad that you were able to intuit that "Rust" was "the other language"
> involved in the comparison.

That's pretty obvious from the

,----
| Be careful with that attitude. The "memory-safe" sudo replacement
| doesn't support non-UTF-8 input either:
|
| https://github.com/memorysafety/sudo-rs/issues/213
`----

upthread. Rust is conjectured to be memory safe because people using it
really want to believe that the Rust runtime - some orders of magnitude
more complicated than a real lot of C programs - has not such bugs.

In article <87v8d8jrpo.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> wrote:
....
>,----
>| Be careful with that attitude. The "memory-safe" sudo replacement
>| doesn't support non-UTF-8 input either:
>|
>| https://github.com/memorysafety/sudo-rs/issues/213
>`----

That URL means nothing to me. But that's just me. Don't take it
personally.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Seriously

gazelle@shell.xmission.com (Kenny McCormack) writes:
> In article <87v8d8jrpo.fsf@doppelsaurus.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
> ...
>>,----
>>| Be careful with that attitude. The "memory-safe" sudo replacement
>>| doesn't support non-UTF-8 input either:
>>|
>>| https://github.com/memorysafety/sudo-rs/issues/213
>>`----
>
> That URL means nothing to me. But that's just me. Don't take it
> personally.

In this case, I suggest one of two options

1) You'll try to memorize that rs commonly means Rust. Eg, it's usually
the extension used for Rust source files.

2) You'll ask your full-time carer to click on the link for you and read
the content of the page to you.

In either case, posting more lame flames into this groups for no
conceivable reason is not going to improve your understanding of
anything.