Environment variable issue

Adrian Sendroiu molecula2788 at gmail.com
Tue Aug 27 09:23:20 CEST 2013


On 20 August 2013 09:17, Marc Lehmann <schmorp at schmorp.de> wrote:
> 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
>       -=====/_/_//_/\_,_/ /_/\_\

Anyway, the fix is:

 =cut

 sub env {
-   +{ map /^([^=]+)(?:=(.*))?$/s && ($1 => $2), $_[0]->envv }
+   +{ map /^([^=]+)(?:=(.*))?$/s ? ($1 => $2) : (), $_[0]->envv }
 }

 =item $modifiermask = $term->ModLevel3Mask




More information about the rxvt-unicode mailing list