Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
issues with otherwise opaque config file locations and
startup handling numerous times, some help from qemu seemed
justified.
The prior version of this patch overloaded
Blue Swirl wrote:
On Thu, Sep 9, 2010 at 3:48 AM, john cooper john.coo...@redhat.com wrote:
I think '?' is not very good name.
I agree, a shell meta char wasn't my first choice. However
it follows the precedent of '?' used in similar query operations
and was chosen only for CLI consistency.
On Thu, Sep 9, 2010 at 3:48 AM, john cooper john.coo...@redhat.com wrote:
Blue Swirl wrote:
On Tue, Sep 7, 2010 at 12:31 PM, john cooper john.coo...@redhat.com wrote:
Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
Blue Swirl wrote:
On Tue, Sep 7, 2010 at 12:31 PM, john cooper john.coo...@redhat.com wrote:
Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
issues with otherwise opaque config file locations and
startup handling
Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
issues with otherwise opaque config file locations and
startup handling numerous times, some help from qemu seemed
justified.
In the case of a ? pseudo filename arg to
On Tue, Sep 7, 2010 at 12:31 PM, john cooper john.coo...@redhat.com wrote:
Failure by qemu to open a default config file isn't cause to
error exit -- it just quietly continues on. After puzzling
issues with otherwise opaque config file locations and
startup handling numerous times, some help
