Re: new package: mined text editor
Christopher Faylor wrote: On Fri, Feb 11, 2005 at 02:31:07AM +0100, Gerrit P. Haase wrote: [EMAIL PROTECTED] wrote: If I remember correctly, I would have to wait until the package shows up in the distribution (being uploaded by you or some other kind maintainer) and then send a message to cygwin-announce, right? Uploaded. I removed the '@ mined' line from the setup.hint;) And, in the interests of space, I removed the 70 extra lines of inappropriate text from ldesc. This field isn't supposed to be an advertisement for the package it is supposed to be a more verbose description. I had no idea it was this big that when someone complained about the length of this field. Does this also resolve the download problem reported on the main leist? Gerrit -- =^..^=
Re: new package: mined text editor
On Thu, Feb 10, 2005 at 04:10:43PM -0500, Christopher Faylor wrote: If I remember correctly, I would have to wait until the package shows up in the distribution (being uploaded by you or some other kind maintainer) and then send a message to cygwin-announce, right? No. You send a message after the package has been confirmed as uploaded. There is no reason to wait. Just make sure your release announce language mentions that it will be uploaded to a mirror soon. I think it is better to do these things as soon as possible, otherwise experience has shown that people forget. Still waiting for that announcement... Btw, Thomas, I notice that you are not subscribed to cygwin-apps. Subscription to this mailing list is a requirement for package maintainers. Hopefully you are reading this through gmane maybe? cgf
nfs server config
hi i have this configuration $ cygcheck.exe -cd Cygwin Package Information Package Version _update-info-dir 00231-1 ash 20040127-1 base-files 3.2-1 base-passwd 2.1-1 bash 2.05b-16 bzip21.0.2-6 coreutils5.2.1-5 cygrunsrv1.0-1 cygutils 1.2.6-1 cygwin 1.5.12-1 cygwin-doc 1.4-1 diffutils2.8.7-1 editrights 1.01-1 findutils20041227-1 gawk 3.1.4-3 gdbm 1.8.3-7 grep 2.5-1 groff1.18.1-2 gzip 1.3.5-1 less 381-1 libbz2_1 1.0.2-6 libcharset1 1.9.2-1 libgdbm 1.8.0-5 libgdbm-devel1.8.3-7 libgdbm3 1.8.3-3 libgdbm4 1.8.3-7 libiconv 1.9.2-1 libiconv21.9.2-1 libintl1 0.10.40-1 libintl2 0.12.1-3 libintl3 0.14.1-1 libncurses5 5.2-1 libncurses6 5.2-8 libncurses7 5.3-4 libncurses8 5.4-1 libpcre 4.1-1 libpcre0 4.5-1 libpopt0 1.6.4-4 libreadline4 4.1-2 libreadline5 4.3-5 libreadline6 5.0-1 login1.9-7 man 1.5o1-1 mktemp 1.5-3 ncurses 5.4-1 nfs-server 2.2.47-2 readline 5.0-1 sed 4.1.3-1 sunrpc 4.0-2 tar 1.13.25-5 termcap 20021106-2 terminfo 5.4_20041009-1 texinfo 4.7-2 unzip5.50-5 vim 6.3-1 which1.6-1 zip 2.3-6 zlib 1.2.2-1 and we i use the command nfs-server-config i have this problem $ nfs-server-config Installing portmap as 'Cygwin portmap' Installing mountd as 'Cygwin mountd' Installing nfsd as 'Cygwin nfsd' mount(1) command did not return SYSTEM mount(s). It looks like you have installed Cygwin for a single user. Cygwin mount points will not be available to programs installed as Windows services. This will keep portmap, mountd, and nfsd from running as Windows services. In order for portmap, mountd and nfsd to function properly, you should establish global mount points using the /bin/mount utility. You can change user-specific Cygwin mount points to global mount points using the following command: eval mount -f -s -b C:/cygwin/bin /usr/bin; mount -f -s -b C:/cygwin/lib /usr/lib; mount -f -s -b C:/cygwin /; mount -s -b --change-cygdrive-prefix /cygdrive; You current mount -m listing is: mount -f -s -b C:/cygwin/bin /usr/bin mount -f -s -b C:/cygwin/lib /usr/lib mount -f -s -b C:/cygwin / mount -s -b --change-cygdrive-prefix /cygdrive pls help me bye luca
Need more documentation
I was wondering if there is any document available about how data is managed on the client side and on the server side. I want to know what exactly is done on each side and what is sent to the other. Maybe a kind of flowchart... Thanks Frédéric Paquet CMC Electronics www.cmcelectronics.ca
Re: MRXVT
Maybe you meant 03.10 Nappi Chris-ra5809 wrote: Unfortunately it appears I spoke too soon - while version .03.13 compiles, it doesn't seem to like to make new tabs (x-server error). .03.00 does work... Regards, Chris -Original Message- From: Nappi Chris-ra5809 Sent: Thursday, February 10, 2005 9:00 AM To: 'cygwin-xfree@cygwin.com' Subject: MRXVT FYI, After a number of versions that did not build easily under Cygwin, the latest MRXVT (tabbed RXVT) compiles out of the box. Home page: http://materm.sourceforge.net/ Version verified to compile: 0.3.13 Regards, Chris Nappi
Re: Need more documentation
I was wondering if there is any document available about how data is managed on the client side and on the server side. I want to know what exactly is done on each side and what is sent to the other. Maybe a kind of flowchart... client and server side of what? cygwin? X-windows?
Re: Need more documentation
http://www.x.org/download.cgi?rel=6.8.2 - Original Message - From: Paquet-Roy, Frederik [EMAIL PROTECTED] To: cygwin-xfree@cygwin.com Sent: Friday, February 11, 2005 1:28 PM Subject: Need more documentation I was wondering if there is any document available about how data is managed on the client side and on the server side. I want to know what exactly is done on each side and what is sent to the other. Maybe a kind of flowchart... Thanks Frédéric Paquet CMC Electronics www.cmcelectronics.ca
src/winsup/cygwin ChangeLog times.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-11 14:27:37 Modified files: winsup/cygwin : ChangeLog times.cc Log message: * times.cc (utimes): Open files with GENERIC_WRITE on file systems not supporting ACLs. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2708r2=1.2709 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.57r2=1.58
winsup/cygwin ChangeLog cygthread.cc fhandler. ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: [EMAIL PROTECTED] 2005-02-11 15:24:15 Modified files: cygwin : ChangeLog cygthread.cc fhandler.cc pinfo.cc pinfo.h pipe.cc sigproc.h spawn.cc Log message: * cygthread.cc (cygthread::release): Reset ev here if it exists. (cygthread::terminate_thread): Eliminat racy code which reset ev and thread_sync. Remove a few nonsensical inuse checks. Exit at the bottom. (cygthread::detach): Rewrite to again try to ensure that we don't say we're signalled when we are not signalled. * fhandler.cc (fhandler_base::raw_read): Revert to signalling read success quickly. * pipe.cc (fhandler_pipe::close): Use base method to close handle. * sigproc.h (WAIT_SIG_PRIORITY): Just trundle along at normal priority to allow the pipe thread to do its thing if possible. * pinfo.h (pinfo::zap_cwd): Declare new function. (pinfo::zap_cwd): Move 'cd out of the way code' here. (pinfo::exit): Use it here. * spawn.cc (spawn_guts): And here. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.2709r2=1.2710 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/cygthread.cc.diff?cvsroot=uberbaumr1=1.58r2=1.59 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler.cc.diff?cvsroot=uberbaumr1=1.218r2=1.219 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.cc.diff?cvsroot=uberbaumr1=1.161r2=1.162 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pinfo.h.diff?cvsroot=uberbaumr1=1.81r2=1.82 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/pipe.cc.diff?cvsroot=uberbaumr1=1.73r2=1.74 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.h.diff?cvsroot=uberbaumr1=1.73r2=1.74 http://sources.redhat.com/cgi-bin/cvsweb.cgi/winsup/cygwin/spawn.cc.diff?cvsroot=uberbaumr1=1.165r2=1.166
src/winsup/cygwin ChangeLog fhandler.cc fhandl ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-02-11 15:37:26 Modified files: winsup/cygwin : ChangeLog fhandler.cc fhandler.h fhandler_disk_file.cc Log message: * fhandler.cc (fhandler_base::raw_write): Mark as changed on successful write. * fhandler.h (fhandler_base::status_flags): Add 'has_changed' flag. * fhandler_disk_file.cc (fhandler_disk_file::fchmod): Call fhandler_disk_file's own open and close instead of open_fs and close_fs. Mark as changed on success. (fhandler_disk_file::fchown): Ditto. (fhandler_disk_file::facl): Ditto. (fhandler_disk_file::ftruncate): Ditto. (fhandler_base::open_fs): Mark as changed when O_TRUNC flag on existing file is set. (fhandler_disk_file::close): Set st_ctime if has_changed flag is set. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.2710r2=1.2711 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.219r2=1.220 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.219r2=1.220 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.100r2=1.101
Re: patch to allow touch to work on HPFS (and others, maybe??)
On Feb 10 23:43, Eric Blake wrote:
Corinna Vinschen vinschen at redhat.com writes:
Anyway, can you please test on both drives how they behave if utime
uses FILE_WRITE_ATTRIBUTES vs. GENERIC_WRITE?
Well, that was my first time ever building cygwin1.dll, but it went smoothly.
As requested, I tested utimes() when opening with just FILE_WRITE_ATTRIBUTES
and with full-blown GENERIC_WRITE, on both the ClearCase and the NFS mounted
drives. In all four cases, touch(1), which boils down to utimes(2), was able
to modify all three file times for a file, but returned success without
budging
any of the times on a directory.
That could be a result of the Cygwin internals. I assume that the
CreateFile call requesting any write access fails on both filesystems.
If you have a look into utimes, you see that Cygwin ignores this case:
h = CreateFile()
if ((h == INVALID_HANDLE_VALUE)
if (win32.isdir ())
{
/* What we can do with directories more? */
res = 0;
}
[...]
Can you add a __seterrno () before the `res = 0;' line and see what
Win32 error is produced by CreateFile (*iff* my assumption is correct)?
The expected result would be that the clearcase volume chokes with
FILE_WRITE_ATTRIBUTES while the Solaris FS should work with it.
Otherwise we're sort of doomed.
Then we're doomed (but was that ever a surprise from Windows? :)
I guess trying my approach isn't the worst one, though. We should
use that as a start point for further experimenting, IMHO. I'll check
that in.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:cygwin@cygwin.com
Red Hat, Inc.
More: setup.exe timestamp 1108087248: mined-2000.10-1: minor glitch
There is an intrusive blank line in the entry for mined-2000.10-1 in setup.ini timestamp 1108087248, preventing its download and installation. No, sorry, I'm talking rubbish I think, there are other mid-entry blank lines in setup.ini. But something meant that the files mined* didn't come down the line, even though they were referenced in setup.ini and seemed to be there on the mirror. (I could wget them.) Removing the blank line seemed to do the trick, for me. More likely just a temporary transmission glitch with a spurious solution. Sorry guys. Fergus -- 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: rsh command gives: rlogin: read: Operation not permitted
CYGWIN_NT-5.0 1.5.5(0.94/3/2) (g1gpv0j) (tty0) ^^ This says you're using using Cygwin DLL version 1.5.5. The current version is 1.5.12. Please upgrade and try again. This is the login prompt of my laptop I try to connect to and not the version of client PC a try to connect from. I want to connect to one of our AIX servers. I only test to connect to my laptop to prove the problem has nothing to do with the AIX servers I try to connect. I get the same rlogin: read: Operation not permitted error message when I try to connect to AIX or to my laptop On the PC from where I try to connect I tried with installing the new 2.457.2.1 version and installing the older 2.416 version. When I connect from my laptop to the AIX machine it works OK. When I copy the complete cygwin directory from my laptop to the desktop I also get the rlogin: read: Operation not permitted. So the problem must be the desktop. Maybe it is something with permissions on the desktop ?? Regards Adrie van Kouteren --- Adrie van Kouteren EMAIL : [EMAIL PROTECTED] [EMAIL PROTECTED] GSM : 06 - 55.38.05.64 Oracle DBA Professional Services Getronics Nederland B.V. Bakenmonde 1 Postbus 1218 3430 BE Nieuwegein Tel.:030 212 5221 --- Van: Larry Hall [mailto:[EMAIL PROTECTED] Verzonden: do 10-2-2005 17:47 Aan: Kouteren, Adrie van; cygwin@cygwin.com Onderwerp: Re: rsh command gives: rlogin: read: Operation not permitted At 06:43 AM 2/10/2005, you wrote: I installed cygwin on a Windows 2000 Service Pack 3 PC on my work. Installation is OK, but when a try to do a rsh hostname I always get: rlogin: read: Operation not permitted I get this when I try to connect to one of the AIX machines, but also when I try to connect to my laptop. When I do a telnet it works ok and I get for example: CYGWIN_NT-5.0 1.5.5(0.94/3/2) (g1gpv0j) (tty0) ^^ This says you're using using Cygwin DLL version 1.5.5. The current version is 1.5.12. Please upgrade and try again. login: When I try the same from my laptop it works OK. I tried: - installing version 2.457.2.1 - isntalling version 2.416 These are the version numbers for the setup program. They tell us nothing about the version of Cygwin you have installed, the packages you have, or their versions. -copying the working installed version from my laptop but always the same problem. Anyone any idea ?? Sure. If the above suggestion doesn't help, please read and carefully follow the guidelines at http://cygwin.com/problems.html. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746
Re: more ctime bugs
Eric, On Feb 9 21:27, [EMAIL PROTECTED] wrote: Corinna, since you've been fixing so many ctime bugs lately to match SUSv3 and POSIX, could you also fix open(2) when O_TRUNC is set, and write(2) and link(2) in general, to touch ctime? No problem with open and link, but I'm a bit reluctant to do this in write. Setting the file time on each WriteFile looks like a pretty time consuming operation, so I'm a bit in doubt if every write operation should be slowed down by this, POSIX compatibility or not. Wouldn't it help in most cases, if the close after write sets the ctime? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: ATT ksh93
Glenn, On Feb 9 16:25, Glenn Fowler wrote: On Wed, 9 Feb 2005 19:01:58 +0100 Corinna Vinschen wrote: I don't understand your problem with being Cygwin maintainer for this package if you patch and build it anyway. The maintenance effort besides building and packing looks pretty small to me. Package specific questions on the Cygwin ML are not going into the millions or so. Well, except for coreutils, perhaps :-) From past experience I don't want to be a point of contact for the cygwin mailing lists. Hmm, I have no idea what the problem was you had, but well, so be it. At that point I had already coded the cygwin system call intercepts and ksh93 and all of the other ast section 1 commands and scripts were running. So we decided to move on to other (non-cygwin) stuff. http://www.research.att.com/sw/download/win32/ As far as the win32 url being insulting to cygwin: if there is anything technically wrong please point it out and I'll correct it. Otherwise its pretty much a statement of fact. cygwin and UWIN make choices That's the problem. It's not the problem that you're pointing out potential bugs in Cygwin, or if it's technical correct or incorrect. It's that you're pointing them out on some web page but don't inform us. The same situation is if I find potential bugs in ksh but decide not to tell you about them, but instead put them on some Cygwin web page. Whom does that help? Definitely not the ksh users, right? But of course it's your choice. I don't have to like it. I would rather appreciate an open discussion on cygwin-patches (including patches, maybe) or even on cygwin-developers, though. I stay on the user side of OS API's to maintain hacking sanity. I'll be happy to discuss details of the workarounds cited in the win32 url above. I would rather like to discuss them in the usual way. You write a mail to the Cygwin list describing a problem, then I flame you. No, that's not quite right. I'll look into it and we discuss this. Yes, that sounds better. You might have seen the coreutils discussions and the perfect reports and testcases from Eric Blake. That's the best way to get problems fixed. Of course, that implies that you're interested in getting Cygwin fixed and so to reduce the need for the system call intercepts. For a start, I have one problem with your implementation. I don't think it's appropriate for the shell to rename files on the fly, just because the .exe suffix is missing, see your descriptions of chmod(2) and creat(2). One hack deserves another. How appropriate is it for cc -o t t.o to create t.exe instead of t? By not handling this at the system call level every script and application must be patched to handle .exe or not .exe. Doing it in one spot allows ksh93 users to forget they're on a windows system -- that's my measure of ultimate correctness. I see your point exactly. I'm far from being happy about the .exe handling in Cygwin but nevertheless, I'm wondering if it's appropriate for ksh to do it's own thing here. Regardless if the .exe handling is good or bad in Cygwin, I think that ksh should not behave very different from other shells running on Cygwin. What you do is a nice idea, but the difference would be surprising in a Cygwin environment. If I understand your change right, the following: $ cat foo.exe bar would create a file bar.exe in ksh, but it would create a file bar in ash, bash, tcsh, and zsh. Do you see my point? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Building Perl modules
Attached is my output of cygcheck -s -r -v. Gerrit, was there something in particular that you wanted to point out to me regarding http://cygwin.com/problems.html? Thanks, Alejandro Cygwin Configuration Diagnostics Current System Time: Fri Feb 11 08:25:18 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\Program Files\Documentum\Shared c:\Sun\AppServer\jdk\bin c:\OraHome1\bin c:\Program Files\Oracle\jre\1.1.8\bin c:\Program Files\Oracle\jre\1.3.1\bin c:\Perl\bin\ c:\WINNT\system32 c:\WINNT c:\WINNT\System32\Wbem c:\Program Files\PC-Doctor for Windows\services c:\bin c:\Program Files\Microsoft SQL Server\80\Tools\BINN c:\Program Files\NUnit V2.1\bin c:\Vim\Vim63 C:\cygwin\bin c:\Vim\vimfiles\vimdebug c:\bea\jdk142_05\lib c:\bea\jdk142_05\jre\bin c:\apache-ant-1.6.2\bin c:\Python23 c:\MinGW\bin c:\src\ c:\nant-0.84\bin\ c:\Sun\AppServer\bin C:\cygwin\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 17680(acalbaza)GID: 10545(mkgroup-l-d) 10545(mkgroup-l-d) Output from C:\cygwin\bin\id.exe (ntsec) UID: 17680(acalbaza)GID: 10545(mkgroup-l-d) 0(root) 544(Administrators) 545(Users) 1004(Debugger Users)10545(mkgroup-l-d) SysDir: C:\WINNT\system32 WinDir: C:\WINNT CYGWIN = `ntsec tty' HOME = `C:\cygwin\home\acalbaza' MAKE_MODE = `unix' PWD = `/home/acalbaza' USER = `acalbaza' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' ANT_HOME = `C:\apache-ant-1.6.2' APPDATA = `C:\Documents and Settings\acalbaza\Application Data' CLASSPATH = `C:\Program Files\Documentum\dctm.jar;C:\Documentum\config;.;C:\xerces-2_6_2\xercesImpl.jar;%JAVAFT_HOME%;C:\logging-log4j-1.2.9\dist\lib\log4j-1.2.9.jar;C:\EDIReader\EDIReader.jar' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `ACALBAZA1-LAP' COMSPEC = `C:\WINNT\system32\cmd.exe' CVSROOT = `' CVS_RSH = `/bin/ssh' EDIREADER_HOME = `C:\EDIReader\EDIReader.jar' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\acalbaza' HOSTNAME = `acalbaza1-lap' INCLUDE = `c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' JAVA_DOCPATH = `C:\bea\jdk142_05\docs' JAVA_HOME = `C:\bea\jdk142_05' LIB = `c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' LOG4J_HOME = `C:\logging-log4j-1.2.9\dist\lib\log4j-1.2.9.jar' LOGONSERVER = `\\ACALBAZA1-LAP' MACHINETYPE = `Local' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' MA_AGENT = `c:\PROGRA~1\MOBILE~1\rstate.exe' MINGW_HOME = `C:\MinGW\bin' NANT_HOME = `C:\nant-0.84\bin\' NUMBER_OF_PROCESSORS = `1' NUNIT_HOME = `C:\Program Files\NUnit V2.1\bin' OLDPWD = `/cygdrive/c/Documents and Settings/acalbaza' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PRINTER = `Local Postscript Printer' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 13 Stepping 6, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0d06' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' PYTHON_HOME = `C:\Python23' SHLVL = `1' SRC_HOME = `C:\src\' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `c:\DOCUME~1\acalbaza\LOCALS~1\Temp' TERM = `xterm' TMP = `c:\DOCUME~1\acalbaza\LOCALS~1\Temp' USERDNSDOMAIN = `cscinfo.com' USERDOMAIN = `CSCINFO' USERNAME = `acalbaza' USERPROFILE = `C:\Documents and Settings\acalbaza' VIM_DEBUG_HOME = `C:\Vim\vimfiles\vimdebug' VIM_HOME = `C:\Vim\Vim63' VS71COMNTOOLS = `c:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' WF_RESOURCES = `C:\OraHome1\WF\RES\WFus.RES' WINDIR = `C:\WINNT' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' 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' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 30513Mb 58% CP CS UN PA FC
RE: more ctime bugs
-Original Message- From: cygwin-owner On Behalf Of Corinna Vinschen Sent: 11 February 2005 09:35 On Feb 9 21:27, ericblake wrote: Corinna, since you've been fixing so many ctime bugs lately to match SUSv3 and POSIX, could you also fix open(2) when O_TRUNC is set, and write(2) and link(2) in general, to touch ctime? No problem with open and link, but I'm a bit reluctant to do this in write. Setting the file time on each WriteFile looks like a pretty time consuming operation, so I'm a bit in doubt if every write operation should be slowed down by this, POSIX compatibility or not. Wouldn't it help in most cases, if the close after write sets the ctime? Explicitly permitted, the way I read SuS: http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_07 snip! Each function or utility in IEEE Std 1003.1-2001 that reads or writes data or changes file status indicates which of the appropriate time-related fields shall be marked for update. [ ... ] An implementation may update fields that are marked for update immediately, or it may update such fields periodically. At an update point in time, any marked fields shall be set to the current time and the update marks shall be cleared. All fields that are marked for update shall be updated when the file ceases to be open by any process, or when a stat(), fstat(), or lstat() is performed on the file. Other times at which updates are done are unspecified. snip! So you clearly MUST update it when the file closes, and it's really up to you whether you want to say that the periodic updates are done once every say hundred million years or so nobody'll notice if you just don't implement them at that interval! cheers, DaveK -- Can't think of a witty .sigline today -- 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: more ctime bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 2/11/2005 2:35 AM: No problem with open and link, but I'm a bit reluctant to do this in write. Setting the file time on each WriteFile looks like a pretty time consuming operation, so I'm a bit in doubt if every write operation should be slowed down by this, POSIX compatibility or not. Wouldn't it help in most cases, if the close after write sets the ctime? That idea is close to what I had in mind. Note that POSIX wording in 4.7 for updating file times, http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html: An implementation may update fields that are marked for update immediately, or it may update such fields periodically. At an update point in time, any marked fields shall be set to the current time and the update marks shall be cleared. All fields that are marked for update shall be updated when the file ceases to be open by any process, or when a stat(), fstat(), or lstat() is performed on the file. Other times at which updates are done are unspecified. Marks for update, and updates themselves, are not done for files on read-only file systems; see Read-Only File System. There is no minimum time specified for the periodic updates, and not even a requirement that a second process be able to see the updates while the first process still has the file open and is updating it if the second process does not stat that file. It is more a requirement that once a file is changed, stat provides a synchronization point where all processes can detect that the file has changed. I really do think that a smarter and faster implementation, that still complies with POSIX, is to track that atime, mtime, and ctime need updates as part of the file descriptor, and to not call the Windows SetFileTimes except as part of utimes (because atime and mtime need not be set to 'now'), and in the stat family and close (but only if the atime, mtime, or ctime bits had been set). Then chown, truncate, link, write, and so forth, just need to set the appropriate time-needs-updating bits to let stat/close do the actual work, saving all the Windows system calls in the meantime. In fact, since Windows already seems to do a good job of keeping atime and mtime up-to-date, you may only need cygwin to cache just a ctime-needs-updating bit. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCDLzm84KuGfSFAYARAo6EAJ9rLGIROa6E9DGFjnaOMQogwDPH+QCfZFmo xc6CO7xt7ld2lMCIzKDT1H4= =+k5i -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: more ctime bugs
-Original Message- From: cygwin-owner On Behalf Of Eric Blake Sent: 11 February 2005 14:11 That idea is close to what I had in mind. Note that POSIX wording in 4.7 for updating file times, http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_cha p04.html: There is no minimum time specified for the periodic updates, LOL, is there an echo in here? cheers, DaveK -- Can't think of a witty .sigline today -- 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: more ctime bugs
On Feb 11 07:10, Eric Blake wrote: According to Corinna Vinschen on 2/11/2005 2:35 AM: No problem with open and link, but I'm a bit reluctant to do this in write. Setting the file time on each WriteFile looks like a pretty time consuming operation, so I'm a bit in doubt if every write operation should be slowed down by this, POSIX compatibility or not. Wouldn't it help in most cases, if the close after write sets the ctime? That idea is close to what I had in mind. Note that POSIX wording in 4.7 for updating file times, http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html: An implementation may update fields that are marked for update immediately, or it may update such fields periodically. At an update point in time, any marked fields shall be set to the current time and the update marks shall be cleared. All fields that are marked for update shall be updated when the file ceases to be open by any process, or when a stat(), fstat(), or lstat() is performed on the file. Other times at which updates are done are unspecified. Marks for update, and updates themselves, are not done for files on read-only file systems; see Read-Only File System. There is no minimum time specified for the periodic updates, [...] Thanks to you and Dave, especially for quoting the above Open Group chapter. I'll update Cygwin to set ctime in close and link. Link is special since it doesn't involve using any explicit file descriptors, so it's a bit unclear where to set the flags inside Cygwin to get that right. Using close() seems a good way to have ctime set for write() as well as open(O_TRUNC). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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: setup.exe timestamp 1108087248: mined-2000.10-1: minor glitch
On Fri, Feb 11, 2005 at 06:28:50AM -, [EMAIL PROTECTED] wrote: There is an intrusive blank line in the entry for mined-2000.10-1 in setup.ini timestamp 1108087248, preventing its download and installation. What is your *exact* problem? If blank lines in an ldesc are causing a problem then this is a problem for GConf2, desktop-file-utils, gnome-keyring, TeXmacs, and a number of other packages. FWIW, I had no problems installing mined. 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/
Re: setup.exe timestamp 1108087248: mined-2000.10-1: minor glitch
What is your *exact* problem? I visited the Cygwin site www.cygwin.com/setup.exe (as one does) and trawled for updates. This was about 12 hours ago. There were none, apparently. But I observed that setup.ini stamped ..7248 (just as it is now, in fact) had altered since my previous visit, and not in a minor way: there was a new provision in the form of mined. I had asked for Install not Default and in the usual way of things this would have been identified and downloaded and installed. All I had was the new setup.ini. I looked at it (a) to see what was new (mined) and (b) what was odd or wrong, leading to this failure. All that I observed even moderately unexpected was the blank line in the middle of ldesc. I closed it, wget'd mined into my local resource, and again used setup.exe, using my setup.ini and my local resource. The new provision was identified and installed. I deduced, wrongly, that my editing tweak was what had mended things. I later observed (see More: at 09.02) that a blank line in ldesc does not uniquely characterise mined, and therefore that something else, maybe to do with the exact timing of my visit to the mirror, was the cause of the glitch. And at least one other person (you) has successfully installed mined by conventional means. Sorry to go on, wasting bandwidth and people's time. I took your question What is your *exact* problem as just that: a request to expand on the nature of the glitch and maybe muse on its causes. It struck me when reading your post that an alternative interpretation might easily be that it was not a generous and thoughtful invitation, but an irritated commentary on my capability and thinking. But you're not like that, so I replied in the way that I have. Fergus -- 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: setup.exe timestamp 1108087248: mined-2000.10-1: minor glitch
On Fri, Feb 11, 2005 at 06:54:53PM +, fergus wrote: What is your *exact* problem? I visited the Cygwin site www.cygwin.com/setup.exe (as one does) and trawled for updates. This was about 12 hours ago. There were none, apparently. But I observed that setup.ini stamped ..7248 (just as it is now, in fact) had altered since my previous visit, and not in a minor way: there was a new provision in the form of mined. I had asked for Install not Default and in the usual way of things this would have been identified and downloaded and installed. All I had was the new setup.ini. I looked at it (a) to see what was new (mined) and (b) what was odd or wrong, leading to this failure. All that I observed even moderately unexpected was the blank line in the middle of ldesc. I closed it, wget'd mined into my local resource, and again used setup.exe, using my setup.ini and my local resource. The new provision was identified and installed. I deduced, wrongly, that my editing tweak was what had mended things. I later observed (see More: at 09.02) that a blank line in ldesc does not uniquely characterise mined, and therefore that something else, maybe to do with the exact timing of my visit to the mirror, was the cause of the glitch. I think you're not quite getting the point here. Your original report contained your interpretation of a cause of a problem without any explanation about the actual problem. Here, you've gone into TMI mode. I think your problem can be summarized by saying When I ran setup.exe and chose, 'mined' did not get installed and I think it should have. A succinct description of the problem is all that's required. If you have a theory about what's causing the problem that's great too, but just including the theory without talking about the problem is usually just going to result in someone asking you to describe the problem. So, to cut down on bandwidth a problem report should always try to include a clear and succinct description of 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/
Re: An updated version of zsh (zsh-4.2.4-1)
On Fri, 11 Feb 2005, David Rayner wrote:
Peter
Hi David,
(I've cc: the list as this is relevent).
An updated version of zsh (zsh-4.2.4-1) has been released and should be
at a mirror near you real soon.
Peter (I don't seem to be able to post today)
On my Pc
echo $ZSH_VERSION
always revealed
4.2.0
Then I remembered I'd had this b4, I then used W-Explorer to copy
/usr/bin/zsh-4.2.4.exe to zsh.exe
I recall someone else reporting this before (with 4.0.7?), and I think it
had to do with symlinks, or perhaps breaking the original file hardlink.
You see, zsh.exe is a hardlink to zsh-X.Y.Z.exe. If you list the package
contents (via tar -tjvf) you'll see this:
hrwxr-xr-x doctor/None 0 2005-02-08 07:53:41 usr/bin/zsh.exe link to
usr/bin/zsh-4.2.4.exe
Now, it's possible to create a symlink for an existing file. Please
check that you don't have a symlink/short-cut for zsh (zsh.exe.lnk or
zsh.lnk). I'd recommend checking this from a DOS Prompt so nothing is
obscured. It's also possible that setup, when it removed the old
package, discovered that zsh.exe was no longer a hardlink and didn't
remove it, but that's just speculation on my part (haven't explored
setup's uninstall package logic lately :), but I seem to recall that if
you remove the package, then manually remove zsh.exe, zsh-X.Y.Z.exe and
libzsh-X.Y.Z.dll (if they are left over) that subsequent
install/uninstalls work as intended. Are you using NTFS or FAT for the
filesystem? As for my self, I've never been able to reproduce this, and
once the manual intervention is done it seems to solve the problem for
others.
Now I get
echo $ZSH_VERSION
4.2.4
ll zsh*
-rwxrwxrwx+ 1 davidr Users 7168 Feb 8 15:53 zsh-4.2.4.exe
-rwxrwxrwx+ 1 davidr None 7168 Feb 8 15:53 zsh.exe
-rwxrwxrwx+ 1 davidr Users 6656 Apr 9 2004 zshold.exe
I think that there's also some issue where, when zsh upgrades you don't
necessarily get any updated /etc/z* files, ie you
have to manually copy them across?!?
This has been addressed. As of 4.2.3 the package does proper
instatiation and removal of /etc/zprofile, using the same method that the
base-files package uses (via preremove and postinstall scripts which test
for changes in the profile before removing). Note that when upgrading
from a pre-4.2.3 version of zsh you will need to manually remove
/etc/zprofile before installing a 4.2.3 or later version to properly sync
things. This was vaguely alluded to in the announcement for 4.2.3.
I also recommend that if you have any customizations you'd like to keep
for shell startup that you either put them into one of the other global
startup scripts (/etc/{zshenv,zshrc,zlogin}) or put them into your
per-user startup scripts (~/.{zshenv,zprofile,zshrc,zlogin}) instead of
modifying /etc/zprofile.
--
Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED]
Cats are just autistic Dogs -- Dr. Tony Attwood
--
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: ATT ksh93
On Fri, 11 Feb 2005 11:21:07 +0100 Corinna Vinschen wrote: On Feb 9 16:25, Glenn Fowler wrote: On Wed, 9 Feb 2005 19:01:58 +0100 Corinna Vinschen wrote: I don't understand your problem with being Cygwin maintainer for this package if you patch and build it anyway. The maintenance effort besides building and packing looks pretty small to me. Package specific questions on the Cygwin ML are not going into the millions or so. Well, except for coreutils, perhaps :-) From past experience I don't want to be a point of contact for the cygwin mailing lists. Hmm, I have no idea what the problem was you had, but well, so be it. At that point I had already coded the cygwin system call intercepts and ksh93 and all of the other ast section 1 commands and scripts were running. So we decided to move on to other (non-cygwin) stuff. http://www.research.att.com/sw/download/win32/ As far as the win32 url being insulting to cygwin: if there is anything technically wrong please point it out and I'll correct it. Otherwise its pretty much a statement of fact. cygwin and UWIN make choices That's the problem. It's not the problem that you're pointing out potential bugs in Cygwin, or if it's technical correct or incorrect. It's that you're pointing them out on some web page but don't inform us. The same situation is if I find potential bugs in ksh but decide not to tell you about them, but instead put them on some Cygwin web page. Whom does that help? Definitely not the ksh users, right? been there, done that, informed, rejected, moved on google cygwin ksh fowler karsten site:cygwin.com there are 100's of messages in threads that go back to 2001-09 But of course it's your choice. I don't have to like it. I would rather appreciate an open discussion on cygwin-patches (including patches, maybe) or even on cygwin-developers, though. I stay on the user side of OS API's to maintain hacking sanity. I'll be happy to discuss details of the workarounds cited in the win32 url above. I would rather like to discuss them in the usual way. You write a mail to the Cygwin list describing a problem, then I flame you. No, that's not quite right. I'll look into it and we discuss this. Yes, that sounds better. That would be fine. You might have seen the coreutils discussions and the perfect reports and testcases from Eric Blake. That's the best way to get problems fixed. Of course, that implies that you're interested in getting Cygwin fixed and so to reduce the need for the system call intercepts. We had such interest way back. It was successfully quashed. We got our stuff working and moved on. For a start, I have one problem with your implementation. I don't think it's appropriate for the shell to rename files on the fly, just because the .exe suffix is missing, see your descriptions of chmod(2) and creat(2). One hack deserves another. How appropriate is it for cc -o t t.o to create t.exe instead of t? By not handling this at the system call level every script and application must be patched to handle .exe or not .exe. Doing it in one spot allows ksh93 users to forget they're on a windows system -- that's my measure of ultimate correctness. I see your point exactly. I'm far from being happy about the .exe handling in Cygwin but nevertheless, I'm wondering if it's appropriate for ksh to do it's own thing here. Regardless if the .exe handling is good or bad in Cygwin, I think that ksh should not behave very different from other shells running on Cygwin. What you do is a nice idea, but the difference would be surprising in a Cygwin environment. We are at cross purposes here. Your goal is to make all applications that run on cygwin act the same. The ast package goal (of which ksh is a part) is to make ast applications act the same on all platforms. If I understand your change right, the following: $ cat foo.exe bar would create a file bar.exe in ksh, but it would create a file bar in ash, bash, tcsh, and zsh. Do you see my point? No. For the creat() intercept the conditions are that the created file have exe magic *and* execute permission. However, if the ksh builtin chmod were in scope (see the cygwin package README) then a subsequent chmod +x bar would result in bar.exe. If the intercepts are done right application code won't even be aware of the underlying hackery. Its all there in the astksh-20050202-src.tar.bz2 cygwin source package: src/lib/libast/comp/omitted.c src/lib/libast/features/omitted These files could be the basis for further discussion w.r.t. ast vs. cygwin. features/omitted is an iffe script that probes the cygwin.dll features in question (.exe and a few others.) ... but the difference would be surprising in a Cygwin environment. From our experience the surprise would be that a unix shell script or makefile worked without change on a windows system.
Cannot download package CVS - bzip2 archive is broken
I cannot download the package CVS. The archives are broken, independent of the download site. There weren't any problems with other packages. A manual FTP download of the archives shows the same: Archives are broken since december. Has no one else encountered this problem? -- 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: rsh command gives: rlogin: read: Operation not permitted
At 04:29 AM 2/11/2005, you wrote: CYGWIN_NT-5.0 1.5.5(0.94/3/2) (g1gpv0j) (tty0) ^^ This says you're using using Cygwin DLL version 1.5.5. The current version is 1.5.12. Please upgrade and try again. This is the login prompt of my laptop I try to connect to and not the version of client PC a try to connect from. OK, I stand corrected. On the PC from where I try to connect I tried with installing the new 2.457.2.1 version and installing the older 2.416 version. Again, these are 'setup.exe' version numbers. They relate to the version of 'setup.exe' you're running. They don't say anything about the version of Cygwin packages you have installed. When I connect from my laptop to the AIX machine it works OK. When I copy the complete cygwin directory from my laptop to the desktop I also get the rlogin: read: Operation not permitted. So the problem must be the desktop. Maybe it is something with permissions on the desktop ?? Maybe. But no one here is going to be able to attempt to help with the information you've provided so far. Please follow the guidelines given at http://cygwin.com/problems.html with any subsequent posting to the list about this issue. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Cannot download package CVS - bzip2 archive is broken
[EMAIL PROTECTED] wrote: I cannot download the package CVS. The archives are broken, independent of the download site. There weren't any problems with other packages. A manual FTP download of the archives shows the same: Archives are broken since december. Has no one else encountered this problem? Works fine for me. I just downloaded http://mirrors.rcn.net/pub/sourceware/cygwin/release/cvs/cvs-1.11.17-1.tar.bz2 and http://mirrors.kernel.org/sources.redhat.com/cygwin/release/cvs/cvs-1.11.17-1.tar.bz2 and they both have md5sum 646638fb4267e9a330d4accdcb02f146, and appear to be valid .tar.bz2 files. That is the same md5sum as in the setup.ini on sources.redhat.com, so everything looks OK to me. 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/
cygheap version mismatch detected
I seem to have managed to completely crash my cygwin installation :o( After trying some of the recent snapshots I noticed KDE would not start. So I tried with different snapshots (including the original cygwin1.dll) a few times, rebooting and running rebaseall -v between tries. Now neither KDE nor XWin will start at all, instead I get the following message: C:\cygwin\usr\X11R6\bin\XWin.exe (2400): *** cygheap version mismatch detected - 0x6179/0x101. You have multiple copies of cygwin1.dll on your system. Search for cygwin1.dll using the Windows Start-Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. There are definitely no multiple copies of cygwin1.dll files on the system. I have renamed the other snapshots something_else._dll and searched through all disks just to make sure. I have restored the original cygwin1.dll, rebooted and run rebaseall -v (with no errors) any number of times but the results are still as above. Running from a dos window still works but that's about it. Cheers CV -- 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: [ANNOUNCEMENT] Updated: zsh-4.2.4-1
On Thu, 10 Feb 2005 19:35:19 +0100 (CET), wrote: An updated version of zsh (zsh-4.2.4-1) has been released and should be at a mirror near you real soon. Peter (I don't seem to be able to post today) On my Pc echo $ZSH_VERSION always revealed 4.2.0 Then I remembered I'd had this b4, I then used W-Explorer to copy /usr/bin/zsh-4.2.4.exe to zsh.exe Now I get echo $ZSH_VERSION 4.2.4 ll zsh* -rwxrwxrwx+ 1 davidr Users 7168 Feb 8 15:53 zsh-4.2.4.exe -rwxrwxrwx+ 1 davidr None 7168 Feb 8 15:53 zsh.exe -rwxrwxrwx+ 1 davidr Users 6656 Apr 9 2004 zshold.exe I think that there's also some issue where, when zsh upgrades you don't necessarily get any updated /etc/z* files, ie you have to manually copy them across?!? Can you clarify Thanks zzapper (vim, cygwin, wiki zsh) -- vim -c :%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg? http://www.vim.org/tips/tip.php?tip_id=305 Best of Vim Tips -- 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: scponly for chrooted sftp server in cygwin
I still get the following error during the make phase.
gcc -g -O2 -I. -I. -DHAVE_CONFIG_H
-DDEBUGFILE='/usr/local/etc/scponly/debuglev
el' -o helper.o -c helper.c
helper.c:174: warning: passing arg 1 of `strdup' makes pointer from
integer with
out a cast
helper.c:179: warning: passing arg 1 of `strcmp' makes pointer from
integer with
out a cast
So do I. I simply didnt mind.
During the install phase the script attempted to set some file permisissions
as follows:
${INSTALL} -o 0 -g 0 scponly ${bindir}/scponly
${INSTALL} -o 0 -g 0 -m 0644 scponly.8 ${mandir}/man8/scponly.8
${INSTALL} -o 0 -g 0 -m 0644 debuglevel ${DEBUGFILE}
This depends on your UID setup in /etc/passwd and /etc/group.
Ive best experiences giving UID 0 to root and GID 0 to the root group. If you
dont have any user or group with those UID/GID, the install call will fail.
I changed the make file to:
${INSTALL} -o SYSTEM -g SYSTEM scponly ${bindir}/scponly
${INSTALL} -o SYSTEM -g SYSTEM -m 0644 scponly.8
${mandir}/man8/scponly.8
${INSTALL} -o SYSTEM -g SYSTEM -m 0644 debuglevel ${DEBUGFILE}
And it worked fine.
That should be ok. Id prefer to have root/root as the owner, but SYSTEM should
work also.
I tried using the setup_chroot.sh script but could not get it to work. You
mentioned an alternative make tool for setting up chrooted users. Or
instructions on how to manually set it up.
To be honest, I didnt find it anymore. Maybe there was a much easier script
available with an earlier version of scponly or rssh.
However, you may setup you chroot cage on your own:
1) create a base folder (your new root) with the following subfolders
/cygdrive/c/temp/sftp:{528}:$ ls -R
.:
bin/ etc/ lib/ pub/ usr/
./bin:
chmod.exe*cygintl-1.dll* id.exe* pwd.exe*
chown.exe*cygintl-2.dll* ln.exe* rm.exe*
cygcrypto-0.9.7.dll* cygwin1.dll*ls.exe* rmdir.exe*
cygcrypto.dll*groups* mkdir.exe* scp.exe*
cygiconv-2.dll* groups.exe* mv.exe* sftp-server.exe*
./etc:
group* passwd*
./lib:
libcygwin.a*
./pub:
./usr:
The passwd and group in the chroot only need to contain the users who will use
the chroot. These files are not used for authentification, but only for UID/GID
to name mapping.
2) Setup chroot in your *regular* /etc/passwd for users to be chrooted
my_chr_user:unused_by_nt/2000/xp:2019:545:my_chr_user,U-WE4\my_chr_user,
S-1-5-21-zzz-xxx-yyy-2019:/root/path/of/chroot:/usr/sbin/scponlyc
3) You may need to rebuild scponlyc
The path setting for sftp-server needs to match your installation.
So if sftp-server.exe resides in the /bin folder in your chroot, you need to
setup config.h:
#define PROG_SFTP_SERVER /bin/sftp-server
When the user logs in, scponlyc chroots and start sftp-server afterwards.
I prefer a small shellscript using rsync to keep the files in my chroot up to
date when I update cygwin.
#!/bin/sh
rsync -ulpogtW --existing /bin/* /root/path/of/chroot/bin
rsync -ulpogtW --existing /usr/sbin/* /root/path/of/chroot/bin
rsync -ulpogtW --existing /usr/lib/* /root/path/of/chroot/lib
This script freshens already existing files in the chroot.
This should enable you to setup the chroot manually.
Regards,
Christian
--
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: [ANNOUNCEMENT] Updated: zsh-4.2.4-1
On Thu, 10 Feb 2005 19:35:19 +0100 (CET), wrote: An updated version of zsh (zsh-4.2.4-1) has been released and should be at a mirror near you real soon. Peter On my Pc echo $ZSH_VERSION always revealed 4.2.0 Then I remembered I'd had this b4, I then used W-Explorer to copy /usr/bin/zsh-4.2.4.exe to zsh.exe Now I get echo $ZSH_VERSION 4.2.4 ll zsh* -rwxrwxrwx+ 1 davidr Users 7168 Feb 8 15:53 zsh-4.2.4.exe -rwxrwxrwx+ 1 davidr None 7168 Feb 8 15:53 zsh.exe -rwxrwxrwx+ 1 davidr Users 6656 Apr 9 2004 zshold.exe I think that there's also some issue where, when zsh upgrades you don't necessarily get any updated /etc/z* files, ie you have to manually copy them across?!? Can you clarify Thanks zzapper (vim, cygwin, wiki zsh) -- vim -c :%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg? http://www.vim.org/tips/tip.php?tip_id=305 Best of Vim Tips -- 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: [ANNOUNCEMENT] Updated: zsh-4.2.4-1
On Thu, 10 Feb 2005 19:35:19 +0100 (CET), wrote: An updated version of zsh (zsh-4.2.4-1) has been released and should be at a mirror near you real soon. Peter On my Pc echo $ZSH_VERSION always revealed 4.2.0 Then I remembered I'd had this b4, I then used W-Explorer to copy /usr/bin/zsh-4.2.4.exe to zsh.exe Now I get echo $ZSH_VERSION 4.2.4 ll zsh* -rwxrwxrwx+ 1 davidr Users 7168 Feb 8 15:53 zsh-4.2.4.exe -rwxrwxrwx+ 1 davidr None 7168 Feb 8 15:53 zsh.exe -rwxrwxrwx+ 1 davidr Users 6656 Apr 9 2004 zshold.exe I think that there's also some issue where, when zsh upgrades you don't necessarily get any updated /etc/z* files, ie you have to manually copy them across?!? Can you clarify Thanks zzapper (vim, cygwin, wiki zsh) -- vim -c :%s%s*%CyrnfrTfcbafbeROenzSZbbyranne%|:%s)[R-T]) )Ig|:norm G1VGg? http://www.vim.org/tips/tip.php?tip_id=305 Best of Vim Tips -- 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: Building Perl modules
Alejandro Calbazana wrote: Attached is my output of cygcheck -s -r -v. I see nothing unusual besides the LIB environment setting which causes problems with perl frequently. Remove this from the cygwin environment: LIB = `c:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' $ unset LIB or with $export LIB= Gerrit, was there something in particular that you wanted to point out to me regarding http://cygwin.com/problems.html? No. Gerrit -- =^..^= -- 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/
