[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Corrupted multibyte characters in command substitutions fixes may be

From: Lawrence Velázquez
Subject: Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.
Date: Mon, 07 Feb 2022 00:18:28 -0500
User-agent: Cyrus-JMAP/3.5.0-alpha0-4586-g104bd556f9-fm-20220203.002-g104bd556

On Sun, Feb 6, 2022, at 11:53 PM, Alex fxmbsw7 Ratchev wrote:
> On Mon, Feb 7, 2022 at 12:02 AM Greg Wooledge <greg@wooledge.org> wrote:
>> There are other programming languages besides bash.  Some of them can
>> store NUL bytes internally, either by encoding and decoding them on the
>> fly, or by not using C-style strings internally (which means any system
>> calls require encoding/decoding the internal strings to C-style strings).
> i am not sure, but, tell me
> 'c strings' is a problem due to internal function handling with static \0 eof
> while 'c strings' can store null bytes no ? ( tell me if this is true
> or not plz )

It is not true.  C strings are terminated by NUL.

> then if, its up to the coding buddies to self code

How generous of you to volunteer other people's time and effort.

> its so simple:
> you have always static length strings simply, u conunt and know the
> length of every msg used, and so u can separate right
> isnt it so simple ?

It's so simple that you should have no problem converting the entire
bash codebase to Pascal-style strings yourself.  We'll wait.

>> I urge you to learn one of these other languages, and use it.
> i cant read others docs it seems buddy, it budds mee, its like the web
> docs about shell scripting, as you i and i wrote on our pages, its
> very invalid
> and so i cant learn a new language sorry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]