Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

2022-02-07 Thread Alex fxmbsw7 Ratchev
On Mon, Feb 7, 2022 at 7:45 AM Lawrence Velázquez wrote: > > On Mon, Feb 7, 2022, at 1:26 AM, Alex fxmbsw7 Ratchev wrote: > > well i saw now, printf a char of "\0" results in 0 bytes out to wc -c > > % /usr/bin/printf '\0' | wc -c >1 > > > > however my solution still stays > > you just use

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

2022-02-07 Thread Frank Heckenbach
> In the case of bash with environment having LC_CTYPE: C.UTF-8 or > en_US.UTF-8 > read: > 0xC3 (len=1) i.e. Ã ('A' w/tilde in a legacy 8-bit latin-compatible > charset), > but invalid if bash processes the environment setting of en_US.UTF-8. > > Should bash process it as legacy input or invali

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

2022-02-07 Thread Ángel
On 2022-02-07 at 11:55 +0100, Alex fxmbsw7 Ratchev wrote: > > > however my solution still stays > > > you just use memory locations instead of c strings > > > and those entries in memory are of course of known length, before > > > setting and all is fine > > > > "Your" solution is decades old. Ev

Re: Corrupted multibyte characters in command substitutions fixes may be worse than problem.

2022-02-07 Thread Alex fxmbsw7 Ratchev
On Tue, Feb 8, 2022 at 12:09 AM Ángel wrote: > > On 2022-02-07 at 11:55 +0100, Alex fxmbsw7 Ratchev wrote: > > > > however my solution still stays > > > > you just use memory locations instead of c strings > > > > and those entries in memory are of course of known length, before > > > > setting an