RE: Enviroment always uppercased; Help me, please
Was an idea for a big bug solution. "No thanx" is the worst solution ever... And to fix it in cygwin1.dll itself... At the moment "cygwin no thanx if I see this errors", because >(..) We're only using cygwin to prototype some stuff, not to make any >viable product as it just isn't stable/reliable/secure enough unfortunately (...) and slow and not bug free and there is no real support available no thanx /usr/local/cygwin-1.3.10-1/winsup/cygwin $make g++ -c -gstabs+ -O2 -MMD -fbuiltin ... cygheap.cc In file included from cygheap.cc:17: fhandler.h: In method `select_stuff::select_stuff()': fhandler.h:1086: implicit declaration of function `int memset(...)' In file included from cygheap.cc:18: path.h: In method `bool path_conv::exists() const': path.h:89: `INVALID_FILE_ATTRIBUTES' undeclared (first use this function) path.h:89: (Each undeclared identifier is reported only once path.h:89: for each function it appears in.) path.h:89: warning: control reaches end of non-void function `path_conv::exists( ) const' make: *** [cygheap.o] Error 1 > -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 01, 2002 2:39 PM > To: [EMAIL PROTECTED] > Subject: Re: Enviroment always uppercased; Help me, please > > > On Fri, Mar 01, 2002 at 02:06:06PM +0100, Markus K. E. Kommant wrote: > >Idea: > > > >It would be better to support an evironment variable > CYGWIN_ENV_UPPERCASE=0, > >1, 2 or a list "var1 var2 var3". > >The list could be, to work correctly in most cases (I used > in my pdksh port) > >"SHELL", "EXECSHELL", "PATH", "HOME", "INCLUDE", "LIB", "HOMEPATH", > >"PATHEXT", "TMP", "TMPDIR", "TEMP", "WINDIR", "SYSTEMDRIVE", > "COMSPEC", > >"HOMEDRIVE", "HOMESHARE", "COMPUTERNAME", "SYSTEMROOT", > "LD_LIBRARY_PATH", > >NULL, > > > >CYGWIN_ENV_UPPERCASE=1 or not set = the current situation > >CYGWIN_ENV_UPPERCASE=0, do not change anything > >CYGWIN_ENV_UPPERCASE=2, use default uppercase list (see above) > >CYGWIN_ENV_UPPERCASE="var1 var2 var3 var4" uppercase only > this variables. > > No thanks. > > cgf > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Enviroment always uppercased; Help me, please
Idea:
It would be better to support an evironment variable CYGWIN_ENV_UPPERCASE=0,
1, 2 or a list "var1 var2 var3".
The list could be, to work correctly in most cases (I used in my pdksh port)
"SHELL", "EXECSHELL", "PATH", "HOME", "INCLUDE", "LIB", "HOMEPATH",
"PATHEXT", "TMP", "TMPDIR", "TEMP", "WINDIR", "SYSTEMDRIVE", "COMSPEC",
"HOMEDRIVE", "HOMESHARE", "COMPUTERNAME", "SYSTEMROOT", "LD_LIBRARY_PATH",
NULL,
CYGWIN_ENV_UPPERCASE=1 or not set = the current situation
CYGWIN_ENV_UPPERCASE=0, do not change anything
CYGWIN_ENV_UPPERCASE=2, use default uppercase list (see above)
CYGWIN_ENV_UPPERCASE="var1 var2 var3 var4" uppercase only this variables.
The problem is the following function inside environ.cc.
/* Turn environment variable part of a=b string into uppercase. */
static __inline__ void ucenv (char *p, char *eq)
{
/* Amazingly, NT has a case sensitive environment name list,
(...)
The function simplifies to uppercase ALL environment variables.
And the next point is, that the environment is sorted (the bash will sort
the environment).
That means, that a lowercase variable (early in environment) will overwrite
an uppercase variable. Is it wanted? The environment has to be "cleaned up"
vice-versa?!?
But the (biggest) problem is, that the amazing case-sensitiv NT environment
will be changed, when
if (!myself->ppid_handle) ucenv (newp, eq);
And this does'nt make any sense to me. Every "tiny" none cygwin program is a
danger for the current environment.
The following bash command sequence will destroy the bash environment.
This is an example! I know how to call the bash, and that this example could
be solved by "bash -c bash" (nice)... I am working with some more other
programs, nobody will know. The example demonstrates the basic problem.
$ cmd.exe /C bash.exe
$ export path=laughing
$ export PATH="/usr/bin"
$ cmd.exe /C bash.exe
$ echo $PATH
laughing
> No idea what this question is. Are you saying that you want
> a cygwin for the POSIX subsystem? There is no reason for such a thing.
No.
But the FAQ for cygwin says:
>The Cygwin tools are ports of the popular GNU development tools for
Microsoft Windows. They run thanks >to the Cygwin library which provides the
UNIX system calls and environment these programs expect.
Such things, as I described ar not happening on UNIX, and they doesn't
happen, when not brute force changing the environment by uppercase all and
everyting (in the wrong order).
The biggest problem, I can not switch it off.
best regards
Markus
> -----Original Message-
> From: Christopher Faylor [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 28, 2002 3:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Enviroment always uppercased; Help me, please
>
>
> On Thu, Feb 28, 2002 at 03:16:47PM +0100, Markus K. E. Kommant wrote:
> >Really???
> >
> >> Don't start the program from a non cygwin program.
> >
> >I am using Windows 2000/NT operating system as the base for my cygwin
> >programs and not DOS and not Linux.
>
> Huh?
>
> >Do anyone know a good trick to use POSIX Environment (or
> simply real Windows
> >Environment) without the cygwin-DOS changes.
>
> c:\> c:\cygwin\bin\sh -c "myprog.exe arg1 arg2"
>
> I really don't know what you're talking about wrt cygwin-DOS.
>
> >Hopefully waiting for help, without real POSIX I have to
> look for another
> >programming base, instead of cygwin...
> >
> >Probably there has anybody build an own cygwin1.dll with
> POSIX Environment
> >on Windows???
>
> No idea what this question is. Are you saying that you want
> a cygwin for
> the POSIX subsystem? There is no reason for such a thing.
>
> cgf
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Enviroment always uppercased; Help me, please
No, it doesn't When calling env.exe (compiled with cygwin1.dll), cygwin programs installed in c:/usr/bin starting cmd.exe: C:\>set garfield=1234 C:\>c:\usr\bin\env.exe | c:\usr\bin\grep -i gar GARFIELD=1234 env.exe (the cygwin program) has uppercased the environment. (the set in the example was the set of cmd.exe, useally there is no set.exe in /usr/bin) The solution, to start a cygwin program "NOT" from another cygwin program is impossible on Windows. B. Gates won't rebuild Windows with useage of cygwin1.dll? And this is not typical for Windows (as you see by using set from cmd.exe) and it is not typical for UNIX and POSIX. To uppercase some Environment values can make sense. When exporting them to a DOS (and some Windows programs), but this is not done by cygwin. And it could make sense to uppercase *some* variables, which come from Windows programs, see MKS Toolkit, like PATH, instead of Path, and some more, but this is optional. Else the use of cygwin is very restricted. I solved this problem in a port of the pdksh very carefully... But all the work is trash, if startupcode will change the environment - without notification or option to stop it. At the moment I am looking for a stable way (see thread Re: cygwin gcc DLLs loaded by Visual C++ crashing) to call the pdksh.exe as a pdksh1.dll. But the solution posted is not stable at the moment. After a while the programs will hang. But the environment is okay (startupcode of MSVC seems to be okay...). At least. Using the original Environment in cygwin is impossible. (> As cfg said: "Don't start the program from a non cygwin program") The solution could be a user build cygwin1.dll without the Environment hack?!? Anybody? Markus - Thread closed. > -Original Message- > From: Hack Kampbjørn [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 3:50 PM > To: Markus K. E. Kommant > Cc: [EMAIL PROTECTED] > Subject: Re: Enviroment always uppercased; Help me, please > > > "Markus K. E. Kommant" wrote: > > > > Really??? > > > > > Don't start the program from a non cygwin program. > > > > I am using Windows 2000/NT operating system as the base for > my cygwin > > programs and not DOS and not Linux. > > > > Do anyone know a good trick to use POSIX Environment (or > simply real Windows > > Environment) without the cygwin-DOS changes. > > > > Hopefully waiting for help, without real POSIX I have to > look for another > > programming base, instead of cygwin... > > > > Probably there has anybody build an own cygwin1.dll with > POSIX Environment > > on Windows??? > > > > Markus > > I don't know what you're asking for. Cygwin does provide case > sensitive > environment variables. > > In a cmd.exe window: > > C:\>set env_var=lowercase > C:\>set > [...] > env_var=lowercase > [...] > C:\>set ENV_VAR=UPPERCASE > C:\>set > [...] > env_var=UPPERCASE > [...] > C:\>cygwin > $ set | grep -i env_var > ENV_VAR=UPPERCASE > $ logout > C:\cygwin\bin>exit > > And in cygwin's bash: > $ env_var=lowercase > $ ENV_VAR=UPPERCASE > $ set | grep -i env_var > ENV_VAR=UPPERCASE > env_var=lowercase > $ bash > $ set | grep -i env_var > $ exit > $ export env_var ENV_VAR > $ bash > $ set | grep -i env_var > ENV_VAR=UPPERCASE > env_var=lowercase > $ exit > $ cmd.exe > Microsoft Windows 2000 [Version 5.00.2195] > (C) Copyright 1985-2000 Microsoft Corp. > > C:\>set > [...] > ENV_VAR=UPPERCASE > [...] > env_var=lowercase > [...] > > As cfg said: "Don't start the program from a non cygwin program" > > -- > Med venlig hilsen / Kind regards > > Hack Kampbjørn > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Enviroment always uppercased; Help me, please
Really??? > Don't start the program from a non cygwin program. I am using Windows 2000/NT operating system as the base for my cygwin programs and not DOS and not Linux. Do anyone know a good trick to use POSIX Environment (or simply real Windows Environment) without the cygwin-DOS changes. Hopefully waiting for help, without real POSIX I have to look for another programming base, instead of cygwin... Probably there has anybody build an own cygwin1.dll with POSIX Environment on Windows??? Markus > -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 27, 2002 6:59 PM > To: [EMAIL PROTECTED] > Subject: Re: Enviroment always uppercased; Help me, please > > > On Wed, Feb 27, 2002 at 06:46:57PM +0100, Markus K. E. Kommant wrote: > >Seems to be a cygwin "feature" that the environment will be > uppercased, when > >called by a none cygwin program. > > "Correct". > > >Is there a trick to switch to a "POSIX" mode in cygwin and > leave the case of > >the environment unchanged? > > Don't start the program from a non cygwin program. > > cgf > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Enviroment always uppercased; Help me, please
Seems to be a cygwin "feature" that the environment will be uppercased, when
called by a none cygwin program.
When puting a variable "gar=1" into the environment and call a program
compiled with gcc and cygwin, the result, when printing the environment,
will be
GAR=1
ups, gar != GAR, especially in a POSIX environment!
When compiling the program with MS Developer Studio C++ the printed result
will be
gar=1
and that's okay.
Is there a trick to switch to a "POSIX" mode in cygwin and leave the case of
the environment unchanged?
parameter.c:
#include
#include
int main ( int argc, char **argv, char **envp)
{
int i;
char **wp;
printf("Environment:\n");
if (envp != NULL)
for (wp = envp; *wp != NULL; wp++)
printf("%s\n", *wp);
printf("Parameters %d\n", argc);
for (i=0;i>%s<<\n", i+1, strlen(argv[i]),
argv[i]);
}
return argc;
}
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Strange output from ps -W, (\\?\?, \??\)
> \??\C:\WIN2KPRO\system32\winlogon.exe
the \??\ could by "something" very special in the bootstrap of the system.
I belive, that it could be a \\?\?\
which will be chown as \??\ (\? interpreted as the escape sequence for ?)
The path \\?\?\ could be:
\\? = do not use "path parsing" and stay on the current volumne (ignore
mount points etc)
\?\ = could be the Volume GUID Name = ?, and ? could be the first, boot or
current volume.
MSDN Volume Names , UNC and MountPoints:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fsys
_64oj.asp
Unique Volume Names
Two factors can make it hard to reliably mount a specific volume at a
specified volume mount point across operating system restarts. One factor is
that two different volumes can have the same label, which makes them
indistinguishable except by drive letter. The other factor is that drive
letters do not necessarily remain the same. If a computer's administrator
does not use the Disk Administrator to enforce drive letters, then drive
letters can change as drives are removed from or added to the system.
To solve this problem, the system refers to volumes to be mounted with
unique volume names. These are strings of this form:
"\\?\Volume{GUID}\"
where GUID is a globally unique identifier (GUID) that identifies the
volume. The \\?\ turns off path parsing and is ignored as part of the path,
as discussed in Path Lengths. Note the trailing backslash. All volume mount
point functions that take a unique volume name as a parameter require the
trailing backslash; all volume mount point functions that return a unique
volume name provide the trailing backslash. You can use CreateFile to open a
volume by referring to its unique volume name, but without a trailing
backslash. When using CreateFile, a unique volume name with a backslash
refers to the root directory of the volume.
The operating system assigns a unique volume name to a volume when the
computer first encounters it, for example during formatting or installation.
The volume mount point functions use unique volume names to refer to
volumes. To learn the unique volume name of any drive, use the
GetVolumeNameForVolumeMountPoint function.
The Unicode versions of several functions permit paths that exceed the
MAX_PATH length if the path has the "\\?\" prefix. The "\\?\" tells the
function to turn off path parsing. However, each component in the path
cannot be more than MAX_PATH characters long. Use the "\\?\" prefix with
paths for local storage devices and the "\\?\UNC\" prefix with paths having
the Universal Naming Convention (UNC) format. The "\\?\" is ignored as part
of the path. For example, "\\?\C:\myworld\private" is seen as
"C:\myworld\private", and "\\?\UNC\bill_g_1\hotstuff\coolapps" is seen as
"\\bill_g_1\hotstuff\coolapps".
> -Original Message-
> From: Stephano Mariani [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 07, 2002 9:24 PM
> To: [EMAIL PROTECTED]
> Subject: Strange output from ps -W
>
>
> The relevant line from ps -W
>
> PIDPPIDPGID WINPID TTY UIDSTIME COMMAND
> 196 0 0196?0 Feb 6
> \??\C:\WIN2KPRO\system32\winlogon.exe
>
> Is this normal? Why is the command prefixed with "\??\"?
>
> Stephano Mariani
>
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
