Environment variable issue

Marc Lehmann schmorp at schmorp.de
Tue Aug 20 08:17:04 CEST 2013

On Mon, Aug 19, 2013 at 11:47:05PM +0300, Adrian Sendroiu <molecula2788 at gmail.com> wrote:
> Marc Lehmann <schmorp at schmorp.de> writes:
> I don't expect anything for the invalid entries. I expect valid entries
> to remain valid.

And this is exactly what happens.

> > However, "majority" is a red herring - we are not talking about corrupting
> > the majority of the data, but about passing in corrupted data and
> > expecting that to be interpreted in a specific way. For the filesystem
> > example, that would mean /usr is corrupted but the directories inside are
> > still visible.
> For the filesystem example that would mean that the entire data is still
> there, even if you corrupt the /usr's inode. Whether it is visible or
> not it's not relevant for this analogy.

It's in fact the only relevant part of this analogy - if you corrupt parts
of the storage, it can become inaccessible in other parts. Your assumption
about the semantics of the empty string amounts of assuming that the
filessstem magically repairs the corrupted structure, which is not even
possible in all cases.

> A filesystem is a more complex structure, with various links between
> items.

The environment is linked in a multitude of ways too, of course - they
have to be in a list and the keys have to have certain structure (they
must all be unique for example).

> There is no connection between environment entries.

An obvious connection is that the keys must be distinct.

> Unfortunately, not even the "the data is still there" assertion holds
> in this case.

> You pass 100 valid entries

But that's not the case in your example, unless you employ a specific
interpretation for the corrupted entry, as has been demonstrated.

> and 1 invalid entry and end up with 101 invalid entries.

That's a hypothetical case that's hasn't anything to do with this case, as
this doesn't happen, right?

> This sounds like corrupting the majority of the data to me.

No, in the case at hand, you hand in corrupted data, and expect urxvt to
repair it for you. Urxvt does not corrupt any data whatsoever.

> Especially when there should be no relation between those items.

I don't know what should be the case, but whether the environment should be
changed in some way is pretty irrelevant for this point - the unix
environment works as it does, and when you change it, you end up with a
different operating system.

It's pretty clear that you want the environment to work differently than
it does, and it's pretty clear that you unreasonably expect certain
interpretations for your corrupted environment, but the fact remains that
urxvt doesn't corrupt anything.

                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