Consider the following program:

{$mode objfpc}{$H+}
uses
   SysUtils;
var
   i: integer;
   s: string;
begin
   i := GetEnvironmentVariableCount;
   writeln('VariableCount: ',i);
   s := GetEnvironmentString(1);
   writeln('Variable 1: ', s);
   s := GetEnvironmentString(2);
   writeln('Variable 2: ', s);
   s := GetEnvironmentVariable('=D:');
   writeln('Variable 1: ', s);
end.

If I run this from a command prompt on my windows 2000 computer it gives the following output:
VariableCount: 43
Variable 1: =D:=D:\lazarus\bugs\7699
Variable 2: =ExitCode=00000000
Variable 1:

The first two envrionment string are special, in the sense that their name start with a =.

but if ask for the value of the environment variable '=D:', it returns the empty string.

I am wrestling a bit with how to interprete this. Should I consider these variable as special and hidden and ignore them?
Or should code parsing environmentstrings be able to handle variables with a '=' on the first position?

Vincent

IMHO, you should not be allowed to have a = in the name of an environment obviously you can in Windows, this is a problem which will need fixing somehow.
I'm pretty sure you can't do this in Linux (I get an illegal variable name error). So code relying on this will not be cross-platform.

Michael.

I found in the doc the inet unit, but i don't found it under my system nor on the web
on page http://www.freepascal.org/packages/inet.html the link ftp://ftp.freepascal.org/pub/fpc/source/packages.zip seem to be broken!

I need to resolv dns entry and i try the synapsys and the NS_Protokoll which not work on a opetron plateform -(64bits amd) If some one could give me some answer for this debug ouptut..

The NS_Protokoll won't compile because of a miss of integers.inc file. Declared in the nsquery.pas:{$define integers_as_include} {$INCLUDE integers.inc}

The other compile fine but doesn't work (it should be ) :)....

In windows it doesn't seem to be allowed either:
C:\lazarus>set =test=p
De syntaxis van de opdracht is onjuist.

So code relying on this will not be cross-platform.

My problem is code relying in the fact that GetEnvironmentString(1) doesn't return strings that start with '='. Will you fix that? Or must code using GetEnvironmentString be aware that on some platforms these strings can start with =.

Vincent

Try the netdb or resolve units; the inet unit is severely outdated and is no longer supplied with FPC.

Michael.

On the command-line.
Have you tried in the 'My Computer' properties, 'System' tab, under 'Advanced' ? There is a GUI dialog to set environment variables, probably it allows this.

I would have to look at the code. Please enter a bug report, so it won't be forgotten.

Michael.

I tried this. I got no error, but my new variable '=test' didn't show up in the environmnent variables, not in the strings return by GetEnnvironmentString.

http://www.freepascal.org/mantis/view.php?id=7967

Vincent

Maybe you can't, and you can only have multiple env strings with an empty name ;)

I added a note to the docs.

If you use GetEnvironmentStrings, I assume you do the parsing all by yourself, and so you have been warned :-)

Michael.

So I get at least one, if I do GetEnvironmentVariable(''); ?

Vincent

Here is a Code Snippet from an application I use to grab environment stuff for CGI Programming:

Var T: integer; SA: Ansistring; eq: integer;

And the rCGIIN is a record of rtCGI. iEnvVarCount and the arNVPair should
Make sense if you look at what I have here.

The iVal function is just a wrapper to convert text numbers to integer
Values - its just wrapped around the standard VAL call that's part of
FPC.
//======================================================================
=======
Type rtNameValuePair = Record
  saName: AnsiString;
  saValue: AnsiString;
End;
Const cn_MaxEnvVariables = 200;
      cn_MaxEnvWarnThreshold = 150;
//-------------- The CGI Environment Gets Pushed in here
Type rtCGI = Record
  iEnvVarCount: Integer; // How Many ENV Variables
  arNVPair: array [0..cn_MaxEnvVariables-1] Of rtNameValuePair;
  iRequestMethodIndex: Integer; // Set to WHICH in the Array of EnvPairs
that
                                // have the request method (GET or POST)
  // POST SPECIFIC - if not post - assumed GET or a "got nothing"
  //(I think technically a "got nothing" is a GET...).
  bPost: Boolean; // true if POST Recieved
  saPostData: AnsiString;
  iPostContentTypeIndex: Integer; // Set to WHICH in the Array of
EnvPairs that
                           // have the CONTENT_TYPE Env Values
  iPostContentLength: Integer;
End;
//--------------------------------------------------------
//======================================================================
=======
------------BEGIN
  For t:=0 To rCGIIN.iEnvVarCount-1 Do
  Begin
    sa:=envstr(t);
    eq:=pos('=',sa);
    rCGIIN.arNVPair[t].saName:=copy(sa,1,eq-1);
    rCGIIN.arNVPair[t].saValue:=copy(sa,eq+1,length(sa)-eq);
    If (rCGIIN.arNVPair[t].saName=csCGI_REQUEST_METHOD) Then
    Begin
      rCGIIN.iRequestMethodIndex:=t;
    End;
    If (rCGIIN.arNVPair[t].saName=csCGI_CONTENT_TYPE) Then
    Begin
      rCGIIN.iPostContentTypeIndex:=t;
    End;
    If (rCGIIN.arNVPair[t].saName=csCGI_CONTENT_LENGTH) Then
    Begin
      rCGIIN.iPostContentLength:=iVal(rCGIIN.arNVPair[t].saValue);
    End;
  End;
------------END

Best Regards,

Jason P Sage
http://www.jegas.com

Nice
i try the netbd but i found a "bug",i use the testdns.pp provide in the directory of netbd.

hostAddrtostr('www.adeli.fr') give the good 195.167.230.4 answer. but the

   H:=StrtoHostAddr('195.167.230.4');
   L:=ResolveAddress(H,NAns);

give me 0 result !

i notice that the result for this is provide by dig -x

4.230.167.195.in-addr.arpa. 92 IN CNAME 4.1-63.230.167.195.in-addr.arpa. 4.1-63.230.167.195.in-addr.arpa. 22892 IN PTR s4.adeli.fr.

For the resolve unit, it's the same, the unit doesn't like an answer of CNAME for the reverse.. only PTR

ok i missed some thing

RFC 1912 Common DNS Errors February 1996

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the ,
PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.

So your are right and i'have to phone to our isp....

ok after a long read inside the rfc actually it seem that http://tools.ietf.org/html/rfc2317
the rfc 2317 specify that the in-addr.arpa can be a CNAME in case of Classless IN-ADDR.ARPA delegation. less than a /24....

so the answer could be a CNAME not only a PTR.

I need to correct the Function ResolveAddressAt in the netbd.pp to be rfc2317 compliant.