2.3.0

[Gustaf Neumann]

Am 04.04.14 02:10, schrieb Ryan Schmidt:
>>
>> 1. I changed the way the environment variables are output, to be sorted and one per line:
>>
>> https://trac.macports.org/ticket/40703
>>
>> This is easier to read. However for reasons I don’t understand, I don’t always see them in log output; sometimes I just see:
>>
>> DEBUG: Environment:
>>
>> Has anybody else noticed this? Could someone take a look at this and see why that might be?
>> Yes, anddam was having this problem yesterday with some ports, but I
>> couldn't reproduce it.
>
> All I changed was one line in environment_array_to_string, making it so that the string it returns now contains newlines. The only place where environment_array_to_string gets called, it’s just sent over to ui_debug as:
>
> ui_debug "Environment: [environment_array_to_string ${varprefix}.env_array]”
>
> Can ui_debug not accept multiline strings? I am having trouble locating where ui_debug is defined.
>
Concerning the discussion with "swallowed" output: i could not reproduce
the exact problem but i see a potential problem: the var-args of ui_message
are never validated. Values might be swallowed in the current code, when
- "args" has two elements, and the first one is not "-nonewline", or when
- more than 2 arguments are specified (e.g. a list expanded via an
   erroneous "eval")

The following argument validator raises at least an error for unexpected
values:

proc ui_message {priority prefix phase args} {
     global macports::channels ::debuglog macports::current_phase

     switch [llength $args] {
        0 - 1 {}
        2 {
            if {[lindex $args 0] ne {-nonewline}} {
                set hint "error: when 5 arguments are given, 2nd last 
must be \"-newnewline\""
                error "$hint\nusage: ui_message priority prefix phase 
?-nonewline? string"
            }
        }
        default {
            set hint "error: too many arguments specified"
            error "$hint\nusage: ui_message priority prefix phase 
?-nonewline? string"
        }
     }

    ...
}

When looking around in the code of 2.2.99, I just saw one more thing that
should be changed. There are a couple of places, where the idiom

         if {$show eq yes} { ... }

is used. This is syntactically correct, but should not be used
as a boilerplate for other comparisons, since the behavior
might become confusing when slightly different values are
used for comparison. The problem is the "bareword" yes.
See e.g.:

% if {1 eq yes} {puts yes}
% if {1 eq y} {puts yes}
% if {1 eq x} {puts yes}
invalid bareword "x"
in expression "1 eq x";
should be "$x" or "{x}" or "x(...)" or ...

The first two lines print nothing (as probably expected), the third
line raises an error.

The rule should be: for expressions "eq" or "ne" always protect against
barewords, i.e. use always "", {} or [], then one can avoid surprises.

The attached patch contains as well the simpler/faster replacement for
"proc const". The patch is against macports_release_2_3 in svn.

-gn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: macports_release_2_3.patch
Type: text/x-patch
Size: 6204 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140413/bdecf923/attachment.bin>