Re: autoconf and exeext behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Keith Moore on 12/16/2005 4:12 PM: > > That said, another possible solution would be to > rip out the lines mentioned above, and replace all > occurances of "exeext" with "EXEEXT" (the variable > set by the autoconf-generated magic). That sounds right to me. Use what autoconf has already provided, then you won't have to do platform-specific hacks that miss specific platforms like cygwin. > > I'll try to get the "most correct" solution pushed > upstream. If you ask me, the "most correct" solution is to have upstream use EXEEXT consistently. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpCCz84KuGfSFAYARAoKCAJ9+OG9KIb94s37F8LDfOSemlbAgUgCfaXhk ql+6MYKDKbkjIofVsU8a//Q= =7X45 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: recreate_mmaps_after_fork_failed errors post-11-30 snapshot
On Thu, Dec 15, 2005 at 02:45:59PM -0600, Van Sickle, Gary wrote: >In both cases tar *is* executed and works fine. Due to the Van Sickle >Exclusion Principle (a bug and a debugging tool capable of providing >insight into that bug cannot occupy the same hardware at the same >time), not running under strace brings the problem back, and I get the >following (i.e. Corinna's new error message): > >" >H:\>bash >bash-3.00$ tar --help > 5 [main] bash 4092 fhandler_dev_zero::fixup_mmap_after_fork: requested > 0x4D != 0x0 mem alloc base 0x4D, state 0x1000, size 20480, Win32 > error 487 >C:\cygwin\bin\bash.exe (4092): *** recreate_mmaps_after_fork_failed >Hangup >" How does the new snapshot look? Corinna and I were able to duplicate this previously but the new snapshot seems to have fixed the problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
STDOUT of non cygwin command lost (in automated ssh session)
background (why plink is used): We have a wrapper script that runs plink to start a localhost ssh session w/password authentication. This wrapper script is designed to run a command after the ssh login. (We also have a similar cygwin expect script.) The benefit- network drives are writable. These wrapper scripts are used in crontabs. The problem is not with these scripts problem: plink starts a local ssh session using password authentication just fine, and then passes in a command to run: "cmd /c bar.bat". Inside bar.bat are lines: "echo hi" and "netstat -n". The output of "netstat -n" is lost. (real problem is w/a command other than netstat.) failing test case, 20051214 snapshot: (output from netstat command is lost) ~ $ uname -a CYGWIN_NT-5.0 c7mkes108 1.5.19s(0.148/4/2) 20051214 14:58:27 i686 unknown unknown Cygwin ~ $ plink -l scmcron -ssh -pw 'MYPASSWORDHERE' localhost 'export PATH="/bin:/usr/bin:$PATH";cd /tmp;set -x;cat bar.bat;cmd /c bar.bat' #end of plink command (sorry for long line) + cat bar.bat echo hi netstat -n + cmd /c bar.bat c:\aut\cyg\tmp>echo hi hi c:\aut\cyg\tmp>netstat -n ~ $ date # NEXT I TRY ADDING the -wait switch below: Sat Dec 17 11:13:07 CST 2005 ~ $ plink -l scmcron -ssh -pw 'MYPASSWORDHERE' localhost 'export PATH="/bin:/usr/bin:$PATH";cd /tmp;set -x;cat bar.bat;cmd -wait /c bar.bat' + cat bar.bat echo hi netstat -n + cmd -wait /c bar.bat c:\aut\cyg\tmp>echo hi hi c:\aut\cyg\tmp>netstat -n ~ $ # no joy working 20051029 snapshot: ~ $ uname -a CYGWIN_NT-5.0 c7mkes108 1.5.19s(0.141/4/2) 20051029 16:39:28 i686 unknown unknown Cygwin ~ $ plink -l scmcron -ssh -pw 'MYPASSWORDHERE' localhost 'export PATH="/bin:/usr/bin:$PATH";cd /tmp;set -x;cat bar.bat;cmd -wait /c bar.bat' #end of plink command (sorry for long line) + cat bar.bat echo hi netstat -n + cmd -wait /c bar.bat c:\aut\cyg\tmp>echo hi hi c:\aut\cyg\tmp>netstat -n Active Connections Proto Local Address Foreign AddressState TCP10.125.15.180:2210.222.10.182:46863 ESTABLISHED TCP10.125.15.180:445 10.125.15.191:3843 ESTABLISHED TCP10.125.15.180:445 10.125.15.192:2682 ESTABLISHED TCP10.125.15.180:1098 10.125.15.180:5413 ESTABLISHED TCP10.125.15.180:1104 10.125.15.180:5413 ESTABLISHED TCP10.125.15.180:1106 10.125.15.180:1339 ESTABLISHED TCP10.125.15.180:1106 10.125.15.180:1343 ESTABLISHED TCP10.125.15.180:1106 10.125.15.180:1367 ESTABLISHED --snip (it also works w/out the "-wait") -- Tom Rodman -- Cygwin Configuration Diagnostics Current System Time: Sat Dec 17 13:05:49 2005 Windows 2000 Advanced Server Ver 5.0 staffuser2 2195 Service Pack 4 Running in Terminal Service session Path: c:\aut\cyg\home\local\staffuser1\bin c:\aut\cyg\bin c:\aut\m c:\aut\ulb i:\tcm\adm\bin\sys i:\tcm\adm\bin\app c:\aut\cyg\contrib\bin c:\bcm63\bin c:\bcm63\jre\bin c:\bcm63\bin\util c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\Resource Kit\ c:\Program Files\Support Tools\ c:\PROGRA~1\BMCSOF~1\common\globalc\bin\Windows-x86 c:\Progra~1\tivoli\tsm\baclient c:\HPOV\bin c:\HPOV\bin\OpC .\ Output from c:\aut\cyg\bin\id.exe (nontsec) UID: 15773(staffuser1) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 10513(Domain Users) 16026(XYZ_ES_ADMIN) 16027(XYZ_ES_STAFF) 16024(XYZ_Users) 545(Users) Output from c:\aut\cyg\bin\id.exe (ntsec) UID: 15773(staffuser1) GID: 16027(XYZ_ES_STAFF) 544(Administrators) 10513(Domain Users) 16026(XYZ_ES_ADMIN) 16027(XYZ_ES_STAFF) 16024(XYZ_Users) 545(Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT USER = `staffuser1' PWD = `/usr/bin' CYGWIN = `binmode tty ntsec smbntsec' HOME = `/home/local/staffuser1' MAKE_MODE = `UNIX' rv = `/adm/backup/recovery' HOMEPATH = `\Documents and Settings\staffuser1' cfl = `/adm/sa/cfglog' MANPATH = `:/usr/ssl/man' APPDATA = `C:\Documents and Settings\staffuser1\Application Data' hostname = `OurServer108' D = `/drv' LCL_PATH_ADM = `i:/tcm' TERM = `cygwin' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel' DIRCMD = `/A' WINDIR = `C:\WINNT' TMPDIR = `/drv/c/TEMP' cu = `/adm/bin/cust' OLDPWD = `/home/local/staffuser1' USERDOMAIN = `DOMxx1\' OS = `Windows_NT' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' dc = `/adm/doc' BMC_GLOBALC_HOME = `c:\Program Files\BMC Software\common\globalc' XCM_MKEP01_DB = `\\OurServer108\bcmdb\xyzp01test' svars_bash_defined = `yes' PATH_ADM = `i:/tcm' OVDATADIR = `C:\HPOV\data\' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' BASH_BIN = `c:\aut\cyg\bin' http_proxy = `http://proxy.OurBiz.com:8080' rg = `C:\WINNT\system32\config' OVPERLLIB = `C:\HP
Re: STDOUT of non cygwin command lost (in automated ssh session)
On Sat, Dec 17, 2005 at 01:52:17PM -0600, Tom Rodman wrote: >background (why plink is used): > >We have a wrapper script that runs plink to start a localhost ssh >session w/password authentication. This wrapper script is designed to >run a command after the ssh login. (We also have a similar cygwin >expect script.) The benefit- network drives are writable. These >wrapper scripts are used in crontabs. The problem is not with these >scripts You seem to be expecting that the people whom you'd like to debug your problem would know what "plink" is. I can't speak for Corinna but, sadly, I don't. If you can't duplicate this problem with "off-the-shelf" components then I'm afraid I'm going to have to say "It's a plink problem". We sometimes have to make tradeoffs to achieve some benefits and maybe the fact that plink (whatever that is) screws up stdout in a cygwin is one of the tradeoffs. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
File permissions and ownership changes between Unix and Cygwin
I have been successful in using 'mkisofs' and 'cdrecord' (from Joerg Schilling)to burn CDs using Cygwin. One thing that is strange is the change in file permissions and ownership. I used 'chown' to (recursively) change the entire filesystem to be burned onto the CD so that the owner was 'SYSTEM'. I verified that this change was right. The group ownership was 'None' and I left that alone. But, when I run 'mkisofs' to create a raw image of the CD, I find (using 'filedisk' to mount the raw image) that the file ownership has been switched back to my Windows XP account name. The burned CD is, of course, the same. Also the permissions on the CD are set to 'rwxrwxrwx' even though this was not the case in the files on the hard disk. I understand that this is something to do with 'mkisofs', but I was wondering if there is a Cygwin trick that I am missing. I would like burn disks so that they have the right permissions and ownerships when used on a Unix/Linux machine. In particualar, I want 'r--r--r--' for the permissions and 'root' for owner and group. Any hints would be greatly appreciated. thanks sj __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: File permissions and ownership changes between Unix and Cygwin
surendar jeyadev wrote: > I understand that this is something to do with > 'mkisofs', > but I was wondering if there is a Cygwin trick that I > am missing. I would like burn disks so that they have > the right permissions and ownerships when used on a > Unix/Linux machine. In particualar, I want 'r--r--r--' > for the permissions and 'root' for owner and group. As far as I understand it, the basic ISO9660 format does not have any fields to store file attributes such as owner or permissions. So on mounting such a disc, Windows and/or Cygwin will have to synthesize these fields, which is probably why they are not set as you want. To enable storing of these attributes you need to use the Rock Ridge extension. When creating your image you will have to make sure that you enable these extensions (-R, -r, etc.) Although from the man page it looks like the author may be somewhat biased against win32: -R Generate SUSP and RR records using the Rock Ridge proto- col to further describe the files on the iso9660 filesystem. -r This is like the -R option, but file ownership and modes are set to more useful values. The uid and gid are set to zero, because they are usually only useful on the author's system, and not useful to the client. All the file read bits are set true, so that files and directo- ries are globally readable on the client. If any exe- cute bit is set for a file, set all of the execute bits, so that executables are globally executable on the client. If any search bit is set for a directory, set all of the search bits, so that directories are globally searchable on the client. All write bits are cleared, because the CD-Rom will be mounted read-only in any case. If any of the special mode bits are set, clear them, because file locks are not useful on a read-only file system, and set-id bits are not desirable for uid 0 or gid 0. When used on Win32, the execute bit is set on all files. This is a result of the lack of file permis- sions on Win32 and the Cygwin POSIX emulation layer. See also -uid -gid, -dir-mode, -file-mode and -new-dir-mode. I'm not sure what "This is a result of the lack of file permissions on Win32 and the Cygwin POSIX emulation layer" but it seems like some pretty thick ignorance, since that's the entire point of Cygwin. You should post your question on the cdrtools list or forum, since this is not a cygwin package. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: File permissions and ownership changes between Unix and Cygwin
Brian, --- Brian Dessent <[EMAIL PROTECTED]> wrote: > surendar jeyadev wrote: > As far as I understand it, the basic ISO9660 format > does not have any > fields to store file attributes such as owner or > permissions. So on > mounting such a disc, Windows and/or Cygwin will > have to synthesize > these fields, which is probably why they are not set > as you want. Ah! Never thought about the basic format . > To enable storing of these attributes you need to > use the Rock Ridge > extension. When creating your image you will have > to make sure that you > enable these extensions (-R, -r, etc.) Although I always, even on an Unix box, use the -R -J options when running mkisofs. The problem I mentioned occured with these options. But (as you say below) I need to explore the -r option, which I have not used so far. > from the man page it > looks like the author may be somewhat biased against > win32: Ah!! That is putting it mildly. Very mildly. (But then again I am probably in that camp though, certainly not so extreme). > When used on Win32, the > execute bit is set on > all files. This is a result of the > lack of file permis- > sions on Win32 and the Cygwin > POSIX emulation layer. > See also -uid -gid, -dir-mode, > -file-mode and > -new-dir-mode. I think that my answers will lie in these other options. I have not bothered with them so far. > I'm not sure what "This is a result of the lack of > file permissions on > Win32 and the Cygwin POSIX emulation layer" but it > seems like some > pretty thick ignorance, since that's the entire > point of Cygwin. I will leave you to spar with Joerg! I have my scars!! > You should post your question on the cdrtools list > or forum, since this > is not a cygwin package. I will try to find one Don't think that one exists. Thanks for the quick response. sj __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
