Talk:Environment variables: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎PARI/GP and environment variables not being captured: On 'individual' task requirement interpretations.)
Line 9: Line 9:


::Take a look at most of the other examples and see if you do as they do. We do have to have some consistency of interpretation of the task goal to aid comparison; and yet tasks are written by different people, with different skills in writing descriptions. If everyone were to try and interpret the description differently then the resulting page would not aid language comparison. With so many examples here, and no demonstable 'extra' gained by the PARI/GP interpretation of the task goals, there is little reason to keep it, hence the comments. --[[User:Paddy3118|Paddy3118]] 08:29, 21 November 2011 (UTC)
::Take a look at most of the other examples and see if you do as they do. We do have to have some consistency of interpretation of the task goal to aid comparison; and yet tasks are written by different people, with different skills in writing descriptions. If everyone were to try and interpret the description differently then the resulting page would not aid language comparison. With so many examples here, and no demonstable 'extra' gained by the PARI/GP interpretation of the task goals, there is little reason to keep it, hence the comments. --[[User:Paddy3118|Paddy3118]] 08:29, 21 November 2011 (UTC)
::: a very brief look at the pari documentation gives the impression that there is no way to access environment variables directly. executing a system command seems to be the only way, however besides <code>system()</code> there is a function <code>extern()</code> which feeds the result back. i believe the following would satisfy the task:
<lang PARI/GP>print(extern("echo $HOME"))</lang>
::: though i am not sure if the syntax is correct.--[[User:EMBee|eMBee]] 12:07, 21 November 2011 (UTC)

Revision as of 12:07, 21 November 2011

PARI/GP and environment variables not being captured

Hi CRGreathouse, You seem to be ignoring various attempts to explain to you the needs of the task. You have removed flags to your example by first user 192.139.122.42, and then by me where we have tried to point out to you what the task, (and the consensus of the other language examples), is about.

At the moment your example is in error. If you would like to discuss the PARI/GP example and why it doesn't do what is needed then this talk page is the place, but would you leave the notice of its problem alone until it is clearly in accordance with the task.

Please, if others have comments, (either way), then do chip in. --Paddy3118 07:11, 21 November 2011 (UTC)

You're making a requirement that isn't part of the task. You have a history of making up these requirements and changing task descriptions until they fit your understanding of them. I do rather wish you'd stop. CRGreathouse 08:13, 21 November 2011 (UTC)
Take a look at most of the other examples and see if you do as they do. We do have to have some consistency of interpretation of the task goal to aid comparison; and yet tasks are written by different people, with different skills in writing descriptions. If everyone were to try and interpret the description differently then the resulting page would not aid language comparison. With so many examples here, and no demonstable 'extra' gained by the PARI/GP interpretation of the task goals, there is little reason to keep it, hence the comments. --Paddy3118 08:29, 21 November 2011 (UTC)
a very brief look at the pari documentation gives the impression that there is no way to access environment variables directly. executing a system command seems to be the only way, however besides system() there is a function extern() which feeds the result back. i believe the following would satisfy the task:

<lang PARI/GP>print(extern("echo $HOME"))</lang>

though i am not sure if the syntax is correct.--eMBee 12:07, 21 November 2011 (UTC)