back slash compatibility prob
MURPHY, Jeremy W
not sure if my previous post went through, but I've refined my question
anyway, so forgive me for repeating myself.
I haven't programmed in djgpp for a while, so I'm a bit out of touch with
its idiosyncrasies.
I notice that if TMPDIR="c:/djgpp/tmp", it comes up as "c:\djgpp\tmp" in
a program if you use getenv() or tmpnam(), which I assume is the correct
behaviour, it makes sense.
Problem is that I'm compiling and running some C which had UNIX in mind,
and so is using the result of getenv() as part of a call to system(), and
the backslashes are getting eaten up, or something.
So calling system("uname -s > c:\djgpp\tmp/dj200000 2>&1") is resulting
in:
c:\djgpp\tmp/dj400000: c:djgpptmp/dj200000: No such file or directory
(ENOENT)
If this is all correct behaviour for djgpp, is my only course of action
to modify the C program?
I'm sort of hoping that there's something wrong with my installation,
because I've seen these errors before and never investigated them, but
everything else runs fine (except Pakke, but that's another story).
Thanks, cheers.
Jeremy
A. Sinan Unur
news:atkeh5$1fh$1...@c3p0.cc.swin.edu.au:
> Howdy,
>
> not sure if my previous post went through, but I've refined my
> question anyway, so forgive me for repeating myself.
>
> I haven't programmed in djgpp for a while, so I'm a bit out of touch
> with its idiosyncrasies.
>
> I notice that if TMPDIR="c:/djgpp/tmp", it comes up as "c:\djgpp\tmp"
> in a program if you use getenv() or tmpnam(), which I assume is the
> correct behaviour, it makes sense.
>
> Problem is that I'm compiling and running some C which had UNIX in
> mind, and so is using the result of getenv() as part of a call to
> system(), and the backslashes are getting eaten up, or something.
> So calling system("uname -s > c:\djgpp\tmp/dj200000 2>&1") is
> resulting in:
> c:\djgpp\tmp/dj400000: c:djgpptmp/dj200000: No such file or directory
> (ENOENT)
you may want to look at the documentation for _fixpath. i don't know if
the value of `_crt0_startup_flags' has any effect on how environment
strings are read, although I suspect not.
C:\Dload\misc>cat eee.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
int main(void)
{
char fixed_path[FILENAME_MAX];
puts(getenv("TEMP"));
_fixpath(getenv("TEMP"), fixed_path);
puts(fixed_path);
return 0;
}
C:\Dload\misc>gcc -Wall eee.c -o eee.exe
C:\Dload\misc>eee
C:\WINDOWS\TEMP
c:/WINDOWS/TEMP
--
A. Sinan Unur
as...@c-o-r-n-e-l-l.edu
Remove dashes for address
Spam bait: mailto:u...@ftc.gov
A. Sinan Unur
news:Xns92E654D4AD5C...@132.236.56.8:
> C:\Dload\misc>cat eee.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/stat.h>
>
> int main(void)
> {
> char fixed_path[FILENAME_MAX];
> puts(getenv("TEMP"));
> _fixpath(getenv("TEMP"), fixed_path);
> puts(fixed_path);
>
> return 0;
> }
>
>
> C:\Dload\misc>gcc -Wall eee.c -o eee.exe
>
> C:\Dload\misc>eee
> C:\WINDOWS\TEMP
> c:/WINDOWS/TEMP
I posted the above code in response to another problem. After posting, I
noticed that the string getenv returns for TEMP does not match the value
of TEMP on my system. Typing set shows:
TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
whereas getenv("TEMP") returns c:\windows\temp.
I am using XP Pro. I do have the v2.03 refresh distribution installed.
What might be the reason?
Sinan.
Richard Dawe
"MURPHY, Jeremy W" wrote:
[snip]
> I'm sort of hoping that there's something wrong with my installation,
> because I've seen these errors before and never investigated them, but
> everything else runs fine (except Pakke, but that's another story).
Please tell me what's up with pakke. I enjoy a good story and I'd be happy to
help you. ;)
Regards,
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
Eli Zaretskii
> Newsgroups: comp.os.msdos.djgpp
> Date: 16 Dec 2002 14:05:57 GMT
>
> I posted the above code in response to another problem. After posting, I
> noticed that the string getenv returns for TEMP does not match the value
> of TEMP on my system. Typing set shows:
>
> TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
> TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
>
> whereas getenv("TEMP") returns c:\windows\temp.
>
> I am using XP Pro. I do have the v2.03 refresh distribution installed.
> What might be the reason?
Perhaps you've edited DJGPP.ENV to set "TEMP"?
Eli Zaretskii
> Newsgroups: comp.os.msdos.djgpp
> Date: 16 Dec 2002 14:05:57 GMT
>
> noticed that the string getenv returns for TEMP does not match the value
> of TEMP on my system. Typing set shows:
>
> TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
> TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
>
> whereas getenv("TEMP") returns c:\windows\temp.
>
> I am using XP Pro. I do have the v2.03 refresh distribution installed.
> What might be the reason?
Perhaps you've edited DJGPP.ENV to set "TEMP"?
Eli Zaretskii
> Newsgroups: comp.os.msdos.djgpp
> Date: 16 Dec 2002 11:47:49 GMT
>
> I notice that if TMPDIR="c:/djgpp/tmp", it comes up as "c:\djgpp\tmp" in
> a program if you use getenv() or tmpnam(), which I assume is the correct
> behaviour, it makes sense.
You didn't tell the whole story (e.g., how _exactly_ did you set
TMPDIR, with what command?), so I'll have to guess.
My guess is that you've set it inside Bash, but did not tell Bash to
export its value to programs Bash invokes. So Bash passes the
programs the original value of TMPDIR as it saw it outside Bash.
> Problem is that I'm compiling and running some C which had UNIX in mind,
> and so is using the result of getenv() as part of a call to system(), and
> the backslashes are getting eaten up, or something.
> So calling system("uname -s > c:\djgpp\tmp/dj200000 2>&1") is resulting
> in:
> c:\djgpp\tmp/dj400000: c:djgpptmp/dj200000: No such file or directory
> (ENOENT)
If the above call to `system' is a literal quotation from your
program's source, then the problem is that you must double every
backslash in a C string, like so:
system("uname -s > c:\\djgpp\\tmp/dj200000 2>&1");
A. Sinan Unur
news:2593-Mon16Dec200...@is.elta.co.il:
That's the first thing I looked at too, but no that's not the case. I
feel pretty clueless.
Wilfried Hennings
> I posted the above code in response to another problem. After posting, I
> noticed that the string getenv returns for TEMP does not match the value
> of TEMP on my system. Typing set shows:
>
> TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
> TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
>
> whereas getenv("TEMP") returns c:\windows\temp.
>
> I am using XP Pro. I do have the v2.03 refresh distribution installed.
> What might be the reason?
Right click on "My computer" on your desktop, then "properties",
"extended" (or what else is it in English? I have the German WinXP),
"environment variables".
There I (logged in with admin rights) see two sets of variables:
User variables and system variables.
"TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp" comes from the user variables.
"TEMP=c:\windows\temp" comes from the system variables.
If I open a command prompt, I get the "user" temp.
But if the djgpp program opens a new process, what variables does this
get??? I don't know! And I myself would like to be a little bit more
enlighted in this respect...
Regards,
--
email me: change "nospam" to "w.hennings"
Dipl.-Ing.(=M.Sc.Eng.) Wilfried Hennings c./o.
Forschungszentrum (Research Center) Juelich GmbH, MUT
<http://www.fz-juelich.de/mut/index_e.html>
All opinions mentioned are strictly my own, not my employer's.
A. Sinan Unur
news:8gvtvuo1qe2qi661n...@4ax.com:
> Right click on "My computer" on your desktop, then "properties",
> "extended" (or what else is it in English? I have the German WinXP),
it is "Advanced" in the English version.
> "environment variables".
> There I (logged in with admin rights) see two sets of variables:
> User variables and system variables.
> "TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp" comes from the user variables.
> "TEMP=c:\windows\temp" comes from the system variables.
Yes, I know that.
> If I open a command prompt, I get the "user" temp.
> But if the djgpp program opens a new process, what variables does this
> get??? I don't know! And I myself would like to be a little bit more
> enlighted in this respect...
I got curious and checked the sources. The code in crt1.c does not give
any immediate clues. I suspect most of the work is being done in
stub.asm but I am not well versed in the technicalities of PSP's etc and
x86 assembly language.
I thought maybe variables from my user environment settings were not seen
by the djgpp stub code, but they are. I verified this by compiling and
running a program that displayed the value of a variable that is only
defined in the user environment.
My guess at this point is that this maybe a bug in ntvdm or whatever
deals with setting up the PSP etc for dos programs in Win XP.
I made the following changes to my djgpp.env as a work-around:
+TMPDIR=C:\DOCUME~1\%USERNAME%\LOCALS~1\Temp
TEMP=%TMPDIR%
TMP=%TMPDIR%
Charles Sandmann
> TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
> whereas getenv("TEMP") returns c:\windows\temp.
> I am using XP Pro. I do have the v2.03 refresh distribution installed.
> What might be the reason?
Just a guess, but look at autoexec.nt and see if any environment variables
are set there (it's in %systemroot%\win32\autoexec.nt). I've seen
Windows automatically put all sorts of stuff there that only is used
in DOS sessions.
A. Sinan Unur
news:3e009a55...@clio.rice.edu:
>> TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
>> TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
>
>> whereas getenv("TEMP") returns c:\windows\temp.
>
>> I am using XP Pro. I do have the v2.03 refresh distribution
>> installed. What might be the reason?
>
> Just a guess, but look at autoexec.nt and see if any environment
> variables are set there (it's in %systemroot%\win32\autoexec.nt).
i found it in %systemroot%\system32 on my computer.
> I've seen Windows automatically put all sorts of stuff there that only
> is used in DOS sessions.
here are the contents of that file:
@echo off
REM AUTOEXEC.BAT is not used to initialize the MS-DOS environment.
REM AUTOEXEC.NT is used to initialize the MS-DOS environment unless a
REM different startup file is specified in an application's PIF.
REM Install CD ROM extensions
lh %SystemRoot%\system32\mscdexnt.exe
REM Install network redirector (load before dosx.exe)
lh %SystemRoot%\system32\redir
REM Install DPMI support
lh %SystemRoot%\system32\dosx
REM The following line enables Sound Blaster 2.0 support on NTVDM.
<snip>explanation of blaster settings</snip>
SET BLASTER=A220 I5 D1 P330 T3
REM %SystemRoot%\system32\vipx.exe
REM %SystemRoot%\system32\vlmsup.exe
so that seems to be a no go. and config.nt does not contain anything
relevant either.
any more places i should look?
Eli Zaretskii
On 18 Dec 2002, A. Sinan Unur wrote:
> so that seems to be a no go. and config.nt does not contain anything
> relevant either.
>
> any more places i should look?
I'd suggest to step thru the startup code that reads the environment and
the DJGPP.ENV file, and see where did the value of TEMP come from,
exactly.
MURPHY, Jeremy W
: Hello.
: "MURPHY, Jeremy W" wrote:
: [snip]
: > I'm sort of hoping that there's something wrong with my installation,
: > because I've seen these errors before and never investigated them, but
: > everything else runs fine (except Pakke, but that's another story).
: Please tell me what's up with pakke. I enjoy a good story and I'd be happy to
: help you. ;)
heheheh, it generally works fine, but when I installed g77321b.zip the
other day, the result included removing quite a lot of the gcc and gpp
files. Sorry, I don't have a detailed diagnosis.
Also, when I run it from a directory other than c:/djgpp I get this:
Warning: Unable to check that 'share/pakke/db' is a directory (errno = 22): No s
uch file or directory (ENOENT)
Warning: Unable to check that 'manifest' is a directory (errno = 22): No
such file or directory (ENOENT)
Warning: Unable to check that 'share/pakke/db-avail' is a directory
(errno = 22): No such file or directory (ENOENT)
[exited with 1]
which is pretty evident as to what is going on, but I don't know why.
Eh, I think I made that flippant comment more from memory of teething
problems with it, but if I think of anything more specific I'll let you
know. :)
Jeremy
A. Sinan Unur
Sorry, I didn't actually get around to doing that fully (I did do some
stepping around, but my guess is I need to have a libc and stub that is
debug enabled -- is that correct?). Here is something else I did, and the
results:
C:\Dload\misc>cat myenv.c
#include <stdio.h>
#include <string.h>
#include <crt0.h>
#include <go32.h>
#include <stubinfo.h>
#include <sys/farptr.h>
#include <sys/movedata.h>
/* disable reading djgpp.env */
void __crt0_load_environment_file(char *_app_name) { };
static void dump(int s)
{
unsigned i = 0;
int c;
do {
while((c = _farpeekb(s, i++)) != 0)
{
putchar(c);
}
putchar('\n');
} while (_farpeekb(s, i) != 0);
}
int main(void)
{
short env;
movedata(_stubinfo->psp_selector, 0x2c, _my_ds(), (int)&env, 2);
dump(env);
return 0;
}
C:\Dload\misc>myenv | grep "TEMP"
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
The results are the same using cmd.exe and command.com. As usual:
C:\Dload\misc>set |grep -i "TEMP"
TEMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
TMP=C:\DOCUME~1\asu1\LOCALS~1\Temp
from both command.com and cmd.exe.
I did search every nook and cranny I could think of (using the group
policy editor and regedit, and also searching for all files that contain
the string "temp") but couldn't find any place where an override might be
set.
I also downloaded Turbo C 2.01, and compiled the following:
#include <stdio.h>
int main(int argc, char **argv, char **envp)
{
char **envstr = envp;
while(*envstr)
{
puts(*envstr);
++envstr;
}
return 0;
}
and ran it. I again got
TEMP=C:\WINDOWS\TEMP
TMP=C:\WINDOWS\TEMP
even though set displayed the correct user settings. Compiling the
program above with cygwin procuded the correct output:
C:\Dload\misc>e4 |grep -i "TEMP"
TEMP=/cygdrive/c/DOCUME~1/asu1/LOCALS~1/Temp
TMP=/cygdrive/c/DOCUME~1/asu1/LOCALS~1/Temp
This suggests to me that the Windows is overriding the user TEMP
variable with the system one for DOS programs.
Sinan.
PS: I also tried the INT 0x21 (ah = 0x62) to get the PSP segment, and
then reach the environment block from there, and again, TEMP points to
C:\WINDOWS\TEMP.
A. Sinan Unur
news:Xns92EAC413C91D...@132.236.56.8:
> Here is something else I did, and the results:
i am wondering if this is only happening onmy machine. could someone with
access to nt/2k/xp please try:
#include <stdio.h>
int main(int argc, char **argv, char **envp)
{
char **envstr = envp;
while(*envstr)
{
puts(*envstr);
++envstr;
}
return 0;
}
on their machine and see what it prints out for TEMP when there is both a
system and a user TEMP defined via the environment variable settings in
My Computer properties (and none in djgpp.env)?
Charles Sandmann
> access to nt/2k/xp please try:
> on their machine and see what it prints out for TEMP when there is both a
> system and a user TEMP defined via the environment variable settings in
> My Computer properties (and none in djgpp.env)?
On Windows 2000 SP1
TEMP=C:\WINNT\TEMP
TMP=C:\WINNT\TEMP
(When TEMP is pointed to the system default of c:\docu...\username...)
If I set TEMP at the command line, that TEMP then goes through.
So this appears is default behavior on Win2K/XP family (I think I'm seeing
the same thing as you described).
A. Sinan Unur
> On Windows 2000 SP1
>
> TEMP=C:\WINNT\TEMP
> TMP=C:\WINNT\TEMP
>
> (When TEMP is pointed to the system default of c:\docu...\username...)
>
> If I set TEMP at the command line, that TEMP then goes through.
>
> So this appears is default behavior on Win2K/XP family (I think I'm
> seeing the same thing as you described).
thank you for checking this out.
i am inclined to think of this as a bug in windows because other system
environment variables overridden by user variables seem to come through
OK. also, some users may not have permission to write to
%SYSTEMROOT%\temp, and a DOS program that needed to write temporary files
would fail for those users.
for now, i am going to work around this by setting
+TMPDIR=C:\DOCUME~1\%USERNAME%\LOCALS~1\Temp
TEMP=%TMPDIR%
TMP=%TMPDIR%
in djgpp.env.
Eli Zaretskii
On 22 Dec 2002, A. Sinan Unur wrote:
> i am inclined to think of this as a bug in windows because other system
> environment variables overridden by user variables seem to come through
> OK.
I think it's a kind of (mis-)feature: The NT family of Windows replaces
some of the environment variables that are deemed ``inappropriate'' for
DOS programs. For example, "Path" is replaced with "PATH", etc.
A. Sinan Unur
yes, but the value is preserved.
anyway, i'll file this under "oddities to keep in mind". thanks for all
the replies.
Richard Dawe
Pardon the slow reply. I have been busy recently.
"MURPHY, Jeremy W" wrote:
>
> Richard Dawe (ri...@phekda.freeserve.co.uk) wrote:
> : Hello.
>
> : "MURPHY, Jeremy W" wrote:
> : [snip]
> : > I'm sort of hoping that there's something wrong with my installation,
> : > because I've seen these errors before and never investigated them, but
> : > everything else runs fine (except Pakke, but that's another story).
>
> : Please tell me what's up with pakke. I enjoy a good story and I'd be happy
> : to help you. ;)
>
> heheheh, it generally works fine, but when I installed g77321b.zip the
> other day, the result included removing quite a lot of the gcc and gpp
> files. Sorry, I don't have a detailed diagnosis.
It seems there are bugs in the DSMs for g77. DSMs are descriptions of packages
- pakke uses them to install/upgrade/uninstall packages. The problem is that
the g77 DSMs have the wrong manifest file names. The manifests list which
files are in a package. So I'm guessing that pakke does the wrong thing,
because it's looking at the wrong manifests.
I will tell the maintainer of the gcc packages about this.
> Also, when I run it from a directory other than c:/djgpp I get this:
>
> Warning: Unable to check that 'share/pakke/db' is a directory (errno = 22): No s
> uch file or directory (ENOENT)
> Warning: Unable to check that 'manifest' is a directory (errno = 22): No
> such file or directory (ENOENT)
> Warning: Unable to check that 'share/pakke/db-avail' is a directory
> (errno = 22): No such file or directory (ENOENT)
> [exited with 1]
>
> which is pretty evident as to what is going on, but I don't know why.
Do you have the DJGPP environment variable set up? What happens if you type:
echo %DJGPP%
in a DOS prompt? (Use "echo $DJGPP", if you're using bash.) I'm guessing that
pakke can't find DJGPP.ENV, so it doesn't know where the DJGPP directory is.
When you're in the DJGPP directory, it's OK, because pakke will default to the
current directory.
> Eh, I think I made that flippant comment more from memory of teething
> problems with it, but if I think of anything more specific I'll let you
> know. :)
Thanks for the bug report! Hope that helps.