When scripting something, and input is not from a terminal, there are some things that cannot be done. E.g. skip file foo.c -> Ignore file pending future shared library load? (y or [n]) [answered N; input not from terminal] If foo.c isn't found the default is "N" (No), and there's no way to "reply" Y.
That's possibly to be a too-big-a-hammer. We tend to be careful with choosing the default action (negative vs positive wording, query/nquery/yquery). I can imagine all sorts of wrong answers if we just switched the default of "query". IMO, it's better to handle this query-by-query. That is, add a "set skip pending on/off/auto/whatnot" for this case, mirroring "set breakpoint pending".
Depending on how it is implemented, yes, it could be a bit of a big hammer. I was expecting to use it like: (with-query-default "y" "skip file foo.c") or some such. [No apologies for having fun with Scheme. :-)] I used "skip" as an example of a potentially general problem. For "skip" itself, set "skip pending on/off/auto" or some such is another way to go (as previously mentioned on IRC).
(sorry, I was not on IRC then, and well, that doesn't get archived) > (with-query-default "y" "skip file foo.c") I still think it's a too big a hammer. You don't really know which query GDB will throw at the user. Sure, usually it'll be the one you want, but sometimes it won't. And it's those other times that'll make such generic hammer annoying. We could still use a generic wrapping function like: (wrap-option "skip pending" "on" "skip file foo.c") With wrap-option working with any GDB option. It just needs to store the current value, set it to the second argument, run the command, and then restore the initial value. Should be doable in Python already today.
There were threads in the past about this problem, from the MI perspective. One further issue is that the queries change over time. You can nearly do the "with" thing in Python. However, bug#12188 can get in the way, depending on the parameter you choose.
Yeah, defaulted_query is flawed from a scripting point of view. Consider this bug a discussion for how to fix it. It's easy enough to add defaulted_query calls to code without remembering that every one screws the user wanting to script that command unless extra steps are taken, but do we want (effectively) a user-settable option for every defaulted_query? E.g. if (pending_break_support == AUTO_BOOLEAN_AUTO && !nquery (_("Make %s pending on future shared library load? "), bptype_string (type_wanted)))