Hi guys! I'm putting together a patch to fix the regression experienced in trunk's port.tcl after the recent API tweaks to macports1.0. As it turns out, many actions (installed, outdated, search and others) are currently broken because the "ports_no_args" flag in the "global_options" array is not being reached; but all in all, I feel this is more of a symptom of a general mix-up in port.tcl's two main global arrays that was revealed by the API changes rather than plain breakage, and I believe the appropriate fix is to clean the mess-up altogether. Basically, port.tcl has two main global arrays: 1) ui_options, for storing user interface options like verbose/debug/ quiet (but also some other things I believe do not belong in it), passed to macports1.0; 2) global_options, for storing all sorts mixed-up things (read below), passed to macports1.0 too; 3) (there's also global_variations, but I think that's orthogonal to the issue at hand). The breakage occurs because at the time the "global_options" array is passed to macports1.0, "ports_no_args" hasn't been set yet; subsequently, "[macports:global_option_isset ports_no_args]" is used to determine the behavior of the outdated/installed/search/etc actions and as the flag is not yet set, things naturally break. As Kevin noted recently, port.tcl stores options that are "private" to port.tcl and options that are passed to the macports1.0 layer *both* inside the global_options array, and I believe the proper fix is to split these two types into their own properly named arrays. In my ongoing patch I created a "private_options" global array in which I store flags like "ports_no_args" and managed to recover some of the broken functionality by polling the former for the latter flag (through [info exists private_options(ports_no_args)]), rather than using the now in macports1.0 "global_option_isset" proc on the "global_options" array (which does not contain the needed flag). So to me this is an obvious example of what should be an option *private* to port.tcl, candidate for storing inside "private_options". In order to complete the patch I would need to know exactly what options are private and which ones should be passed to macports1.0 through "global_options". Polling the appropriate array throughout port.tcl will not only recover all the broken functionality but also clear up any confusion as to what stays and what is handed over. Global options that should be passed to macports1.0 are, I think: *) 'ports_force', port(1)'s -f; *) 'ports_ignore_older', port(1)'s -o; *) 'ports_nodeps', port(1)'s -n; *) 'port_uninstall_old', port(1)'s -u; *) 'ports_do_dependents', port(1)'s -R; *) 'ports_source_only', port(1)'s -s; *) 'ports_binary_only', port(1)'s -b; *) 'ports_autoclean', port(1)'s -c & -k; *) 'ports_trace', port(1)'s -t; Am I right? Did I miss any? Or am I, instead, including some options that don't need to be passed to macports1.0? Conversely, options that are private to port.tcl are: *) ports_no_args, currently being stored in global_options but opting for private_options, I believe; *) I'm sure I'm missing others throughout port.tcl that are really of private scope and need not be stored in global_options; care to illuminate? Thirdly, options I'm not sure about where they should be: *) long arguments processed in the "parse_options" proc, which are being stored in "global_options". Do they need to stay there or can they be moved to the private array? Or maybe split between the two? *) 'ports_commandfiles' in the "parse_options" proc too, why is it being saved in ui_options? What does it have to do with the user interface? Seems to me like this is another perfect candidate for the private_options array (and in lack of it, I would have imagined this option is more appropriate for saving inside the global_options array, not in ui_options); *) 'ports_processall', same comments as above; *) 'ports_exit', ditto; So as you can see, even though a quick fix for this regression could be a very simple patch (which I could commit like *now*), what I think is the proper one gets a bit more involved. After knowing all the information I request above, the final part to call the fix complete is knowing in what situations I would need to poll the "global_options" array and/or "private_options". As the code stands now, many constructs simply [array get global_options] and thus obtain all the baggage that's stored there (I'm sure sometimes unnecessarily so), but that would naturally need to change if we do split the options (including some proc prototypes). So... can more port.tcl illuminated souls shine some light on me? ;-) Thanks for even reading all this mail this far! Regards,... -jmpp PS; The patch I'm working on is attached in its current, still incipient form. If you're careful you'll also notice the removal of some global calls in some procs, which are due to the API changes to macpors1.0 (the corresponding vars need no longer be brought into scope).