Environment variable issue

Marc Lehmann schmorp at schmorp.de
Mon Aug 19 16:08:16 CEST 2013


On Sun, Aug 18, 2013 at 09:37:12PM +0300, Adrian Sendroiu <molecula2788 at gmail.com> wrote:
> Marc Lehmann <schmorp at schmorp.de> writes:
> 
> > As far as I can see, this is exactly what happens. I am still confused
> > though - what you seem to report is some expectation of preservation when
> > you do NOT pass in sane values (or even valid ones) - empty strings have
> > no meaning in the environment, and thus there is no way to preserve them
> > in any sense of the word preservation - you can't even represent them in
> > the environment, so what should the semantic value of empty strings be?
> 
> I was referring to variables "c" and "e" from my initial example. I
> don't expect anything for the empty string one.

That's obviously not true, as this discussion shows. Imagine that an
empty string means "corrupt c and e with random data" (which is close to
what you reported) - I don't think you have that in mind as "preserving"
them. To avoid that, you require certain semantics for the empty string.

That is, your expectations *require* certain assumptions about the
semantics of the corrupted environment block (that it incidentally doesn't
have).

If you really don't expect anything for the empty string, then you have no
basis for your expectatoins for the other strings.

As a concrete and comparable example, imagine you corrupt half of your
hard disk, and then expect all the remaining data to be somehow preserved
or accessible by normal means. That expectation assumes that corrupting
data has no effect on other data that hasn't been corrupted, which
generally isn't the case.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\




More information about the rxvt-unicode mailing list