bugGNU Octave - Bugs: bug #49289, getenv('PROCESSOR_ARCHITECTURE')...


bug #49289: getenv('PROCESSOR_ARCHITECTURE') just returns generic results

Submitter:  None
Submitted:  Thu 06 Oct 2016 09:24:36 PM UTC
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Works For Me Assigned to:  None
Originator Name:  Johannes Pfeifer Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.2.0-rc2
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Fri 07 Oct 2016 11:22:56 PM UTC, comment #12: 

Closing with "works for me" status.

Mike Miller <mtmiller>
Project Administrator
Fri 07 Oct 2016 12:58:22 PM UTC, comment #11: 

I'm pretty sure that the reason Octave just prints the value when there are no input/output arguments is because that's what Matlab used to do.  It's easy enough to change, I suppose.

We have had bug reports about the actual values returned by computer in the past and decided not to change them.  I'd really rather not change them in Octave, but I guess if we are not 100% exactly like Matlab in every way, then someone somewhere will be pissed about it.

No, there is not a 64-bit version on alpha.gnu.org yet but you are right that it would be good to have for testing.

Resources are limited.  Can you support our work somehow?

John W. Eaton <jwe>
Project Administrator
Fri 07 Oct 2016 09:55:10 AM UTC, comment #10: 

What about the output of computer():


Octave returns this:

>> computer
>> computer('arch')
ans = gnu-linux-x86_64

while Matlab returns:

>> computer
ans =
>> computer('arch')
ans =

Which makes me notice that, with Octave, computer() prints the output instead of returning it as an output argument.

[I realize I am hijacking this thread with a related but distinct issue, let me know if I should open a new bug report instead].

Guillaume <gyom>
Fri 07 Oct 2016 06:32:51 AM UTC, comment #9: 

Yes, this is indeed fixed in the 64bit version of 4.0.3 available from http://www.tatsuromatsuoka.com/octave/Eng/Win/
Thus, we can close this issue, I guess.

Is there already a 64 bit binary for the Release candidate available for download? I could not find it on ftp://alpha.gnu.org/gnu/octave, but it might be good to have it for testing.

Johannes Pfeifer <jpfeifer>
Thu 06 Oct 2016 10:45:07 PM UTC, comment #8: 

I haven't checked, but I guess this would be fixed by using the 64-bit binary instead?  I intend to distribute both 32- and 64-bit binaries for Octave 4.2.

John W. Eaton <jwe>
Project Administrator
Thu 06 Oct 2016 10:30:19 PM UTC, comment #7: 

I see. Then this is actually Microsoft's desired behavior and not a bug, because the current Octave binary on Windows is a 32bit one.

Thu 06 Oct 2016 10:20:50 PM UTC, comment #6: 
Dmitri A. Sergatskov <dasergatskov>
Thu 06 Oct 2016 10:10:17 PM UTC, comment #5: 

Hmm, on my Windows 7 system running in a VM, the value in the DOS shell is AMD64 but the value in Octave (CLI or GUI) is x86.  I'm sure Octave is not setting this directly (PROCESSOR_ARCHITECTURE is nowhere to be found in the Octave sources), so some library that we use must be doing it?  Hmm, which one?

John W. Eaton <jwe>
Project Administrator
Thu 06 Oct 2016 09:57:00 PM UTC, comment #4: 

No, Matlab correctly returns the environment variable's value "AMD64". Octave only reports "x86".

Johannes Pfeifer <jpfeifer>
Thu 06 Oct 2016 09:51:42 PM UTC, comment #3: 

I think the value of an environment variable is outside the scope of Octave.  If it is set to something, then Octave's getenv function should return it.  That looks to be working.

I'd be curious to know whether it is different outside of Matlab.  If so, then maybe Matlab sets it at startup?  But I see no reason to do that.

John W. Eaton <jwe>
Project Administrator
Thu 06 Oct 2016 09:49:29 PM UTC, comment #2: 

My environment variable actually says "AMD64".

Johannes Pfeifer <jpfeifer>
Thu 06 Oct 2016 09:42:05 PM UTC, comment #1: 

What happens if you check the value of the environment variables PROCESSOR_ARCHITECTURE from within the Control Panel?  At least on my Windows XP virtual machine, the PROCESSOR_ARCHITECTURE variable is set to 'x86' already and so Octave is correct in returning that walue.

If I go and change the environment variable to something like "foobar", then Octave accurately reports that silly value instead when I use getenv.

Rik <rik5>
Project Administrator
Thu 06 Oct 2016 09:24:36 PM UTC, original submission:  

On Windows 10 64 bit with a Core i7-4790K, calling in Matlab 2016b



arch = AMD64

but on Octave, it returns

arch = x86



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jpfeifer (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-07 mtmiller Open/ClosedOpen Closed
    2016-10-06 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.9