Re: [ITP] gobject-introspection
On Nov 15 22:40, Yaakov S wrote: On 09/11/2009 14:38, Yaakov (Cygwin/X) wrote: GObject Introspection is a language-agnostic binding tool for GObject-based libraries. It generates typelibs describing the library's API, which can then be read and used through a library (libgirepository) or language bindings thereto (currently available for Python and JavaScript). The typelibs for GLib, various X11 libraries used higher up the stack, and a test module are also included. This is necessary for GNOME 2.28, as Pango builds its typelib concurrently, and PyGObject 2.20 includes Python bindings to libgirepository. Ping? GNOME 2.28 is ready to ship as soon as this is approved. Packaging looks good, but: - girepository-x11/setup.hint contains no requires line. - gobject-introspection itself requires libgirepository1.0-devel. The base package requires its own -devel package? If that's ok, the package is ok to upload. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU 1.7] whois-4.7.36-1
Yaakov (Cygwin/X) wrote: Uploaded. Can 4.7.24-1 be deleted? Sure. The requires: line should NOT include 'cygwin'. I fixed this before uploading, but please fix your local copy. Whoops. Locally updated. -- Lapo Luchini - http://lapo.it/ “I couldn't help but overhear, probably because I was eavesdropping.” (anonymous)
Re: ITP: libustr
Yaakov (Cygwin/X) wrote: 1) Shouldn't the DLLs be linked with -Wl,--enable-auto-image-base? (Why this isn't the binutils default already, I really don't know.) It's in the compiler's link spec, turned on automatically when you use -shared or -mdll, so anything that uses the gcc driver to link should get it. Is this another case of libtool building the command-line by pieces and not doing exactly what the gcc driver would have done? cheers, DaveK
Re: ITP: libustr
Dave Korn wrote: Yaakov (Cygwin/X) wrote: 1) Shouldn't the DLLs be linked with -Wl,--enable-auto-image-base? (Why this isn't the binutils default already, I really don't know.) It's in the compiler's link spec, turned on automatically when you use -shared or -mdll, so anything that uses the gcc driver to link should get it. Is this another case of libtool building the command-line by pieces and not doing exactly what the gcc driver would have done? No, it's that I'm using gcc3 to build on cygwin-1.5. and the statement above is true only for cygwin's gcc4. -- Chuck
Re: [ITP] talkfilters-3.8.1-1
On 11/13/2009 19:32, JonY wrote: On 11/11/2009 03:30, Yaakov (Cygwin/X) wrote: On 10/11/2009 03:38, Corinna Vinschen wrote: You didn't say in which stable Linux distro this package is available. Without that info, your package needs five votes from other maintainers. +1 Packaging looks good. I'm just wondering why all the executables are linked statically against libtalkfilters, rather than being linked against cygtalkfilters-1.dll. Don't eat your own dog food? ;) That's how upstream made the package, no fault of OP. (Cygwin Ports has had talkfilters for a while, as libtranslate uses it.) Yaakov Ping. Any other votes? Ping. One more +1 to go. :)
Re: ITP: libustr
On 16/11/2009 03:13, Dave Korn wrote: Yaakov (Cygwin/X) wrote: 1) Shouldn't the DLLs be linked with -Wl,--enable-auto-image-base? (Why this isn't the binutils default already, I really don't know.) It's in the compiler's link spec, turned on automatically when you use -shared or -mdll, so anything that uses the gcc driver to link should get it. Good to know; I wasn't aware that this change had been made. Yaakov
Re: [RFU 1.7] whois-4.7.36-1
On 16/11/2009 02:42, Lapo Luchini wrote: Yaakov (Cygwin/X) wrote: Uploaded. Can 4.7.24-1 be deleted? Sure. Done. Yaakov
Re: [ITP] gobject-introspection
On 16/11/2009 02:36, Corinna Vinschen wrote: Packaging looks good, but: - girepository-x11/setup.hint contains no requires line. This is correct. The x11 typelibs just define typedefs and constants used higher up the stack; they do not use library symbols so they do not depend on their respective C libraries. - gobject-introspection itself requires libgirepository1.0-devel. The base package requires its own -devel package? gobject-introspection (the compilers) includes an aclocal macro which depends on the gobject-introspection-1.0.pc pkg-config file. The latter is also used for linking against libgirepository, so it is part of -devel, hence the dependency. Yaakov
Re: 'run xterm' fails to open a window
thanks for the reply I tested doing c:\Cygwin\bin\run.exe sh -c env|grep DISP /cygdrive/c/log I get the expected value : DISPLAY=:0.0 C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /cygdrive/c/log 21 do diplay waring in the log but does make the window appears in fact it seems that because gvim do output some error string it is stopped by run.exe so as said in next reply C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /dev/null 21 is a workaround thanks JLM On Tue, Nov 10, 2009 at 7:03 AM, Linda Walsh cyg...@tlinx.org wrote: jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: 'run xterm' fails to open a window
the workaround isn't sufficient installing the font don't help setting the LANG=C don't help but in gvim.bat C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim '%*'/dev/null 21 don't work all the time 1)if I run it in a cmd.com : gvim.bat c:\some\path\to.file it's working 2)if I do open with in explorer, this don't work, after investigation it appears that %* in this case is replaced by c:\some\path\to.file ie C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim 'c:\some\path\to.file'/dev/null 21 (note that there is double quote inside single quote) removing the single quote cause the \ to be escaped and then gvim try to open c:omeatho.file. please can someone give a fix to run.exe so that the process is run with stdout and stderr redirected to /dev/null? thanks JLM On Mon, Nov 16, 2009 at 5:04 PM, jean-luc malet jeanluc.ma...@gmail.com wrote: thanks for the reply I tested doing c:\Cygwin\bin\run.exe sh -c env|grep DISP /cygdrive/c/log I get the expected value : DISPLAY=:0.0 C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /cygdrive/c/log 21 do diplay waring in the log but does make the window appears in fact it seems that because gvim do output some error string it is stopped by run.exe so as said in next reply C:\cygwin\bin\run.exe -p /usr/bin sh -c gvim /dev/null 21 is a workaround thanks JLM On Tue, Nov 10, 2009 at 7:03 AM, Linda Walsh cyg...@tlinx.org wrote: jean-luc malet wrote: thanks for the reply, for some reason I would like to continue using the cygwin one... this .bat was working some time ago, until I update cygwin 1) when I launch cygwin's gvim from a dos cmd shell it run as expected 2) when I launch c:\Cygwin\bin\run gvim in the same dos cmd shell it spawn a process gvim (ps -a show it) attached to con but nothing is displayed on screen - this isn't a pb of DISPLAY else 1) wouldn't have worked and cygwin's gvim wouldn't have displayed That may not, exactly, be the case. I was under the impression that starting something using the 'run' command is starting outside of your normal Cygwin session (and not attached to a Shell window). Depending on how you set your DISPLAY variable, this could easily mean that the 'gvim' you start via run doesn't have DISPLAY set properly. I.e. if you set DISPLAY in your cygwin environment via the startup commands in BASH, OR if you start X, which spawns an Xterm, that already has DISPLAY, preset for you, (by X, before it spawns Xterm), then by using run, you are starting 'gvim' outside of the environment where you normally have DISPLAY set to a valid value. The only way DISPLAY would be set correctly for gvim when run using 'run', is if you be sure that it's set by the 'run' command, OR if you have it set in your Windows System or User Environment variables when you log on (settable in Computer Properties(shortcut=WIN-BREAK on keyboard), then Advanced-Environment Variables. There you can set display for your userid, or system wide under the User variables. So do you know that DISPLAY is set correctly for gvim when invoked by run? A test you could do is « run bash.exe -c printenv/tmp/my_envvars.txt » That will dump out all the env vars you think you are setting to a file that you can look at after running it -- then you can make sure DISPLAY is set the way you want it. BTW, regarding Vim versions: I use the X-version of Gvim when i'm logged into my linux machines, but I use the Win version locally on my desktop (or the 'cygwin-vim' version when I'm working in a command window and just want to do quick edits). So I jump between all three version somewhat interchangeably. The Win version has a nicety that you can set the horizontal scaling of a font separately from the vertical scaling, and use 'half' sizes like Lucida_Console:h10.5 -- which is different than Lucida_Console:10, or 11. But the X-version of Gvim has better Foreign character display capabilities which can confused the Windows version. So depends on what I'm editing I suppose, as well. Hope the DISPLAY stuff helps. -linda -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm --
src/winsup/cygserver ChangeLog Makefile.in
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-11-16 08:50:07 Modified files: winsup/cygserver: ChangeLog Makefile.in Log message: * Makefile.in (cygserver.exe): Link with -static to avoid linking against cygstdc++-6.dll due to references to __cxa_pure_virtual. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygserver/ChangeLog.diff?cvsroot=srcr1=1.75r2=1.76 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygserver/Makefile.in.diff?cvsroot=srcr1=1.23r2=1.24
src/winsup/doc ChangeLog pathnames.sgml
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2009-11-16 12:30:00 Modified files: winsup/doc : ChangeLog pathnames.sgml Log message: * pathnames.sgml (pathnames-specialchars): Fix typos. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.244r2=1.245 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/doc/pathnames.sgml.diff?cvsroot=srcr1=1.47r2=1.48
Re: 'ls' not finding owner/group of some files created by other user
On Nov 15 08:48, aputerguy wrote: Jason DePriest wrote: Does 'ls -n' show the UIDs under both users? ls -n shows uid=gid=4294967295 which I believe is UINT_MAX (2^32-1), so this is just -1. Maybe what's happening is that cygwin is returning an error (-1) here? It means it doesn't know the SIDs. They don't show up in /etc/passwd and /etc/group. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
On Nov 15 20:02, aputerguy wrote: OK - I just re-read the ntsec portion of the cygwin manual and found this paragraph: [...] So is 'subinacl' just another example of these badly behaved non-Cygwin applications? If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? The other methods *are* the solutions for this problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
aputerguy wrote: So is 'subinacl' just another example of these badly behaved non-Cygwin applications? Looks like it. If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? You mean, apart from the other methods to get a properly authenticated ssh login, is there a method to get a properly authenticated ssh login? No, there is no method to get a properly authenticated ssh login, apart from the methods to get a properly authenticated ssh login. If you want a method to get a properly authenticated ssh login, I'm afraid you're completely stuck; you'll just have to use one of the methods to get an authenticated ssh login. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.0-64: cygserver linked against cygstdc++-6.dll (libstdc++6)
On Nov 15 10:18, Steven Monai wrote: In 1.7.0-64, /usr/sbin/cygserver is linked against cygstdc++-6.dll. cygserver will not run (exit status 128) unless the 'libstdc++6' package is installed. Fixed in CVS. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
On Nov 16 09:01, Dave Korn wrote: aputerguy wrote: So is 'subinacl' just another example of these badly behaved non-Cygwin applications? Looks like it. If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? You mean, apart from the other methods to get a properly authenticated ssh login, is there a method to get a properly authenticated ssh login? No, there is no method to get a properly authenticated ssh login, apart from the methods to get a properly authenticated ssh login. If you want a method to get a properly authenticated ssh login, I'm afraid you're completely stuck; you'll just have to use one of the methods to get an authenticated ssh login. Sounds tricky... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] [1.7] Updated: whois 4.7.36-1
I've updated the Cygwin 1.7 version of whois to 4.7.36-1. Whois is a client for the whois directory service. It allows you to retrieve information on domains name, IP addresses, and more. If you're not sure what version do you have you can use the following command to both check version number and integrity of the install: % cygcheck -c whois If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sources.redhat.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Lapo Luchini -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
Corinna Vinschen wrote: On Nov 16 09:01, Dave Korn wrote: aputerguy wrote: So is 'subinacl' just another example of these badly behaved non-Cygwin applications? Looks like it. If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? You mean, apart from the other methods to get a properly authenticated ssh login, is there a method to get a properly authenticated ssh login? No, there is no method to get a properly authenticated ssh login, apart from the methods to get a properly authenticated ssh login. If you want a method to get a properly authenticated ssh login, I'm afraid you're completely stuck; you'll just have to use one of the methods to get an authenticated ssh login. Sounds tricky... Yep. It might be easier to just use one of the methods to get an authenticated ssh login instead. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
Andy Koppe wrote: I'd suspect the support for ADSs in 1.5 was rather accidental anyway. POSIX programs certainly don't know about them, and you get the rather weird situation that files like foo:bar can be accessed but don't show up in the directory they're in. Hence I think the right way to access ADSs is via Windows tools. Unless there is a POSIXy way to represent them? I've only learned about this ADS stuff recently but yes, I think, simply using the a:b syntax (which is also used by Windows tools) and handling them as a virtual file is a quite obvious POSIX way to do it. So if it worked in 1.5, whether accidental or not, I think it should continue to work in 1.7. The loss of this feature may simply be a consequence of handling illegal filename characters via the Unicode private range, so the resolution might be as easy as taking out : from this handling again, just a guess. Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
On Nov 16 12:56, Thomas Wolff wrote: Andy Koppe wrote: I'd suspect the support for ADSs in 1.5 was rather accidental anyway. POSIX programs certainly don't know about them, and you get the rather weird situation that files like foo:bar can be accessed but don't show up in the directory they're in. Hence I think the right way to access ADSs is via Windows tools. Unless there is a POSIXy way to represent them? I've only learned about this ADS stuff recently but yes, I think, simply using the a:b syntax (which is also used by Windows tools) and handling them as a virtual file is a quite obvious POSIX way to do it. So if it worked in 1.5, whether accidental or not, I think it should continue to work in 1.7. It's a deliberate change. It's more important to support as much POSIXy filenames as possible than to access streams. I agree with Andy. Use Windows tools to use them. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
I think it should still at least be documented as a change especially since a deliberate change. -- View this message in context: http://old.nabble.com/Seems-like-treatment-of-NTFS-ADS-%28foo%3Abar%29-changed-between-1.5-and-1.7-but-not-mentioned-in-What%27s-Changed-tp26363833p26370924.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
On Nov 16 04:19, aputerguy wrote: I think it should still at least be documented as a change especially since a deliberate change. It was never documented that streams are supported at all. And the usage of special DOS chars for filenames is documented: http://cygwin.com/1.7/cygwin-ug-net/ov-new1.7.html#ov-new1.7-file http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html#pathnames-specialchars Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
Corinna Vinschen wrote: On Nov 16 12:56, Thomas Wolff wrote: Andy Koppe wrote: I'd suspect the support for ADSs in 1.5 was rather accidental anyway. POSIX programs certainly don't know about them, and you get the rather weird situation that files like foo:bar can be accessed but don't show up in the directory they're in. Hence I think the right way to access ADSs is via Windows tools. Unless there is a POSIXy way to represent them? I've only learned about this ADS stuff recently but yes, I think, simply using the a:b syntax (which is also used by Windows tools) and handling them as a virtual file is a quite obvious POSIX way to do it. So if it worked in 1.5, whether accidental or not, I think it should continue to work in 1.7. It's a deliberate change. It's more important to support as much POSIXy filenames as possible than to access streams. I agree with Andy. Use Windows tools to use them. But with it being supported, foo:bar *is* a POSIX filename and can quite transparently be handled like a file, just that the underlying filesystem in some cases (i.e. if it is NTFS) maps it to a fork of some other file. So in practice, it *is* actually a file too, despite the fact that MS uses weird terminology and inconsistent tooling for it. And since I read that the use cases for ADS may increase with future Windows versions, I just thought it should be a good idea not to ignore these files. Moreover, this transparent mapping would also solve the copy/backup problem discussed in the other thread (was it rsync?) and actually all problems at once, like including these things in zip archives etc. Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'ls' not finding owner/group of some files created by other user
Corinna Vinschen writes: It means it doesn't know the SIDs. They don't show up in /etc/passwd and /etc/group. BUT THEY DO! And they must since why else would doing a trivial 'chmod' (that doesn't change anything) all of a sudden make them show up. $ subinacl /noverbose /nostatistic /file C:\\cygwin\\usr\\local\\bin\\testfolder /findsid=S-1-5-21-1234567890-1234567890-1234567890-1005 +File C:\cygwin\usr\local\bin\testfolder /control=0x0 /owner =mymachine\userA /pace =mymachine\userA Type=0x0 Flags=0x0 AccessMask=0x1f01ff $ grep S-1-5-21-1234567890-1234567890-1234567890-1005 /etc/passwd userA:unused:1005:513:U-mymachine\userA,S-1-5-21-1234567890-1234567890-1234567890-1005:/home/userA:/bin/bash Note this error doesn't happen if I create a folder (using Windows tools) in C: but it does happen in all the other public places I tried, including: /c/Program Files /c/cygwin/usr /c/cygwin/usr/local /c/cygwin/usr/local/bin -- View this message in context: http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26371224.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
2009/11/16 Thomas Wolff: I'd suspect the support for ADSs in 1.5 was rather accidental anyway. POSIX programs certainly don't know about them, and you get the rather weird situation that files like foo:bar can be accessed but don't show up in the directory they're in. Hence I think the right way to access ADSs is via Windows tools. Unless there is a POSIXy way to represent them? I've only learned about this ADS stuff recently but yes, I think, simply using the a:b syntax (which is also used by Windows tools) and handling them as a virtual file is a quite obvious POSIX way to do it. So if it worked in 1.5, whether accidental or not, I think it should continue to work in 1.7. It's a deliberate change. It's more important to support as much POSIXy filenames as possible than to access streams. I agree with Andy. Use Windows tools to use them. But with it being supported, foo:bar *is* a POSIX filename and can quite transparently be handled like a file If you create a file called foo:bar in Cygwin 1.5, a directory listing will actually show a file called foo of size 0. You have to already know that foo:bar exists to access it, and there's no way in Cygwin to find those files. Furthermore, if you delete the file foo, you'll also delete foo:bar and any other ADSs of foo. Again, something that POSIX programs don't expect. Moreover, this transparent mapping would also solve the copy/backup problem discussed in the other thread (was it rsync?) and actually all problems at once, like including these things in zip archives etc. Zip would never know about the ADSs, because they don't show up in directory listings. Same in cmd.exe, btw. I guess they could be included in Cygwin directory listings, but - It would be a chunky piece of work to implement it. - It would slow down directory operations. - Non-POSIX behaviours would remain: creating foo:bar would create an empty foo and deleting foo would also delete foo:bar and any other ADSs. I think they'd need a special API if they were to be supported. Do they fit into the xattr stuff? Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
2009/11/16 aputerguy: Well I'm using Putty to ssh into my Windows machine running cygwin 1.5 When I do tab completion on the foo:bar file it completes to foo\357\200\272 but perhaps the Unicode is coming from the Putty terminal (which is set to UTF-8) though somehow bash is preserving the encoding that gets translated that way... Right, it was pasting into the UTF-8-configured PuTTY then that translated the U+F03A to \357\200\272. As far as Cygwin 1.5's bash is concerned, that's just a bunch of bytes. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'ls' not finding owner/group of some files created by other user
On Nov 16 04:41, aputerguy wrote: Corinna Vinschen writes: It means it doesn't know the SIDs. They don't show up in /etc/passwd and /etc/group. BUT THEY DO! And they must since why else would doing a trivial 'chmod' (that doesn't change anything) all of a sudden make them show up. $ subinacl /noverbose /nostatistic /file C:\\cygwin\\usr\\local\\bin\\testfolder /findsid=S-1-5-21-1234567890-1234567890-1234567890-1005 +File C:\cygwin\usr\local\bin\testfolder /control=0x0 /owner =mymachine\userA /pace =mymachine\userA Type=0x0 Flags=0x0 AccessMask=0x1f01ff $ grep S-1-5-21-1234567890-1234567890-1234567890-1005 /etc/passwd userA:unused:1005:513:U-mymachine\userA,S-1-5-21-1234567890-1234567890-1234567890-1005:/home/userA:/bin/bash Note this error doesn't happen if I create a folder (using Windows tools) in C: but it does happen in all the other public places I tried, including: /c/Program Files /c/cygwin/usr /c/cygwin/usr/local /c/cygwin/usr/local/bin In that case, the problem probably occurs because userB has no permissions to read the file permissions. Cygwin's chmod creates a POSIX compatible ACL, which adds READ_CONTROL permissions for everyone. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
On Nov 16 13:32, Andy Koppe wrote: 2009/11/16 Thomas Wolff: But with it being supported, foo:bar *is* a POSIX filename and can quite transparently be handled like a file If you create a file called foo:bar in Cygwin 1.5, a directory listing will actually show a file called foo of size 0. You have to already know that foo:bar exists to access it, and there's no way in Cygwin to find those files. Furthermore, if you delete the file foo, you'll also delete foo:bar and any other ADSs of foo. Again, something that POSIX programs don't expect. Or, just for kicks, try to create a file abc:def:ghi under 1.5 or, FWIW, under CMD. Moreover, this transparent mapping would also solve the copy/backup problem discussed in the other thread (was it rsync?) and actually all problems at once, like including these things in zip archives etc. Zip would never know about the ADSs, because they don't show up in directory listings. Same in cmd.exe, btw. I guess they could be included in Cygwin directory listings, but - It would be a chunky piece of work to implement it. - It would slow down directory operations. - Non-POSIX behaviours would remain: creating foo:bar would create an empty foo and deleting foo would also delete foo:bar and any other ADSs. I think they'd need a special API if they were to be supported. Do they fit into the xattr stuff? No, xattrs and ADS are entirely different beasts. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
Corinna Vinschen wrote: On Nov 16 13:32, Andy Koppe wrote: 2009/11/16 Thomas Wolff: But with it being supported, foo:bar *is* a POSIX filename and can quite transparently be handled like a file If you create a file called foo:bar in Cygwin 1.5, a directory listing will actually show a file called foo of size 0. You have to already know that foo:bar exists to access it, and there's no way in Cygwin to find those files. Furthermore, if you delete the file foo, you'll also delete foo:bar and any other ADSs of foo. Again, something that POSIX programs don't expect. Or, just for kicks, try to create a file abc:def:ghi under 1.5 or, FWIW, under CMD. Well, I wanted to withdraw my arguments when I read this but then I simply tried in 1.5 and it worked quite well... Of course Andy is right and directory handling would have to be tweaked to gain maximum consistence with POSIX, e.g. removing the base file might have to leave a dummy empty base file if there are forks... Isn't one of the goals of cygwin to provide a mostly POSIX-like gateway to Windows resources and isn't quite a lot of effort being put to this aim about some other features, e.g. the weird security stuff? I think ADS sounds easier and more worth some effort, also considering NTFS is not the only file system with this kind of feature (e.g. Mac forks). Kind regards, Thomas Moreover, this transparent mapping would also solve the copy/backup problem discussed in the other thread (was it rsync?) and actually all problems at once, like including these things in zip archives etc. Zip would never know about the ADSs, because they don't show up in directory listings. Same in cmd.exe, btw. I guess they could be included in Cygwin directory listings, but - It would be a chunky piece of work to implement it. - It would slow down directory operations. - Non-POSIX behaviours would remain: creating foo:bar would create an empty foo and deleting foo would also delete foo:bar and any other ADSs. I think they'd need a special API if they were to be supported. Do they fit into the xattr stuff? No, xattrs and ADS are entirely different beasts. Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
Thomas Wolff wrote: Corinna Vinschen wrote: ... Or, just for kicks, try to create a file abc:def:ghi under 1.5 or, FWIW, under CMD. Well, I wanted to withdraw my arguments when I read this but then I simply tried in 1.5 and it worked quite well... Where I visually mistook the second : for a . however... (blush). Anyway, maybe some syntax could be found that would not be too harmful to become reserved for this purpose... end:of:rationale:for:weird:feature Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to capture stderr of dos process running in bash shell??
On Sun, Nov 15, 2009 at 06:59:03PM -0800, aputerguy wrote: Dave Korn writes... So, it just doesn't work, and that's using all MS software; it's not going to work any better in bash. I think you're probably out of luck here; I don't know any way to capture direct console output like that (short of some sort of screen scraper or even if you want a wooden table solution taking a snapshot and OCRing it...!) True... just for the record, you can capture stderr to a file using the flag /errorlog=file or even dump it to /dev/null using /errorlog=$(cygpath -w /dev/null) or equivalently /errorflag=\\.\NULL which to my surprise actually worked. And once you have split off stderr, you are left with just the output on stdout which is now in the bash world so you can treat it using standard bash pipes and redirection. I just couldn't figure out how to pipe the stderr -- since in my case I wanted to pipe it through gzip before capturing it to a file. So, instead I do the slightly less elegant thing of first capturing to a file and then running gzip later on that file. I do agree with you though that the original question is probably more a question of a broken windows program and I'm thinking that the help is just plain wrong in saying that the error is on stderr but rather I believe that stdout and stderr are a single stream unless you use /errorlog to explicitly fork it off to a file. Ok, then since we've confirmed that this problem has nothing to do with Cygwin, I think it's time to close down this thread. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Seems like treatment of NTFS ADS (foo:bar) changed between 1.5 and 1.7 but not mentioned in What's Changed
On Mon, Nov 16, 2009 at 03:55:43PM +0100, Thomas Wolff wrote: Thomas Wolff wrote: Corinna Vinschen wrote: ... Or, just for kicks, try to create a file abc:def:ghi under 1.5 or, FWIW, under CMD. Well, I wanted to withdraw my arguments when I read this but then I simply tried in 1.5 and it worked quite well... Where I visually mistook the second : for a . however... (blush). Anyway, maybe some syntax could be found that would not be too harmful to become reserved for this purpose... end:of:rationale:for:weird:feature Sorry but I agree with Corinna. On linux/UNIX you can create a file with a colon in it. We can now do this in Cygwin 1.7 and that's a good thing. Complicating the path handling to deal specially with colons in a filename doesn't sound like a good idea to me. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
On Mon, Nov 16, 2009 at 09:14:11AM +, Dave Korn wrote: Corinna Vinschen wrote: On Nov 16 09:01, Dave Korn wrote: aputerguy wrote: So is 'subinacl' just another example of these badly behaved non-Cygwin applications? Looks like it. If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? You mean, apart from the other methods to get a properly authenticated ssh login, is there a method to get a properly authenticated ssh login? No, there is no method to get a properly authenticated ssh login, apart from the methods to get a properly authenticated ssh login. If you want a method to get a properly authenticated ssh login, I'm afraid you're completely stuck; you'll just have to use one of the methods to get an authenticated ssh login. Sounds tricky... Yep. It might be easier to just use one of the methods to get an authenticated ssh login instead. Is that even possible though? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: subinacl not consistent with getfacl under ssh login (USERNAME=SYSTEM)
Christopher Faylor wrote: On Mon, Nov 16, 2009 at 09:14:11AM +, Dave Korn wrote: Corinna Vinschen wrote: On Nov 16 09:01, Dave Korn wrote: aputerguy wrote: So is 'subinacl' just another example of these badly behaved non-Cygwin applications? Looks like it. If so, is there anything one can do other than to use one of the other methods to get a properly authenticated ssh login? You mean, apart from the other methods to get a properly authenticated ssh login, is there a method to get a properly authenticated ssh login? No, there is no method to get a properly authenticated ssh login, apart from the methods to get a properly authenticated ssh login. If you want a method to get a properly authenticated ssh login, I'm afraid you're completely stuck; you'll just have to use one of the methods to get an authenticated ssh login. Sounds tricky... Yep. It might be easier to just use one of the methods to get an authenticated ssh login instead. Is that even possible though? cgf I don't know, he'll have to try it. If it doesn't work, at least there's always a workaround: use one of the methods to get an authenticated ssh login. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'ls' not finding owner/group of some files created by other user
Corinna Vinschen writes: In that case, the problem probably occurs because userB has no permissions to read the file permissions. Cygwin's chmod creates a POSIX compatible ACL, which adds READ_CONTROL permissions for everyone. That seems to be the case here and would seem to explain it - thanks! BTW, it seems that chmod also adds FILE_READ_ATTRIBUTES though READ_CONTROL is all that was needed to solve my problem. Also, for the record, it seems that 'cp -a' does similar except it also *deletes* the SYSTEM ACL attributes of DELETE, WRITE_DAC and WRITE_OWNER. It's not intuitively obvious to me why 'cp -a' would degrade permissions... That being said is there (or should there) be a flag to 'cp' that will strictly preserve 'all' ACL attributes in a similar way to how Linux has the -Z flag to preserve SELinux context? (cp -r --preserve=all doesn't do so) I had always (mistakenly) assumed that 'cp -a' would do a pristine job of copying -- it would be nice to have a cygwin tool that would be pristine that way without having to go to Windows tools. I apologize for all these maybe newbie-like questions but I am still used to *nix rwx permissions and in this case even getfacl didn't help. I needed to go to my new friend subinacl to see what you were saying - wasn't obvious to me at least. -- View this message in context: http://old.nabble.com/%27ls%27-not-finding-owner-group-of-some-files-created-by-other-user-tp26355135p26377078.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 'ls' not finding owner/group of some files created by other user
On Nov 16 10:33, aputerguy wrote: Corinna Vinschen writes: In that case, the problem probably occurs because userB has no permissions to read the file permissions. Cygwin's chmod creates a POSIX compatible ACL, which adds READ_CONTROL permissions for everyone. That seems to be the case here and would seem to explain it - thanks! BTW, it seems that chmod also adds FILE_READ_ATTRIBUTES though READ_CONTROL is all that was needed to solve my problem. Also, for the record, it seems that 'cp -a' does similar except it also *deletes* the SYSTEM ACL attributes of DELETE, WRITE_DAC and WRITE_OWNER. It's not intuitively obvious to me why 'cp -a' would degrade permissions... That being said is there (or should there) be a flag to 'cp' that will strictly preserve 'all' ACL attributes in a similar way to how Linux has the -Z flag to preserve SELinux context? It's not cp but the Cygwin DLL which looks for the permissions. The permission bits are strictly viewed from a POSIX point of view and all rwx bits are translated to a specific set of ACE permission bits and vice versa. If you need control over every single permission bit in a Windows ACL, use a Windows tool. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
SWI Prolog will not fix their software for Cygwin
Just FYI. ---BeginMessage--- http://gollem.science.uva.nl/bugzilla/show_bug.cgi?id=429 Jan Wielemaker b...@swi-prolog.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Jan Wielemaker b...@swi-prolog.org 2009-11-15 11:03:18 --- Terrence, I'm sorry, but Cygwin is not supported by me. I do apply patches if I receive them, but I'm not actively hunting Cygwin issues. You can try the mailinglist or maybe Mary Ellen Foster m...@inf.ed.ac.uk, who has fixed Cygwin issues before. Cheers --- Jan -- Configure bugmail: http://gollem.science.uva.nl/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. ---End Message--- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SWI Prolog will not fix their software for Cygwin
Terrence Brannon wrote: Subject: [Bug 429] term.h on Cygwin not existent. no warning during configure From: bugzilla-dae...@gollem.science.uva.nl term.h is provided by ncurses, and is located in /usr/include/ncurses/. So, all you need to do (I think) is add -I/usr/include/ncurses to your CPPFLAGS, and (perhaps) link against -lncurses. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Use of Dual Core causes random failures building OpenJDK
I've been trying to build OpenJDK for several weeks now and have never been able to get to the end of the build because of random failures. Last night I had a hunch to turn off one of the cores in BIOS and after doing that the problems have gone away. My system is a Lenovo T500, Model 2081-CTO, with an Intel Core2 Duo P8700 at 2.53 GHz and 2 GB of RAM running XP Pro SP3. The latest updates have been applied to the Lenovo system and to XP. Some examples of failures: - empty environment variables - invalid environment variables - files not found (possibly related to corrupted environment variables) Attached is my cygcheck.out file. -- *Pete Brunet* a11ysoft - Accessibility Architecture and Development (512) 238-6967 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G Cygwin Configuration Diagnostics Current System Time: Mon Nov 16 13:26:46 2009 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program Files\Windows Resource Kits\Tools\ c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\ATI Technologies\ATI.ACE\Core-Static c:\Program Files\Common Files\Lenovo c:\Program Files\Common Files\Roxio Shared\10.0\DLLShared\ c:\Program Files\Common Files\Roxio Shared\DLLShared\ c:\Program Files\ThinkPad\ConnectUtilities c:\Program Files\Lenovo\Client Security Solution c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\Program Files\doxygen\bin c:\Program Files\Support Tools\ c:\utilities c:\Program Files\apache-ant-1.7.1 c:\Python26 c:\MinGW\bin c:\Program Files\KDiff3 c:\Program Files\QuickTime\QTSystem\ c:\Program Files\Mercurial c:\Program Files\Git\cmd c:\Program Files\Intel\WiFi\bin\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 1008(Pete) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1008(Pete) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Pete' PWD = '/home/Pete' HOME = '/home/Pete' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\Pete' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\Pete\Application Data' HOSTNAME = 'Bevo' RR = 'C:\Program Files\Lenovo\Rescue and Recovery' DXSDK_DIR = 'C:\Program Files\Microsoft DirectX 9.0 SDK (Summer 2004)\' TVTCOMMON = 'C:\Program Files\Common Files\Lenovo' TERM = 'cygwin' ROXIOCENTRAL = 'C:\Program Files\Common Files\Roxio Shared\10.0\Roxio Central36\' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' WINDIR = 'C:\WINDOWS' EMC_AUTOPLAY = 'C:\Program Files\Common Files\Roxio Shared\' TVTPYDIR = 'C:\Program Files\Common Files\Lenovo\Python24' TVT = 'C:\Program Files\Lenovo' OLDPWD = '/usr/bin' USERDOMAIN = 'BEVO' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' VS90COMNTOOLS = 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' TEMP = '/cygdrive/c/DOCUME~1/Pete/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' QTJAVA = 'C:\Program Files\Java\jre7\lib\ext\QTJava.zip' USERNAME = 'Pete' PROCESSOR_LEVEL = '6' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\Pete' CLIENTNAME = 'Console' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\BEVO' PROCESSOR_ARCHITECTURE = 'x86' !C: = 'C:\cygwin\bin' SWSHARE = 'C:\SWSHARE' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOCUME~1/Pete/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PYTHONPATH = 'C:\Python26\Lib;' PRINTER = 'Canon MP800 Series Printer' CVS_RSH = '/bin/ssh' WINEYES = 'C:\Program Files\GW Micro\Window-Eyes' PROCESSOR_REVISION = '170a' CLASSPATH = '.;C:\Program Files\Java\jre7\lib\ext\QTJava.zip' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' TPCCOMMON = 'C:\PROGRA~1\THINKV~1\PrdCtr' SESSIONNAME = 'Console' COMPUTERNAME = 'BEVO' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive'
