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
   

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>
Group Member
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>
Group administrator
Fri 07 Oct 2016 09:55:10 AM UTC, comment #10: 

What about the output of computer():

http://www.mathworks.com/help/matlab/ref/computer.html

Octave returns this:


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


while Matlab returns:


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


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>
Group 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.

Anonymous
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>
Group 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>
Group 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>
Group 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 = getenv('PROCESSOR_ARCHITECTURE')`


returns


arch = AMD64


but on Octave, it returns


arch = x86


Anonymous

 

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

Attach Files:
   
   
Comment:
   

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 group 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.13-4448.
    Corresponding source code