Behaviour of vmware* utilities is hidden from us.
It seems to me that they didn't expect vmware-vmx direct usage so
reporting everything to stderr in case of os x.
This obvious option is reported to stderr too and has some bug :
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vmx -?
/Applications/VMware Fusion.app/Contents/Library/vmware-vmx: illegal option -- ?
To run the user interface, use vmware and not vmware-vmx.
Usage: vmware-vmx [<flags>] [configfile]
where <flags> are:
-P start paused
-q exit at power off
-s name=value set variable NAME to VALUE
-x power on when program starts
-X as -x, also go to full screen mode
-v print program version
-# Product-specific settings
-e name extract a resource specified by name
-? Usage
-@ VMDB connection to UI
vmware-vmx: this executable should not be invoked directly.
Cannot start vmware-vmx.
-3 Failed to parse command line options.
"vmware-vmx" -h probably was chosen as only one that reports version
string (btw it is strange that version is not saved to driver, it just
left in local var).
So I think connecting stderr is not bad at all, as it shouldn't change
behaviour and will address this strange VMware bug.
On Sat, Jan 4, 2014 at 8:17 AM, Denis Kondratenko
<denis.kondratenko@xxxxxxxxx> wrote:
>
> NP, I could test something for you. Send me a patch or whole brew receipt.
>
> On Jan 4, 2014 7:34 AM, "Doug Goldstein" <cardoe@xxxxxxxxxx> wrote:
>>
>> On Fri, Jan 3, 2014 at 12:14 PM, Eric Blake <eblake@xxxxxxxxxx> wrote:
>> > On 01/03/2014 10:57 AM, Denis Kondratenko wrote:
>> >> Incorrect usage of virAsprintf and vmware-vmx reports to stderr.
>> >>
>> >> --- https://bugzilla.redhat.com/show_bug.cgi?id=1036248
>> >
>> > Oh my - the triple --- leadin confused 'git am':
>> >
>> > Applying: vmware: os x support is broken
>> > fatal: patch fragment without header at line 42: @@ -271,17 +271,17 @@
>> > vmwareExtractVersion(struct vmware_driver
>> > *driver)</div><div> </div><div> switch (driver->type)
>> > {</div><div> case VMWARE_DRIVER_PLAYER:</div><div>-
>> > if (virAsprintf(&bin, "%s/%s", vmwarePath,
>> > "vmplayer"))</div>
>> > Repository lacks necessary blobs to fall back on 3-way merge.
>> > Cannot fall back to three-way merge.
>> > Patch failed at 0001 vmware: os x support is broken
>> >
>> > so I had to apply it by hand.
>> >
>> >
>> >> case VMWARE_DRIVER_PLAYER:
>> >> - if (virAsprintf(&bin, "%s/%s", vmwarePath, "vmplayer"))
>> >> + if (virAsprintf(&bin, "%s/%s", vmwarePath, "vmplayer") < 0)
>> >
>> > Definitely correct!
>> >
>> >
>> >> cmd = virCommandNewArgList(bin, "-v", NULL);
>> >> virCommandSetOutputBuffer(cmd, &outbuf);
>> >> +
>> >> + // OS X 10.9.1 and some earlier ver: vmware-vmx reports ver to stderr
>> >
>> > We prefer to avoid C99 comments, and the code is self-explanatory enough
>> > that it was easier to just drop the comment (and put it in the commit
>> > message instead).
>>
>> Sadly the comment actually doesn't make any sense. vmware-vmx is a
>> program shipped by VMware and doesn't select stdout or stderr based on
>> OS X version. It selects it based on whether the arguments supplied
>> are valid or not for the command. If they aren't valid then its stderr
>> (like most UNIX utilities) and if they're valid it goes via stdout. I
>> believe we had to use a bad command (and thus stderr) on OS X always
>> to get the version info as nothing that supplied the version returned
>> a successful.
>>
>> Denis,
>>
>> I don't own a copy of VMware Fusion (or any VMware product) so I can't
>> personally test. I have a number of branches which have some potential
>> fixes (I believe 1 series has been posted RFC without a response) but
>> don't at the moment have anyone to test them. So if you're interested
>> in testing them I can provide you with an alternate brew install
>> command and we can maybe land some other fixes.
>>
>> --
>> Doug Goldstein
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list