Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

Yes but other programs might like to read values left behind by rc, using getenv On Wed, 18 Jan 2017, 23:51 Giacomo Tesio, wrote: > Yes that would be a plausible explanation but actually rc does not use > getenv: it reads /env/ files directly. > > I've tried to remove the loop

Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

Yes that would be a plausible explanation but actually rc does not use getenv: it reads /env/ files directly. I've tried to remove the loop and I can't see any issue. Giacomo 2017-01-18 21:13 GMT+01:00 Charles Forsyth : > Yes, it's the lists. Nothing will cope with

Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

Yes, it's the lists. Nothing will cope with \0 in a C string, so it's a good choice as list of string element separator. On 18 January 2017 at 19:21, Fran. J Ballesteros wrote: > rc lists? > > > El 18 ene 2017, a las 17:45, Giacomo Tesio escribió: > > > > Hi,

Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

rc lists? > El 18 ene 2017, a las 17:45, Giacomo Tesio escribió: > > Hi, last night I noticed this strange post processing in 4th edition's > getenv: > https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41 > >seek(f, 0, 0); >r = read(f,

Re: [9fans] Why getenv replaces \0 with spaces in the returned value?

Just a wild guess, but I think it could be because getenv just returns a null- terminated string with no indication of its length. If C code were to do pretty much anything on the environment variable in question, it would always be truncated. e.g. with VAR=ABC\0DEF, the C string processing

[9fans] Why getenv replaces \0 with spaces in the returned value?

Hi, last night I noticed this strange post processing in 4th edition's getenv: https://github.com/brho/plan9/blob/master/sys/src/libc/9sys/getenv.c#L34-L41 seek(f, 0, 0); r = read(f, ans, s); if(r >= 0) { ep = ans + s - 1; for(p = ans; p < ep; p++)