Re: updated: guile-1.6.7-1 and guile-1.7.2-1
On May 6 15:54, Jan Nieuwenhuizen wrote: I have prepared packages for new upstream guile releases. Guile 1.6.5 has known gc problems. Please also upload the hint files, so that 1.6.7-1 is [curr] and 1.7.2-1 is [test]. Uploaded. I've removed 1.6.4 and 1.7.1. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
Re: Setup - Hiding ZZZRemovedPackages?
Christopher Faylor wrote: How about if we just adopt a convention of making categories which begin with '_' invisible? We could move ZZZRemovedPackages to just _RemovedPackages for that case. Yes, please. I felt a little uncomfortable hardcoding the exclusion names. Brian
Re: updated: tetex-3.0.0-3
On May 6 11:08, Jan Nieuwenhuizen wrote: Please upload, and remove tetex-3.0.0-2, so that 3.0.0-3 enters the [curr] release, and tetex-2.0.2-15 remains available in [prev]. Uploaded and 3.0.0-2 removed. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc.
plea for better sdesc lines
This is a request to all package maintainers to please check your setup.hints for bogus 'sdesc' lines. As you know, this is the text that is displayed to the user when using setup. It should not begin with the name of the package, since setup displays it as $package: $sdesc. It should also be more descriptive than just the name of the package, because foo: Foo is almost useless to the user. Surely you can describe your package with a short phrase or sentence. I wrote a small script that tests for these things as well as packages that reference anything in ZZZRemovedPackages in their Requires. The output is below: GraphicsMagick: sdesc contains only name of package ImageMagick: sdesc contains only name of package WindowMaker: sdesc contains only name of package XmHTML: sdesc begins with name of package ddd: sdesc contains only name of package fvwm: sdesc contains only name of package lesstif: sdesc contains only name of package libsmi: sdesc contains only name of package man: sdesc begins with name of package nedit: sdesc contains only name of package openbox: sdesc contains only name of package opengl: sdesc begins with name of package postgresql: sdesc begins with name of package shutdown: sdesc begins with name of package tetex-x11: references removed package in 'requires' transfig: sdesc contains only name of package x2x: sdesc contains only name of package xfig: sdesc begins with name of package xfig-lib: sdesc begins with name of package xgraph: sdesc contains only name of package xterm: sdesc begins with name of package Brian
Re: Setup - Hiding ZZZRemovedPackages?
Brian Dessent wrote: Christopher Faylor wrote: How about if we just adopt a convention of making categories which begin with '_' invisible? We could move ZZZRemovedPackages to just _RemovedPackages for that case. Yes, please. I felt a little uncomfortable hardcoding the exclusion names. That would be a useful cleanup of the names, I think, but I don't mind hardcoding the names if it brings us an additional benefit... say, like auto-uninstalling anything in _RemovedPackages ? Max.
Re: plea for better sdesc lines
Lets see, GraphicsMagick, ImageMagick, WindowMaker, ddd, fvwm, lesstif, libsmi (was that me?), nedit, openbox, transfig, xfig, xfig-lib, xgraph (me???), and xterm. About 14 of 21. Wow, looks like I'm the number-one offender. ;) Harold Brian Dessent wrote: This is a request to all package maintainers to please check your setup.hints for bogus 'sdesc' lines. As you know, this is the text that is displayed to the user when using setup. It should not begin with the name of the package, since setup displays it as $package: $sdesc. It should also be more descriptive than just the name of the package, because foo: Foo is almost useless to the user. Surely you can describe your package with a short phrase or sentence. I wrote a small script that tests for these things as well as packages that reference anything in ZZZRemovedPackages in their Requires. The output is below: GraphicsMagick: sdesc contains only name of package ImageMagick: sdesc contains only name of package WindowMaker: sdesc contains only name of package XmHTML: sdesc begins with name of package ddd: sdesc contains only name of package fvwm: sdesc contains only name of package lesstif: sdesc contains only name of package libsmi: sdesc contains only name of package man: sdesc begins with name of package nedit: sdesc contains only name of package openbox: sdesc contains only name of package opengl: sdesc begins with name of package postgresql: sdesc begins with name of package shutdown: sdesc begins with name of package tetex-x11: references removed package in 'requires' transfig: sdesc contains only name of package x2x: sdesc contains only name of package xfig: sdesc begins with name of package xfig-lib: sdesc begins with name of package xgraph: sdesc contains only name of package xterm: sdesc begins with name of package Brian
RE: please test new setup
Only UI problem I saw was on the Choose a download site page: Add button overlaps the adjacent edit control. I think that's due to the theme and/or the button was too close before anyway. Oh, found another bullet item for you: - Get rid of the Installation complete dialog box. -- Gary R. Van Sickle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Friday, May 06, 2005 11:53 PM To: cygwin-apps@cygwin.com Subject: please test new setup http://cygwin.com/setup-snapshots/setup-2.497-alpha.exe I've committed support for tooltips in setup. I would appreciate any feedback on the wording of the text, the implementation, or reports of it not working with older versions of windows. For most things I use multiline tooltips. According to MSDN, this requires the common controls v4.70 or greater. This was first included with MS IE v3, so the only people that this would affect would be those people running windows 95 with IE 2.x. I can't possibly imagine that there are many people in that situation. Regardless, they should degrade gracefully (as in they just won't display) if that is the case. And the single-line tooltips would still work for them regardless. Currently, I have added multiline tooltips for the Keep, Prev, Curr, and Exp radio buttons as well as the View button on the package chooser screen. The text explains what the buttons do, more or less. The clickable hyperlinks also get single line tooltips that show their url. Here is an example: http://dessent.net/cygwin/setup-dialogs4.png Again, I'm looking for any kind of feedback about these new features: works/doesn't work, bad wording, UI comments, etc. http://cygwin.com/setup-snapshots/setup-2.497-alpha.exe Brian
Updated: lilypond-2.4.6-1
This is a main upstream release. Cygwin-related changes: libkpathsea4 and libintl3 dependency Please upload, keep lilypond-2.4.3-1 in [prev] Thank you, Bert http://web.interware.hu/fodber/lily/release/lilypond/setup.hint http://web.interware.hu/fodber/lily/release/lilypond/lilypond-2.4.6-1-src.tar.bz2 http://web.interware.hu/fodber/lily/release/lilypond/lilypond-2.4.6-1.tar.bz2 http://web.interware.hu/fodber/lily/release/lilypond/lilypond-doc/setup.hint http://web.interware.hu/fodber/lily/release/lilypond/lilypond-doc/lilypond-doc-2.4.6-1.tar.bz2
Re: Ready to begin release cycle?
Op Sat, 7 May 2005 23:21:31 +0100 schreef Max Bowsher in [EMAIL PROTECTED]: [...] : Any thoughts on anything additional which ought to go in before the branch? I sent this before... 2005-05-10 Bas van Gompel [EMAIL PROTECTED] * archive.cc (archive::extract_file): Use prefixPath for linktarget on hardlinks. diff -u -p -r2.11 archive.cc --- setup/archive.cc5 May 2005 22:48:34 - 2.11 +++ setup/archive.cc8 May 2005 18:40:31 - @@ -161,7 +161,7 @@ archive::extract_file (archive * source, io_stream::remove (destfilename); int ok = io_stream::mklink (destfilename, - prefixURL + source-linktarget (), + prefixURL + prefixPath + source-linktarget (), IO_STREAM_HARDLINK); /* FIXME: check what tar's filelength is set to for hardlinks */ source-skip_file (); L8r, Buzz. -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe s.u(z)\1.as.| me. 4^re
RE: Ready to begin release cycle?
Original Message From: Max Bowsher Sent: 07 May 2005 23:22 I believe I have now got the MD5 checking to behave in a sensible way. I'm inclined to make a release branch, to start the process of getting the nicer dialogs and proxy port fix into a release. Then, Brian can start using trunk to develop the new dependency logic. Any thoughts on anything additional which ought to go in before the branch? Max. Since the branch is going to happen before the dependency logic goes in, can I suggest you put my cygwin1-dll-last patch on the branch, since it will save at least a few people at least a medium amount of pain? We can always rip it out easily if we ever need rid of it. cheers, DaveK -- Can't think of a witty .sigline today
Re: Strange-Dangerous behaviour in Cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Carlo Florendo on 5/8/2005 9:30 PM:
Ooops. Sorry, I've read earlier discussions on this issue just a few
seconds ago by Erik Blake et al. So, it's not an xterm issue. It's a
I spell it Eric.
bug with coreutils not being POSIX compliant. A patch has been
applied. We just have to wait for the next annoucement for coreutils.
Hold on there - the bug in POSIX non-compliance was that before coreutils
patch, `rm -i' accepted y as yes, now CVS coreutils obeys POSIX and
interprets it as a match failure (which has the same effect as typing an
answer interpreted as no). Unfortunately, POSIX requires that if your
terminal settings are strange (such as the ctlecho settings that cgf
mentioned on linux), such that raw editing characters escape the terminal
into the program, that y\bn ('y', BACKSPACE, 'n') be interpreted as yes.
The only way this would be an xterm bug is if the default tty settings of
xterm under cygwin can be changed to improve user experience by making it
less likely that raw backspaces are passed through to the program, rather
than being line edited first.
And my next release of cygwin coreutils-5.3.0-6 will not be CVS coreutils
(with all its recent patches in many other areas as well), but stock 5.3.0
with a minimal subset of CVS patches backported as needed (I plan to wait
until 5.3.1 is released before cygwin officially sees all upstream patches
since 5.3.0, unless someone can convince me of a need for cygwin to track
CVS). That means I will not be changing the yes/no behavior in my next
drop of coreutils. But rest assured that I am tracking CVS changes on my
own machine, to try and make sure that there are no regressions introduced
when 5.3.1 is finally released upstream.
- --
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
iD8DBQFCf18n84KuGfSFAYARAliCAJ9LHbOYO3swwmsLrqlDff0KMyEY4ACeMzAI
x1/ti+7xCZub+fRYc0Kts6Q=
=wTHd
-END PGP SIGNATURE-
Re: Getting multiple lines Xlib: unexpected async reply (sequence 0xAdress)! when runnning startx
Vincenzo Daniele wrote: Xlib: unexpected async reply (sequence 0x1921)! Xlib: unexpected async reply (sequence 0x1923)! XIO: fatal IO error 0 (No error) on X server :0.0 after 111 requests (6436 known processed) with 0 events remaining. XIO: fatal IO error 0 (No error) on X server :0.0 after 7 requests (6 known processed) with 0 events remaining. This should never happen unless you have some network troubles. bye ago NP: SITD - Plastination City -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Unicode support in Cygwin 1.5.16 - Xorg 6.8.2.0
Hi, I'm trying to build a little test program to show unicode fonts in XWin, using LessTif. The code is from the Motif guide (see attached XTest.C). I'm building it with: g++ -I/usr/X11R6/include XTest.C -L/usr/X11R6/lib -lXm -lXt -lX11 The build gives me the following message: Info: resolving _sessionShellWidgetClass by linking to __imp__sessionShellWidgetClass (auto-import) Info: resolving __XmStrings by linking to __imp___XmStrings (auto-import) After that, when I run the executable, the application segfaults. I'm attaching the test program source code, the stack dump and the output of cygcheck. Thanks for your help. Giampaolo a.exe.stackdump XTest.C a.exe.stackdump Description: Binary data XTest.C Description: Binary data
RE: Unicode support in Cygwin 1.5.16 - Xorg 6.8.2.0
I forgot the cygcheck output. Sorry, here it is. cygcheck.out -Original Message- Subject: Unicode support in Cygwin 1.5.16 - Xorg 6.8.2.0 Hi, I'm trying to build a little test program to show unicode fonts in XWin, using LessTif. The code is from the Motif guide (see attached XTest.C). I'm building it with: g++ -I/usr/X11R6/include XTest.C -L/usr/X11R6/lib -lXm -lXt -lX11 The build gives me the following message: Info: resolving _sessionShellWidgetClass by linking to __imp__sessionShellWidgetClass (auto-import) Info: resolving __XmStrings by linking to __imp___XmStrings (auto-import) After that, when I run the executable, the application segfaults. I'm attaching the test program source code, the stack dump and the output of cygcheck. Thanks for your help. Giampaolo a.exe.stackdump XTest.C File: a.exe.stackdumpFile: XTest.C cygcheck.out Description: Binary data
src/winsup/mingw ChangeLog include/math.h ming ...
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2005-05-09 09:36:11 Modified files: winsup/mingw : ChangeLog winsup/mingw/include: math.h winsup/mingw/mingwex: Makefile.in winsup/mingw/mingwex/math: nextafterf.c Added files: winsup/mingw/mingwex/math: nextafterl.c Log message: * mingwex/math/nextafterf.c (nextafterf): Correct handling of -0.0. * mingwex/math/nextafterl.c: New file. * mingwex/Makefile.in (MATH_DISTFILES): Add nextafterl.c. (MATH_OBJS): Add nextafterl.o. * include/math.h (nextafterl): Uncomment prototype. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog.diff?cvsroot=srcr1=1.271r2=1.272 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/math.h.diff?cvsroot=srcr1=1.26r2=1.27 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/Makefile.in.diff?cvsroot=srcr1=1.27r2=1.28 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/nextafterl.c.diff?cvsroot=srcr1=NONEr2=1.1 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mingwex/math/nextafterf.c.diff?cvsroot=srcr1=1.1r2=1.2
Re: [Patch]: mkdir -p and network drives
Pierre A. Humblet pierre at phumblet.no-ip.org writes: Here is a patch to allow mkdir -p to easily work with network drives and to allow future enumeration of computers and of network drives by ls -l. It works by defining a new FH_NETDRIVE virtual handler for names such as // and //machine. This also makes chdir work without additional change. I've just downloaded the 20050508 snapshot to play with this, and it still needs some work before coreutils-5.3.0-6 can be released. But it is an improvement! First, `ls -ld // //machine' show that these directories are mode 111 (searchable, but not readable). Yet opendir(//) and opendir(//machine) succeed, although POSIX requires that opendir(2) fail with EACCESS if the directory to be opened is not readable. Second, the sequence chdir(//), mkdir(machine) creates machine in the current directory. $ cd //eblake/share $ ls $ ~/coreutils-cvs/src/mkdir -p //eblake/share/dir $ ls -F dir/ eblake/ share/ A relevant portion of the strace is included below. Basically, mkdir (//machine) (or chdir(//), mkdir(machine)) needs to fail with EEXIST (because it is always assumed that //machine already exists) or with EACCESS (because there is no write access in //), rather than create a directory by that name somewhere else. 69 4745479 [main] mkdir 10204 chdir: dir '//' 62 4745541 [main] mkdir 10204 normalize_posix_path: src // 66 4745607 [main] mkdir 10204 normalize_posix_path: // = normalize_posix_path (//) 62 4745669 [main] mkdir 10204 mount_info::conv_to_win32_path: conv_to_win32_p ath (//) 61 4745730 [main] mkdir 10204 set_flags: flags: binary (0x2) 74 4745804 [main] mkdir 10204 mount_info::conv_to_win32_path: src_path //, ds t \\, flags 0x2, rc 0 77 4745881 [main] mkdir 10204 build_fh_pc: fh 0x61831710 67 4745948 [main] mkdir 10204 chdir: 0 = chdir() cygheap-cwd.posix '//' nati ve '\\' 67 4746015 [main] mkdir 10204 normalize_posix_path: src eblake 61 4746076 [main] mkdir 10204 cwdstuff::get: posix // 60 4746136 [main] mkdir 10204 cwdstuff::get: (//) = cwdstuff::get (0x22EAC0, 260, 1, 0), errno 2 132 4746268 [main] mkdir 10204 normalize_posix_path: //eblake = normalize_posi x_path (eblake) 67 4746335 [main] mkdir 10204 mount_info::conv_to_win32_path: conv_to_win32_p ath (//eblake) 67 4746402 [main] mkdir 10204 set_flags: flags: binary (0x2) 61 4746463 [main] mkdir 10204 mount_info::conv_to_win32_path: src_path //ebla ke, dst \\eblake, flags 0x2, rc 0 64 4746527 [main] mkdir 10204 build_fh_pc: fh 0x61831710 68 4746595 [main] mkdir 10204 cwdstuff::get: posix // 72 4746667 [main] mkdir 10204 cwdstuff::get: (\\) = cwdstuff::get (0x22E4E0, 260, 0, 0), errno 2 1561 4748228 [main] mkdir 10204 mkdir: 0 = mkdir (eblake, 511)
RE: [Patch]: mkdir -p and network drives
Original Message From: Eric Blake Sent: 06 May 2005 23:29 Also, what should //.. resolve to, / or //? And if it resolves to /, should // be an entry in the readdir() of /? I would argue that //.. should resolve to //, meaning we just have two distinct roots in the directory tree. Wouldn't it work to just have a magic directory called '/' in the root dir, just like the other magic dirs 'dev' and 'proc'? Then it would be called '//', and it could have '.' and '..' entries just like '/dev' and '/proc' do. Well, like /proc does, anyway. cheers, DaveK -- Can't think of a witty .sigline today
Re: [Patch]: mkdir -p and network drives
At 06:19 PM 5/9/2005 +, Eric Blake wrote:
Second, the sequence chdir(//), mkdir(machine) creates machine in the
current directory.
Old bug.
chdir(/proc), mkdir(machine) produces the same result.
And mkdir(/proc), mkdir(/proc/machine) creates c:\proc\machine
The fix sets errno to EROFS, which is what rmdir is already doing.
Is that OK for coreutils?
Pierre
2005-05-10 Pierre Humblet [EMAIL PROTECTED]
* dir.cc (isrofs): New function.
(mkdir): Use isrofs.
(rmdir): Ditto.
Index: dir.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dir.cc,v
retrieving revision 1.84
diff -r1.84 dir.cc
218a219,225
inline bool
isrofs(DWORD devn)
{
return devn == FH_PROC || devn == FH_REGISTRY
|| devn == FH_PROCESS || devn == FH_NETDRIVE;
}
233a241,245
else if (isrofs (real_dir.get_devn ()))
{
set_errno (EROFS);
goto done;
}
266d277
DWORD devn;
272,273c283
else if ((devn = real_dir.get_devn ()) == FH_PROC || devn == FH_REGISTRY
|| devn == FH_PROCESS)
---
else if (isrofs (real_dir.get_devn ()))
RE: echo $(echo '\r') oddity
Hi Brian, in interactive mode the command seems to work fine. What happens if you build socat and then run the test script (./test.sh) ? Which tests does it fail on? What DOES fail for me is $ socat -t 0.1 exec:'openssl s_server -accept 12002 -quiet -cert cacert.pem -key privkey.pem' pipe $ echo hello | socat -d -d -t 0.1 - openssl:localhost:12002,cafile=cacert.pem,verify=1 so piping text into the client socat is failing on me. regards, JJK I built socat and tried the very same commands you did, and it seems to work fine. I normally run a CVS build of the Cygwin DLL but I switched to 1.5.16 and it works fine with that version as well. $ socat -t 0.1 exec:'openssl s_server -accept 12002 -quiet -cert cacert.pem -key privkey.pem' pipe [1] 3276 $ socat -d -d -t 0.1 - openssl:localhost:12002,cafile=cacert.pem,verify=1 2005/05/04 02:19:30 socat[2460] N reading from and writing to stdio 2005/05/04 02:19:30 socat[2460] N opening connection to AF=2 127.0.0.1:12002 2005/05/04 02:19:30 socat[2460] N successfully connected from local address AF=2 127.0.0.1:4335 2005/05/04 02:19:30 socat[2460] N SSL connection using DHE-RSA-AES256-SHA 2005/05/04 02:19:30 socat[2460] N starting data transfer loop with FDs [0,1] and [3,3] hello hello goodbye goodbye 2005/05/04 02:19:34 socat[2460] N socket 1 (fd 0) is at EOF 2005/05/04 02:19:34 socat[2460] N socket 2 (fd 3) is at EOF 2005/05/04 02:19:34 socat[2460] W shutdown(3, 2): Bad file descriptor 2005/05/04 02:19:34 socat[2460] N exiting with status 0 The hello and goodbye I each typed once, the second one was echoed back to me. I then hit ^D. If there was any network problems I would not have expected the ssl handshake to succeed (I used a dummy cert on both sides as you can tell.) This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- 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: problem with using tetex 3.0.0-2
TC writes: I have ran updmap by hand, somehow get it runs successfully. But it does not create the directory /var/lib/texmf. What else can I do? Well, if you have write permission, and no error log, you'd need a local TeXpert to look into the problem. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org -- 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: Strange-Dangerous behaviour in Cygwin
Original Message From: Christopher Faylor Sent: 08 May 2005 23:53 On Sun, May 08, 2005 at 03:02:17PM +0200, Angelo Graziosi wrote: The problems described prviously exist in standard bash shell (that is launched with the link on Desktop) Again: This means that IT IS an xterm setup issue so YOU SHOULD be using the cygwin-xfree mailing list. I must be missing something here. How that is an xterm setup issue? Last time I let setup.exe create an icon on my desktop it gave me a standard bash-shell-in-DOS-box. Has that changed, or is it related to xterm in some way I don't understand? 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: Fixing strace and cygcheck so that they work with mount -X
Original Message From: Christopher Faylor Sent: 09 May 2005 03:26 On Sun, May 08, 2005 at 08:21:26PM -0400, Christopher Faylor wrote: The above is an *example* of what could be done to install the needed files. There may be typos in the example or it may not work perfectly on your system. It is intended as a *hint* for those who are savvy enough to test things without excessive amounts of hand holding. If you are not comfortable with UNIX commands like wget or tar, please do not attempt this. If you do not know what a Windows command shell is or you cannot figure out how to run bash from the command shell or you are not comfortable with command shell commands like copy please do not try this. May cause intense itching. Discontinue if symptoms persist for more than a millennium. May suddenly accelerate to dangerous speeds. Do not taunt the Cygwin snapshot. Not valid in Alaska or Tennessee. UNIX ® is a registered trademark of the Open Group in the United States and other countries. ) cgf No hippos were harmed in the making of this snapshot! 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: problem with using tetex 3.0.0-2
Original Message From: Jan Nieuwenhuizen Sent: 09 May 2005 08:18 TC writes: I have ran updmap by hand, somehow get it runs successfully. But it does not create the directory /var/lib/texmf. What else can I do? Well, if you have write permission, and no error log, you'd need a local TeXpert to look into the problem. Jan. Or you could invoke bash with the -x flag and find out *why* updmap fails. bash --login -i -x /usr/bin/updmap 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: sshd owned by root error
On May 6 16:42, Christopher Faylor wrote: On Fri, May 06, 2005 at 12:41:55PM -0400, Igor Pechtchanski wrote: On Fri, 6 May 2005, Ordal, Peter wrote: I just finished an install of Cygwin's OpenSSH on XP SP 2. Along the way I got the error: /var/empty must be owned by root and not group or world-writable. This has been discussed several places before, I know. Still, I had a different experience than previous posts. I found that what owned by root meant was actually owned by the account running sshd. So, when I ran /usr/sbin/sshd -D under my domain account, I had to chown /var/empty to my account. The above might be a good candidate for the FAQ... I think the error message should probably be changed instead, although I suspect that the upstream openssh maintainers might balk at that. They will, no doubt about it. The test for ownership is generally guarded by a test for the root user. Only on Cygwin the test also tests for the user running sshd. So that's FAQ fodder. 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/
sqlite / pysqlite ... RFC/ITP?
Hi all, I'm not sure just *how* off-topic this is, let's see ... I'm using Reini's own package of sqlite 3.0.7 for cygwin in conjunction with the pysqlite source-distribution. This works quite well, only I'd like it all in cygwin packages in the standard distribution. For the record: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. - http://www.sqlite.org/ pysqlite is a Python DB-API 2.0 interface for the SQLite embedded relational database engine. - http://www.pysqlite.org/ Now on to the real issues: I might volunteer as maintainer for the pysqlite cygwin package, but there are a few questions: - Is anyone else actually interested in this, or might I be better off to keep it to my own? - Reini, will the sqlite package ever be part of the standard cygwin mirrors, or would I have to maintain that, too? Is there any serious reason against uploading it? - The python setup script, shipped with the pysqlite source, builds and installs different DLLs, not only for different versions of python (e.g. 2.3 vs. 2.4 which isn't a problem as only 2.4 is supported in cygwin as of now), but also for each version of the cygwin dll itself. This makes it look as if it's a bad idea to just package the binary ... But I have no real experience with that yet. Would I have to update it whenever a new cygwin version comes about, or is there a smart way around it - e.g. to call the actual build-and-install from the postinstall script? Sounds scary. Might it be OK to distribute a pysqlite binary cygwin package and rebuild it only as soon as it stops working? Note also that this would be my first ITP ever. If I get positive responses here, I'll take the ITP to cygwin-apps, of course. Thanks for any hints, Jan. -- 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: echo $(echo '\r') oddity
Jan Just Keijser wrote: in interactive mode the command seems to work fine. What happens if you build socat and then run the test script (./test.sh) ? Which tests does it fail on? test.sh fails on the openssl test for me too. I can't really follow exactly what the testcase is doing though. It looks like there's a race condition somewhere because you get the previous command's output with each command: $ socat -t0.1 exec:'openssl s_server -accept 12009 -quiet -cert cacert.pem -key privkey.pem' pipe $ echo -n 1 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 $ echo -n 2 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 1 $ echo -n 3 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 2 $ echo -n 4 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 3 I don't know what's going there. You'd probably have to delve into an strace to find out. 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: echo $(echo '\r') oddity
This is exactly the problem I am seeing and it also happens with a few other tests. When using socat -d -d -d -v it turns out that the server process is sending back the text ( hello) but this text never ends up at the client. This also happens when the server is running on Cygwin and the client is running on Linux (change the client command to use the server's IP address instead of localhost). My guess was that this is a flushing problem and not a race condition; BTW, I am 99.% convinced that this is caused by socat and not by the openssl server process. h I was hoping somebody had a terribly bright idea before I started using strace but I guess that's what I will have to do thx, JJK -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Monday, May 09, 2005 12:06 To: 'cygwin@cygwin.com' Subject: Re: echo $(echo '\r') oddity Jan Just Keijser wrote: in interactive mode the command seems to work fine. What happens if you build socat and then run the test script (./test.sh) ? Which tests does it fail on? test.sh fails on the openssl test for me too. I can't really follow exactly what the testcase is doing though. It looks like there's a race condition somewhere because you get the previous command's output with each command: $ socat -t0.1 exec:'openssl s_server -accept 12009 -quiet -cert cacert.pem -key privkey.pem' pipe $ echo -n 1 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 $ echo -n 2 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 1 $ echo -n 3 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 2 $ echo -n 4 | socat -t0.1 - openssl:localhost:12009,cafile=cacert.pem,verify=1 3 I don't know what's going there. You'd probably have to delve into an strace to find out. 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/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- 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: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges
How to confirm whether Cygwin 1.5.16 has been installed? Is it uname -a command? Best regards, Jayant Moghe === Texas Instruments (I) Pvt. Ltd. Bagmane Tech Park, CV Raman Nagar, Byrasandra Bangalore - India 560 093 Office Phone: - +91- 80 - 25048295 [EMAIL PROTECTED] Fools you are... to say you learn by your experience I prefer to profit by other's mistakes and avoid the price of my own. -Otto von Bismarck, 19th Century Prussian Chancellor. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Friday, April 29, 2005 7:15 PM To: cygwin@cygwin.com Subject: Re: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges On Apr 29 15:36, Corinna Vinschen wrote: On Apr 29 18:50, Moghe, Jayant wrote: I there any way where I can avail paid support? Sure, but isn't it easier to report your problem somewhat more detailed and see if you get a free (as in free beer) reply within a couple of days? For the records: I tried to reproduce your problem with a 2K3 Server machine running terminal services. Logging in via remote desktop with a non-admin acocunt, I was able to use bash and any other tool just fine. This is with Cygwin 1.5.16. Did you upgrade? Perhaps that helps. Other than that, I found that bash can be somewhat obdurate if the /tmp directory is not writable for the user. I suggest to change the permissions with chmod 1777 /tmp HTH, 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/ -- 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 and column dividers
On 06 May 2005, you wrote in gmane.os.cygwin: J. David Boyd wrote: Does anyone know where, in what file, the information for setup.exe is stored as it pertains to the column dividers? At some point in the past, I did 'something' so that all I see in the window is the current version. I have to move FAR to the right, and drag back the column divider, 6 or 7 times, until I can see all the pertinent fields at once in the program window. Check your /etc/setup/installed.db for a package with a long string of repeating version numbers, e.g. foo-1.3.2.2.2.2.2.2.2.2 or something like that. At some point in the past there was a packaging error that named a package with an improper version, and for whatever reason setup got confused by this and recored this malformed version number. The columns adjust their size to fit the widest element in the column, and if you have this bogus package number that would cause it. Alternatively, if you just switch to the Full view and page through the list you should be able to find the package that is causing the column to be so wide. Uninstall/reinstall that package. Brian Thank you very much, that was indeed the problem. Dave -- 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: postgresql and sockets
On May 6 02:02, Krzysztof Duleba wrote:
150 int issocket () const {return dev.devn == FH_UNIX;}
(gdb) n
78set_errno (EBADF);
(gdb) n
79return 0;
Your debugging shows that my assumption was correct. The file isn't
recognized as socket anymore. This was already shown by `cat' printing
the contents of the socket file, though. The problem is that we still
don't know why, when and by which process the file is changed so that
it's not recognized as socket anymore. More debugging is required.
You wrote that this happens after 10 minutes, regardless if the socket
is used or not. Does the output of `ls -l' on the file change after
the 10 minutes? What does `ls -l' on the file print anyway?
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: sending packets from solaris to Cygwin
On May 8 13:02, Nakul Haridas wrote: Hi, The codes I have attached are similar to a eariler reported problem References: [EMAIL PROTECTED] However I have my program working either in Solaris or Cygwin only. If the server is on solaris and client on cygwin and vice versa , the packet is lost. I cant figure out what the problem could be. I have also put memset(su_addr, 0, sizeof(su_addr));/* server addr info */ su_addr.sin_family = AF_INET; su_addr.sin_port = htons(MYPORT); su_addr.sin_addr.s_addr = inet_addr(u_addr); This should have solved the probelem but it didnt. Could youhelp me in this regards. Probably not. After working around the missing udp_ack.h in your attached example code, I tried it between a Linux and a Cygwin box. http://cygwin.com/acronyms/#WJFFM. 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: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges
On May 9 17:15, Moghe, Jayant wrote: How to confirm whether Cygwin 1.5.16 has been installed? Is it uname -a command? Did you consider to *try* it? 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: base-files patch (atn: Eric Blake)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to John Morrison on 5/8/2005 1:52 AM:
On Fri, March 25, 2005 8:26 pm, Eric Blake said:
True enough. And that points out another bug - echo $0 may fail if $0
starts with -, it should be echo -- $0. Isn't portable shell
programming fun?
Sorry that this has taken so long, but I'm just getting around to adding
all the fixes emailed wrt /etc/profile. I tried the above, and it broke
so I checked the man pages,
Serves me right for thinking that echo was standard when I typed my
original message, rather than me actually testing at the command line.
Yes indeed, POSIX requires that echo must interpret -- as a string
operand, rather than the standard interpretation of being an argument
separator.
so, I'm afraid that echo -- ${0} won't work.
This will work instead:
case `printf %s $0 | /usr/bin/tr '[:upper:]' '[:lower:]'` in
bash | -bash | */bash )
[..]
- --
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
iD8DBQFCf1wc84KuGfSFAYARAg5qAJ9M9WVxgQhBUc9edDMtZZirq8/JIACfbw2t
KQ0laPFFkGEIWyjP3xHaJB8=
=r+l4
-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: DD converts LF - CR / LF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/8/2005 5:03 PM: Hmm, overriding the explicit advice of the system administrator? How common is it for file systems to be mounted in text mode? Why would anyone do such a thing? If it's sufficiently rare, then dd shouldn't need to worry about it. It is not rare but, regardless, this email was the result of someone who was surprised by the fact that dd converted LF - CRLF. Whether it is common or not, I don't think it makes sense to surprise people who use dd when it is trivial to make it work in a more UNIX-like fashion (i.e., do not convert LF - CRLF). The cygwin installer is being changed to more explicitly warn users that text-mode mounts are usually a bad idea. The problem is that the cygwin system administrator is often the primary user, and is often naive about the issues between text vs binary mounts (especially at the point in time when they ran the installer). However, Paul's arguments are starting to convince me (if only because then I have fewer downstream patches to maintain) - respecting the underlying mount point unless told otherwise can also be considered a sensible behavior, and is adopted by several other utilities in coreutils. So long as there is command-line configurability to get both text and binary behaviors (whether that be default binary, iflag=binary is a no-op, and iflag=text always changes behavior; or default from underlying mount, and both iflag=binary and iflag=text potentially change behavior), then a cygwin FAQ can be written that tells the user how to make dd(1) meet expectations (if it really is frequently asked). I guess it comes down to how often is dd used in scripts vs. interactively? Note that this alias would give binary-only behavior in interactive mode even when respecting the underlying mount points: $ alias dd='dd iflag=binary oflag=binary' iflag= is already a coreutils extension beyond POSIX, so this alias relies on parsing multiple iflag= operands in the same way that POSIX requires support for multiple conv= operands. But since iflag= is a POSIX extension, portable scripts that use dd cannot assume its existance, and they will get whichever default behavior we choose (all binary, or underlying mount). - -- 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 iD8DBQFCf10N84KuGfSFAYARAi9FAKCvTTD43+pDp5euzEfL9ZwWoMRd9wCeK1uM hz2iNl2z2OJYh+me30G3qpQ= =53KA -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: Strange-Dangerous behaviour in Cygwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Carlo Florendo on 5/8/2005 9:30 PM:
Ooops. Sorry, I've read earlier discussions on this issue just a few
seconds ago by Erik Blake et al. So, it's not an xterm issue. It's a
I spell it Eric.
bug with coreutils not being POSIX compliant. A patch has been
applied. We just have to wait for the next annoucement for coreutils.
Hold on there - the bug in POSIX non-compliance was that before coreutils
patch, `rm -i' accepted y as yes, now CVS coreutils obeys POSIX and
interprets it as a match failure (which has the same effect as typing an
answer interpreted as no). Unfortunately, POSIX requires that if your
terminal settings are strange (such as the ctlecho settings that cgf
mentioned on linux), such that raw editing characters escape the terminal
into the program, that y\bn ('y', BACKSPACE, 'n') be interpreted as yes.
The only way this would be an xterm bug is if the default tty settings of
xterm under cygwin can be changed to improve user experience by making it
less likely that raw backspaces are passed through to the program, rather
than being line edited first.
And my next release of cygwin coreutils-5.3.0-6 will not be CVS coreutils
(with all its recent patches in many other areas as well), but stock 5.3.0
with a minimal subset of CVS patches backported as needed (I plan to wait
until 5.3.1 is released before cygwin officially sees all upstream patches
since 5.3.0, unless someone can convince me of a need for cygwin to track
CVS). That means I will not be changing the yes/no behavior in my next
drop of coreutils. But rest assured that I am tracking CVS changes on my
own machine, to try and make sure that there are no regressions introduced
when 5.3.1 is finally released upstream.
- --
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
iD8DBQFCf18n84KuGfSFAYARAliCAJ9LHbOYO3swwmsLrqlDff0KMyEY4ACeMzAI
x1/ti+7xCZub+fRYc0Kts6Q=
=wTHd
-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: Strange-Dangerous behaviour in Cygwin
On Mon, May 09, 2005 at 10:17:34AM +0100, Dave Korn wrote: Original Message From: Christopher Faylor Sent: 08 May 2005 23:53 On Sun, May 08, 2005 at 03:02:17PM +0200, Angelo Graziosi wrote: The problems described prviously exist in standard bash shell (that is launched with the link on Desktop) Again: This means that IT IS an xterm setup issue so YOU SHOULD be using the cygwin-xfree mailing list. I must be missing something here. How that is an xterm setup issue? Last time I let setup.exe create an icon on my desktop it gave me a standard bash-shell-in-DOS-box. Has that changed, or is it related to xterm in some way I don't understand? Sorry. I meant to apologize for misinformation (and very poor reading skills) after the issue became clearer. I mentioned what the actual problem is later in the thread. 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: Help !!! - Problem running Cygwin in Remote Desktop session with non-admin privileges
On Mon, May 09, 2005 at 02:39:28PM +0200, Corinna Vinschen wrote: On May 9 17:15, Moghe, Jayant wrote: How to confirm whether Cygwin 1.5.16 has been installed? Is it uname -a command? Did you consider to *try* it? bash: it: command not found 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: DD converts LF - CR / LF
On Mon, May 09, 2005 at 06:52:29AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 5/8/2005 5:03 PM: Hmm, overriding the explicit advice of the system administrator? How common is it for file systems to be mounted in text mode? Why would anyone do such a thing? If it's sufficiently rare, then dd shouldn't need to worry about it. It is not rare but, regardless, this email was the result of someone who was surprised by the fact that dd converted LF - CRLF. Whether it is common or not, I don't think it makes sense to surprise people who use dd when it is trivial to make it work in a more UNIX-like fashion (i.e., do not convert LF - CRLF). The cygwin installer is being changed to more explicitly warn users that text-mode mounts are usually a bad idea. The problem is that the cygwin system administrator is often the primary user, and is often naive about the issues between text vs binary mounts (especially at the point in time when they ran the installer). However, Paul's arguments are starting to convince me (if only because then I have fewer downstream patches to maintain) - respecting the underlying mount point unless told otherwise can also be considered a sensible behavior, and is adopted by several other utilities in coreutils. As one of the project leads, I am formally asking you to make dd default to binary behavior. This whole thread was kicked off by someone who was suprised by the current behavior. I don't think there is any reason to force people to read the man page in order to get the behavior that they're used to on UNIX. If you want to make it to text mode when the dd arguments clearly indicate that you're manipulating text, then that would be great. Otherwise, the current and proposed behavior will just annoy me and prevent me from writing portable scripts. I use text mode mounts myself and I do not desire this behavior. So far, that seems to be two for two desiring binmode. 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: Help with error in vi and man
On 5/7/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Sat, May 07, 2005 at 06:27:59PM -0600, Trevor Osatchuk wrote: On 5/7/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Fri, May 06, 2005 at 10:59:22PM -0600, Trevor Osatchuk wrote: When starting up vi/vim I get the following error: E558: Terminal entry not found in terminfo 'cygwin' not known. Available builtin terminals are: builtin_ansi builtin_xterm builtin_iris-ansi builtin_dumb defaulting to ansi Help does not work for vim I get the error: E433: No tags file E149: Sorry, no help for help.txt Also when I type in the man command, man ls for example, all I get is (END) and no man page. Like it paged to the end. I don't currently have a pager environment variable. My manpath is correct. Any ideas? Run the cygwin version of vim, i.e., /usr/bin/vim? You're obviously running some other version. which vim would probably show which version you're running. Obviously is a strong word! Which vim yeilds /usr/bin/vim. I have seen these symtoms in other posts, though no solutions. Ok. Perhaps your terminfo installation is screwed up or nonexistent. If you're scouring old posts then maybe you've come across the concept of following the instructions at http://cygwin.com/problems.html , as has already been sugested. These instructions would help you send problems in such a way that we wouldn't have to guess about things like what version of vim you're running or whether you even have terminfo installed. I apologize for not sending the expected information and format. LART accepted. I am running CYGWIN_NT-5.1, I got that from uname. I think that terminfo may in fact be the correct diagnosis. I found a symlink of terminfo in /lib where terminfo was pointing to ../share/terminfo. There is no /share directory. If you look in my cygcheck.out you will find that terminfo 5.4_20041009-1 is listed as installed. So, is my installation of terminfo broken? What do I need to do to fix it? Thanks! fybar Cygwin Configuration Diagnostics Current System Time: Mon May 09 09:46:43 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\cygwin\home\trevor\scripts c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Adaptec Shared\System c:\PROGRA~1\COMMON~1\AUTODE~1 Output from C:\cygwin\bin\id.exe (nontsec) UID: 400(osatchuk) GID: 401(mkpasswd) 0(root) 513(None) 544(Administrators) 545(Users) 401(mkpasswd) Output from C:\cygwin\bin\id.exe (ntsec) UID: 400(osatchuk) GID: 401(mkpasswd) 0(root) 513(None) 544(Administrators) 545(Users) 401(mkpasswd) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `c:\Documents and Settings\osatchuk' MAKE_MODE = `unix' PWD = `/cygdrive/c/Documents and Settings/osatchuk' USER = `osatchuk' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\osatchuk\Application Data' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `GALILEO' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CVS_RSH = `/bin/ssh' FP_NO_HOST_CHECK = `NO' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\osatchuk' HOSTNAME = `GALILEO' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\GALILEO' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/usr/bin' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PRINTER = `\\P6330\HPLJ5000' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 13 Stepping 6, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0d06' PROGRAMFILES = `C:\Program Files' PROMPT = `$P$G' PS1 = [EMAIL PROTECTED] \033[01;31m\w\033[0m \033[04;36m##\d##\033[0m \033[01;35m\t\033[0m\n$ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\osatchuk\LOCALS~1\Temp' TERM = `cygwin' TMP = `C:\DOCUME~1\osatchuk\LOCALS~1\Temp' USERDOMAIN = `GALILEO' USERNAME = `osatchuk' USERPROFILE = `C:\Documents and Settings\osatchuk' WINDIR = `C:\WINDOWS' _ = `/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
cygwn error in arm build binutils
I'm trying to build an arm tool chain for ECOS per their build instructions. I have a fresh install of cygwin and all the recommended sources. Each time I try to build the binutils-2.13.1I get an error message from the make. This seems to be a problem with the version of makeinfo.? I'm using version 4.8 of makeinfo from current cygwin release . I've tried several different version of binutils with the same results Anyone recognize this error and have a fix? My config command: /binutils-2.13.1/configure --target=arm-elf --prefix=/armtools -v 21 | tee make.out My make command: Make -w all install 21 | tee make.out make[4]: Leaving directory `/buildbin/binutils/doc' make[3]: Leaving directory `/buildbin/binutils/doc' rm -f config.texi echo '@set VERSION 2.13.1' config.texi makeinfo -I /binutils-2.13.1/binutils/doc /binutils-2.13.1/binutils/doc/binutils.texi /binutils-2.13.1/binutils/doc/binutils.texi:51: Unknown index `ky' and/or `cp' in @synindex. makeinfo: Removing output file `/buildbin/binutils/doc/binutils.info' due to errors; use --force to preserve. make[2]: *** [binutils.info] Error 1 make[2]: Leaving directory `/buildbin/binutils/doc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/buildbin/binutils' make: *** [install-binutils] Error 2 make: Leaving directory `/buildbin' Thanks, Richard Slaughter Firmware Engineer This message, including any attachments, may contain information that is confidential and proprietary information of Advanced Energy Industries, Inc. The dissemination, distribution, use or copying of this message or any of its attachments is strictly prohibited without the express written consent of Advanced Energy Industries, 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: Fixing strace and cygcheck so that they work with mount -X
On 5/8/2005 7:26 PM, Christopher Faylor wrote: On Sun, May 08, 2005 at 08:21:26PM -0400, Christopher Faylor wrote: Ultimately, I just have to make strace and cygcheck understand the cygwin arguments and environment variables. Then we won't need this. I would appreciate it if people would check out the latest snapshot to verify if I actually got this working in all scenarios (directories mounted with -X, -x, not mounted at all, or mounted without -X and -x). Does cygstart also need to be fixed? I've found that it doesn't propagate the full Cygwin environment when /bin is mounted in cygexec mode. % cygstart -- /bin/rxvt -e bash -c 'env; read x' prints out a small set of environment variables when /bin is mounted in cygexec. When /bin is mounted normally, it gets the full environment. -- David Rothenbergerspammer? - [EMAIL PROTECTED] GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734 Everybody is going somewhere!! It's probably a garage sale or a disaster Movie!! -- 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/
Bug in the /dev/ttySx handling code?
I compiled a linux program, which uses the serial driver (and is working) under cygwin (winxp), but the communication was not working. For initializing the port, I use: fd = open (dev, O_RDWR | O_NOCTTY); tcgetattr (fd, t1); t1.c_cflag = B19200 | CS8 | PARENB | CLOCAL | CREAD; t1.c_iflag = IGNBRK | INPCK | ISIG; t1.c_oflag = 0; t1.c_lflag = 0; t1.c_cc[VTIME] = 1; t1.c_cc[VMIN] = 0; tcsetattr (fd, TCSAFLUSH, t1); Then normal read/write to the file descriptor follows. strace logged: 47 22132 [main] eibd 3124 fhandler_serial::open: fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 101 22233 [main] eibd 3124 fhandler_base::open_9x: (\\.\com2, 0x8002) 1415 23648 [main] eibd 3124 fhandler_base::set_flags: flags 0x8002, supplied_bin 0x1 59 23707 [main] eibd 3124 fhandler_base::set_flags: filemode set to binary 42 23749 [main] eibd 3124 fhandler_base::open_9x: 0x6C8 = CreateFile (\\.\com2, 0xC000, 0x7, 0x22E990, 0x3, 0x4080, 0) 44 23793 [main] eibd 3124 fhandler_base::open_9x: 1 = fhandler_base::open (\\.\com2, 0x8002) 97 23890 [main] eibd 3124 fhandler_serial::open: 0x1 = fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 45 23935 [main] eibd 3124 open: 5 = open (/dev/ttyS1, 0x8002) 85 24020 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 41 24061 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 75 24136 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 46 24182 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 57 24239 [main] eibd 3124 fhandler_serial::tcsetattr: action 1 55 24294 [main] eibd 3124 fhandler_serial::tcsetattr: flushed file buffers 210 24504 [main] eibd 3124 fhandler_serial::tcsetattr: vtime 100, vmin 0 42 24546 [main] eibd 3124 fhandler_serial::tcsetattr: ReadTotalTimeoutConstant 100, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1 56 24602 [main] eibd 3124 tcsetattr: iflag 0x11, oflag 0x0, cflag 0x9BE, lflag 0x0, VMIN 0, VTIME 1 43 24645 [main] eibd 3124 tcsetattr: 0 = tcsetattr (5, 1, 22EDF0) A printf of the return code of tcsetattr returned 0. I connected the program using a null modem cable to an other Linux machine. It turned out, that cygwin configured the serial interface to 9600 baud. With this configuration, I can send without any errors data on the linux PC to the cygwin program (and back): stty -F /dev/ttyS0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5; parenb parodd cs8 -hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke On cygwin, stty on the serial is not working (stty -F /dev/ttyS0 shows 0 baud; stty -F /dev/ttyS0 speed 9600 returns an error message). Is the serial driver emulation code not supporting this, or is there an bug in it? mfg Martin Kögler PS: Please CC me on replies -- 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: Experiencing problems with OpenGL
Hi everybody,
First and foremost I have to say that I am so happy with the concept of
Cygwin and to the Cygwin volunteers Keep up with the good work. It is
so much appreciated. I am having a little problem with compiling an
OpenGL sourcefile.
Here's what I've done so far:
Installed Cygwin using setup.exe to c:\cygwin using default settings
onto Windows XP SP 2 OS.
Installed make, g++ and nano by running setup.exe again.
Read the readme file located under /usr/share/opengl1-1-0.
Little confused about what switches I should use when compiling .cpp
file and whether to use a makefile or not.
Ran the OpenGL examples to test if its possible to run the .exe files
compiled and linked under Cygwin. All examples ran successfully.
Tried to compile the following .cpp file whilst using -lglu32 -lopengl32
switches with g++:
#define WIN32_LEAN_AND_MEAN
#include windows.h
#include gl/glu.h
#include gl/gl.h
HDC g_hDC;
bool g_keys[256];
void SetupPixelFormat(HDC hDC)
{
int nPixelFormat;
static PIXELFORMATDESCRIPTOR pfd =
{
sizeof(PIXELFORMATDESCRIPTOR),
1,
PFD_DRAW_TO_WINDOW |
PFD_SUPPORT_OPENGL |
PFD_DOUBLEBUFFER,
PFD_TYPE_RGBA,
32,
0,0,0,0,0,0,
0,
0,
0,
0,0,0,0,
16,
0,
0,
PFD_MAIN_PLANE,
0,
0,0,0
};
nPixelFormat = ChoosePixelFormat(hDC,pfd);
SetPixelFormat(hDC,nPixelFormat,pfd);
}
LRESULT CALLBACK WndProc(HWND hWnd,UINT msg,WPARAM wParam,LPARAM lParam)
{
static HDC hDC;
static HGLRC hRC;
int width,height;
switch (msg)
{
case WM_CREATE:
{
hDC = GetDC(hWnd);
g_hDC = hDC;
SetupPixelFormat(hDC);
hRC = wglCreateContext(hDC);
wglMakeCurrent(hDC,hRC);
return 0;
break;
}
case WM_SIZE:
{
width = LOWORD(lParam);
height = HIWORD(lParam);
glViewport(0,0,width,height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f,(GLfloat)width /
(GLfloat)height,1.0f,1000.0f);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
return 0;
break;
}
case WM_CLOSE:
{
wglMakeCurrent(hDC,NULL);
wglDeleteContext(hRC);
PostQuitMessage(0);
return 0;
break;
}
case WM_SYSCOMMAND:
{
switch (wParam)
{
case SC_SCREENSAVE:
{
return 0;
break;
}
case SC_MONITORPOWER:
{
return 0;
break;
}
default:
{
break;
}
}
break;
}
case WM_KEYDOWN:
{
g_keys[wParam] = TRUE;
return 0;
break;
}
case WM_KEYUP:
{
g_keys[wParam] = FALSE;
return 0;
break;
}
default:
{
break;
}
}
return (DefWindowProc(hWnd,msg,wParam,lParam));
}
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR
lpCmdLine,int nShowCmd)
{
RECT wr;
WNDCLASSEX wc;
HWND hWnd;
bool done;
MSGmsg;
int width = 1280;
int height = 800;
int bits = 32;
wr.left = (long)0;
wr.right = (long)width;
wr.top= (long)0;
wr.bottom = (long)height;
wc.cbSize= sizeof(WNDCLASSEX);
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = WndProc;
wc.cbClsExtra= 0;
wc.cbWndExtra= 0;
wc.hInstance = hInstance;
FW: Bug in the /dev/ttySx handling code?
It appears you are using com1, with this command: stty -F /dev/ttyS0 -a But, your strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? T. Dabbs Subject: Bug in the /dev/ttySx handling code? I compiled a linux program, which uses the serial driver (and is working) under cygwin (winxp), but the communication was not working. For initializing the port, I use: fd = open (dev, O_RDWR | O_NOCTTY); tcgetattr (fd, t1); t1.c_cflag = B19200 | CS8 | PARENB | CLOCAL | CREAD; t1.c_iflag = IGNBRK | INPCK | ISIG; t1.c_oflag = 0; t1.c_lflag = 0; t1.c_cc[VTIME] = 1; t1.c_cc[VMIN] = 0; tcsetattr (fd, TCSAFLUSH, t1); Then normal read/write to the file descriptor follows. strace logged: 47 22132 [main] eibd 3124 fhandler_serial::open: fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 101 22233 [main] eibd 3124 fhandler_base::open_9x: (\\.\com2, 0x8002) 1415 23648 [main] eibd 3124 fhandler_base::set_flags: flags 0x8002, supplied_bin 0x1 59 23707 [main] eibd 3124 fhandler_base::set_flags: filemode set to binary 42 23749 [main] eibd 3124 fhandler_base::open_9x: 0x6C8 = CreateFile (\\.\com2, 0xC000, 0x7, 0x22E990, 0x3, 0x4080, 0) 44 23793 [main] eibd 3124 fhandler_base::open_9x: 1 = fhandler_base::open (\\.\com2, 0x8002) 97 23890 [main] eibd 3124 fhandler_serial::open: 0x1 = fhandler_serial::open (/dev/ttyS1, 0x8002, 0xF78) 45 23935 [main] eibd 3124 open: 5 = open (/dev/ttyS1, 0x8002) 85 24020 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 41 24061 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 75 24136 [main] eibd 3124 fhandler_serial::tcgetattr: vmin_ 0, vtime_ 0 46 24182 [main] eibd 3124 tcgetattr: iflag 4, oflag 0, cflag 930, lflag 0, VMIN 0, VTIME 0 57 24239 [main] eibd 3124 fhandler_serial::tcsetattr: action 1 55 24294 [main] eibd 3124 fhandler_serial::tcsetattr: flushed file buffers 210 24504 [main] eibd 3124 fhandler_serial::tcsetattr: vtime 100, vmin 0 42 24546 [main] eibd 3124 fhandler_serial::tcsetattr: ReadTotalTimeoutConstant 100, ReadIntervalTimeout -1, ReadTotalTimeoutMultiplier -1 56 24602 [main] eibd 3124 tcsetattr: iflag 0x11, oflag 0x0, cflag 0x9BE, lflag 0x0, VMIN 0, VTIME 1 43 24645 [main] eibd 3124 tcsetattr: 0 = tcsetattr (5, 1, 22EDF0) A printf of the return code of tcsetattr returned 0. I connected the program using a null modem cable to an other Linux machine. It turned out, that cygwin configured the serial interface to 9600 baud. With this configuration, I can send without any errors data on the linux PC to the cygwin program (and back): stty -F /dev/ttyS0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 5; parenb parodd cs8 -hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke On cygwin, stty on the serial is not working (stty -F /dev/ttyS0 shows 0 baud; stty -F /dev/ttyS0 speed 9600 returns an error message). Is the serial driver emulation code not supporting this, or is there an bug in it? mfg Martin Kögler PS: Please CC me on replies -- 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/
ls finds file1 but ls file1 does not
ls finds file1 but ls file1 does not. How can this happen? The following example occurred just after I had renamed some *.htm files to *.html using an ash shell script. No such problem occurred, however, when I used DOS rename to make the same change. (Windows XP Pro SP 2) Does Windows have some kind of special handling for the extension .htm? EXAMPLE: [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_c $ ls _index.htm*finder.dat* lib_over.htm* setjmp.htm* time.htm* assert.htm*float.htm* lib_prin.htm* signal.htm* types.htm* charset.htm* function.htm* lib_scan.htm* stdarg.htm* wchar.htm* crit_pb.htm* gif/limits.htm* stddef.htm* wctype.htm* ctype.htm* index.htm* locale.htm* stdio.htm* ./ declare.htm* intro.htm* math.htm* stdlib.htm* ../ errno.htm* iso646.htm* portable.htm* string.htm* express.htm* lib_file.htm* preproc.htm*syntax.htm* [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_c $ ls assert.htm ls: assert.htm: No such file or directory -- THIS IS THE PROBLEM a bit of exploration follows: [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_c $ ls as* ls: as*: No such file or directory [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_c $ ls *.htm _index.htm*express.htm*lib_over.htm* preproc.htm* string.htm* assert.htm*float.htm* lib_prin.htm* setjmp.htm*syntax.htm* charset.htm* function.htm* lib_scan.htm* signal.htm*time.htm* crit_pb.htm* index.htm* limits.htm* stdarg.htm*types.htm* ctype.htm* intro.htm* locale.htm* stddef.htm*wchar.htm* declare.htm* iso646.htm* math.htm* stdio.htm* wctype.htm* errno.htm* lib_file.htm* portable.htm* stdlib.htm* [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_c $ ls AS* ls: AS*: No such file or directory [EMAIL PROTECTED] /cygdrive/c/Documents and Settings/cdr/My Documents/books_open/c/stdcbook_bad/STD_C $ ls -l total 722 -rwx--+ 1 cdr None58614 Oct 12 1995 _index.htm* -rwx--+ 1 cdr None 2177 Oct 12 1995 assert.htm* -rwx--+ 1 cdr None17888 Oct 12 1995 charset.htm* -rwx--+ 1 cdr None 3661 Oct 12 1995 crit_pb.htm* -rwx--+ 1 cdr None 9185 Oct 12 1995 ctype.htm* -rwx--+ 1 cdr None42189 Oct 12 1995 declare.htm* -rwx--+ 1 cdr None 2584 Oct 12 1995 errno.htm* -rwx--+ 1 cdr None84781 Oct 12 1995 express.htm* -rwx--+ 1 cdr None 3440 Nov 20 1995 finder.dat* The only difference here from a correctly working directory is that the correctly working directory does not have execute permissions -- 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: postgresql and sockets
Corinna Vinschen wrote:
On May 6 02:02, Krzysztof Duleba wrote:
150 int issocket () const {return dev.devn == FH_UNIX;}
(gdb) n
78set_errno (EBADF);
(gdb) n
79return 0;
Your debugging shows that my assumption was correct. The file isn't
recognized as socket anymore. This was already shown by `cat' printing
the contents of the socket file, though. The problem is that we still
don't know why, when and by which process the file is changed so that
it's not recognized as socket anymore. More debugging is required.
You wrote that this happens after 10 minutes, regardless if the socket
is used or not. Does the output of `ls -l' on the file change after
the 10 minutes? What does `ls -l' on the file print anyway?
$ ls -l /tmp/.s.PGSQL.5432
srwxrwxrwx 1 SYSTEM Administratorzy 53 May 9 18:21 /tmp/.s.PGSQL.5432
$ sleep 600
$ ls -l /tmp/.s.PGSQL.5432
-rwxrwxrwx 1 SYSTEM Administratorzy 53 May 9 18:31 /tmp/.s.PGSQL.5432
I turned off all non-system apps except for cygserver and postgresql and
still the same.
How can I provide more debug info? Is it possible to check which processes
access or modify the socket file?
Regards
Krzysztof Duleba
--
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: Fixing strace and cygcheck so that they work with mount -X
On 9-May-2005 19:22, David Rothenberger wrote: On 5/8/2005 7:26 PM, Christopher Faylor wrote: On Sun, May 08, 2005 at 08:21:26PM -0400, Christopher Faylor wrote: Ultimately, I just have to make strace and cygcheck understand the cygwin arguments and environment variables. Then we won't need this. I would appreciate it if people would check out the latest snapshot to verify if I actually got this working in all scenarios (directories mounted with -X, -x, not mounted at all, or mounted without -X and -x). Does cygstart also need to be fixed? I've found that it doesn't propagate the full Cygwin environment when /bin is mounted in cygexec mode. % cygstart -- /bin/rxvt -e bash -c 'env; read x' prints out a small set of environment variables when /bin is mounted in cygexec. When /bin is mounted normally, it gets the full environment. Well, cygstart is a proper Cygwin executable. However, it does use a Windows API call (ShellExecute, see cygstart --reference) to execute whatever needs to be started, so I can see how it might depend on a properly synchronized Windows environment. If anyone can tell me how to do this, I'll be happy to make the change to cygstart. Michael -- 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/
JNI and cygwin.
Hi, I assume that the cygwin/JNI combination has still not been fixed in the latest version. I need to make use of the cygwin libraries to get TERMinal support. Any workarounds? Any other libraries supporting curses and TERMinal operations for Windows would also be useful. Thanks, venkat. Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html -- 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: ls finds file1 but ls file1 does not
ls finds file1 but ls file1 does not. How can this happen? [...] The only difference here from a correctly working directory is that the correctly working directory does not have execute permissions You are correct that it has something with permissions. Observe: $ umask 0077 $ mkdir bar# By default, searchable and readable by me $ cd foo $ stat -c %A . drwx-- $ touch foo $ ls foo $ ls foo foo $ chmod a-r . # Make it searchable, but not readable $ stat -c %A . d-wx-- $ ls ls: .: Permission denied $ ls foo foo $ chmod u+r,a-x . # Make it readable, but not searchable $ stat -c %A . drw--- $ ls foo $ ls -F ls: foo: Permission denied $ ls foo ls: foo: Permission denied The x permission on a directory stands for search permission, which is the right to ask what are the properties of a named file in this directory. The r permission on a directory stands for read permission, which is the right to ask what files exist in this directory. `ls' with no arguments defaults to `ls .', which requires only read permission on `.'. But `ls foo' with an argument requires search permission on `.'. Furthermore, `ls -F foo' with an argument requires both search and read permission on `.', because the -F tells ls to find out more about the file than just its name. [...] -rwx--+ 1 cdr None 3440 Nov 20 1995 finder.dat* See the + at the end of your permissions? It means that there are ACL's further modifying who can do things with this file. What does getfacl print for you? Maybe the ACLs will give you a clue why Windows lets you see the file, but your particular cygwin username cannot. My error, without ACLs on the file foo, was EACCESS, Permission denied. But your error was ENOENT, No such file or directory, so I'm not sure what is going on differently. -- Eric Blake -- 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: Strange-Dangerous behaviour in Cygwin
On Sun, 8 May 2005 18:52:58 -0400, Christopher Faylor wrote: On Sun, May 08, 2005 at 03:02:17PM +0200, Angelo Graziosi wrote: The problems described prviously exist in standard bash shell (that is launched with the link on Desktop) and in the shell launched by xterm (with startxwin.bat). THEY DO NOT exist in dos box (with C\:cygwin\bin in W2KSP4 path) and in the shell launched with RXVT: in these cases the BACKSPACE key delete the previous character and does not move the cursor as the LEFT arrow key. Again: This means that IT IS an xterm setup issue so YOU SHOULD be using the cygwin-xfree mailing list. WHY an xterm setup if, as I wrote, the problems are present in standard bash shell, i.e. that launched with cygwin.bat. I have reinstalled Cygwin, installing only the BASE category: NO xterm, NO XORG, NO RXVT. ONLY BASE PACKAGES. The problems are PRESENT in any case!!! thank angelo. -- 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/
Building GCC-4.0-20050430
My apology if this problem has been reported already. I successfully built it for three languages Ada, C, C++ with configured as --enable-languages=ada,c,c++ --enable-threads=gnat. A number of Ada Conformance Assessment Test Suite (ACATS) failed. Further testing reveals that the Ada runtime tasking support was not included in the build. In addition, this behavior is the same as Gcc-Ada-3.3.3 compiler, par of cygwin. Of course, I would like to have Tasking support for Ada Compiler. What options do I need for accomplishing this? Thanks very much in advance for your help. AV -- 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/
Bug in the /dev/ttySx handling code?
On Mon, May 09, 2005 at 12:46:55PM -0500, Terry Dabbs wrote: It appears you are using com1, with this command: stty -F /dev/ttyS0 -a But, you strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? Yes, I used the right port, as on the Linux PC cat /dev/ttyS0 showed the expected data (after adjusting the configuration of the port), which was send with my program (eibd) using cygwin. In the other direction, I did some echo /dev/ttyS0. With 9600 baud, I get for such a request a block of the same byte (I have not checked the hex code). I am using two PCs, one with Windows, where COM2 is used and a Linux PC with only one COM port. stty -F /dev/ttyS0 -a shows the configuration of the Linux PC. A mode COMx in cmd on a unused port shows a baud rate of 9600, so it looks like, the configuration of the serial port is not changed, although in the current CVS version of fhandler_serial.cc, I can not see any proof for it. At least, I understand, why stty -F /dev/ttyS0 under cygwin return 0 baud: tcgetattr returns 0 baud, if DTR is not set, which is different to the behaviour of Linux. I would like to track the problem down, but as the use of stty (and cat for doing IO) does not work, I have no idea, how to do it. mfg Martin Kögler -- 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: Bug in the /dev/ttySx handling code?
Perhaps one of the gurus will chime in I am not an expert, but I produced the following code that works every day on a number of our production machines, using com2 to send data out. The comments are what I put at the time, and as far as I know thet describe accurately what is happening. One note: com_port_name below is the string /dev/com2, not /dev/ttyS1, if that makes a difference. /* We now have the name of the com port. The following opens the port for us to use.*/ rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY ); /* In case this right after a reboot, windows */ /* may be unstable on the com ports. This is */ close(rs232_fd); /* wake it up you might say... */ rs232_fd = open(com_port_name, O_RDWR | O_NOCTTY ); /* Now for real. com_port_name is of the form*/ /* com1, com2, etc.; O_RDWR is open for */ /* read and write. O_NOCTTY indicates there */ /* is no controlling terminal (no tty).*/ /* Now we set the parameters using termios functions, these set the port parameters. Mucho importante! */ tcgetattr(rs232_fd,my_termios); /* Get the current port setup, such as it is. */ my_termios.c_cflag = B9600 | CS8 | CREAD | CLOCAL | HUPCL;/* Set the following communication flags: */ /* B9600 = 9600 Baud rate.*/ /* CS8 = character bits are 8. */ /* CREAD = Enable receiver. */ /* CLOCAL= Ignore modem control lines. No modem here. */ /* HUPCL = Release/close port when the process dies. */ my_termios.c_iflag = IXON | IGNBRK | IGNPAR ; /* Set the following input flags: */ /* IXON = Use XON/XOFF flow on output. */ /* IGNBRK= Ignore Break condition on input. */ /* IGNPAR= Ignore framing and parity errors. */ cfsetospeed(my_termios,B9600); /* Set Speed to 9600 Baud.*/ tcsetattr(rs232_fd,TCSANOW,my_termios); /* Make the my_termios values apply to rs232_fd NOW.*/ tcflush(rs232_fd,TCIOFLUSH); /* Flush any spurious IO data on the port.*/ /* The important opening and set up is done. */ /* Now go read and write. */ Good Luck, Terry -Original Message- Subject: Bug in the /dev/ttySx handling code? On Mon, May 09, 2005 at 12:46:55PM -0500, Terry Dabbs wrote: It appears you are using com1, with this command: stty -F /dev/ttyS0 -a But, you strace shows ttyS1, which is com2. Are you plugged into the proper port with your cable? Yes, I used the right port, as on the Linux PC cat /dev/ttyS0 showed the expected data (after adjusting the configuration of the port), which was send with my program (eibd) using cygwin. In the other direction, I did some echo /dev/ttyS0. With 9600 baud, I get for such a request a block of the same byte (I have not checked the hex code). I am using two PCs, one with Windows, where COM2 is used and a Linux PC with only one COM port. stty -F /dev/ttyS0 -a shows the configuration of the Linux PC. A mode COMx in cmd on a unused port shows a baud rate of 9600, so it looks like, the configuration of the serial port is not changed, although in the current CVS version of fhandler_serial.cc, I can not see any proof for it. At least, I understand, why stty -F /dev/ttyS0 under cygwin return 0 baud: tcgetattr returns 0 baud, if DTR is not set, which is different to the behaviour of Linux. I would like to track the problem down, but as the use of stty (and cat for doing IO) does not work, I have no idea, how to do it. mfg Martin Kögler -- -- 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/
ls finds file1 but ls file1 does not
Response to Eric Blake: Thanks. I forgot that unix had separate permissions for directories. However, I have now given myself all the permissions I know of and I still have the same problem. EXAMPLE: $ ls ass* ls: ass*: No such file or directory --BUT IT IS THERE $ ls -l total 722 -rwxrwxrwx+ 1 cdr None58614 Oct 12 1995 _index.htm* -rwxrwxrwx+ 1 cdr None 2177 Oct 12 1995 assert.htm* -rwxrwxrwx+ 1 cdr None17888 Oct 12 1995 charset.htm* -rwxrwxrwx+ 1 cdr None 3661 Oct 12 1995 crit_pb.htm* -rwxrwxrwx+ 1 cdr None 9185 Oct 12 1995 ctype.htm* etc/ $ ls -ld . drwxrwxrwx+ 4 cdr None0 May 8 12:27 ./ $ getfacl . # file: . # owner: cdr # group: None user::rwx group::rwx group:root:rwx group:SYSTEM:rwx mask:rwx other:rwx default:user:cdr:rwx default:group:root:rwx default:group:SYSTEM:rwx default:mask:rwx -- 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: ls finds file1 but ls file1 does not
Response to Eric Blake: Thanks. I forgot that unix had separate permissions for directories. However, I have now given myself all the permissions I know of and I still have the same problem. EXAMPLE: $ ls ass* ls: ass*: No such file or directory --BUT IT IS THERE $ ls -l total 722 -rwxrwxrwx+ 1 cdr None58614 Oct 12 1995 _index.htm* -rwxrwxrwx+ 1 cdr None 2177 Oct 12 1995 assert.htm* Next thing to check - do you have shell globbing disabled or filtered? (For more info on these options, read `man bash'.) $ echo ignoring:$GLOBIGNORE options:$- $ shopt | grep glob If GLOBIGNORE includes *.htm or the builtin set includes -f, bash will not expand *, but instead looks for the literal file named ass*, which does not exist. I'm also guessing that nullglob is off, otherwise bash would expand the failed * into no arguments at all, which would cause a full directory listing, rather than passing the literal string with * on to ls. -- Eric Blake -- 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/
Static destructors not running
I'm sure this is the result of my having done something stupid
with the setup application, but suddenly static destructors no
longer run. That is, for the following program:
#include stdio.h
struct S {
S();
~S();
} s;
S::S() {
printf(In ctor.\n);
}
S::~S() {
printf(In dtor.\n);
}
int main() {
printf(In main.\n);
}
the output is
In ctor.
In main.
The output In dtor. is missing.
I have tried to update all the gcc compilers and mingw libraries to
the latest versions that the setup application allows me, on the
assumption that somehow I managed to get an old version of a
library during my last update, but nothing I have done restores the
static destructor output. From cygcheck, here are the versions of
things I think might matter:
gcc 3.4.1-1
gcc-ada 3.4.1-1
gcc-core 3.4.1-1
gcc-g++ 3.4.1-1
gcc-g77 3.4.1-1
gcc-java 3.4.1-1
gcc-mingw20040810-1
gcc-mingw-ada20040822-1
gcc-mingw-core 20040822-1
gcc-mingw-g++20040822-1
gcc-mingw-g7720040822-1
gcc-mingw-java 20040822-1
mingw-runtime3.7-1
Anyone have any idea how I managed to do this to myself and,
more importantly, how I can undo it?
Thanks!
--
William M. (Mike) Miller
[EMAIL PROTECTED]
--
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: Static destructors not running
William M. (Mike) Miller wrote:
I'm sure this is the result of my having done something stupid
with the setup application, but suddenly static destructors no
longer run. That is, for the following program:
#include stdio.h
struct S {
S();
~S();
} s;
S::S() {
printf(In ctor.\n);
}
S::~S() {
printf(In dtor.\n);
}
int main() {
printf(In main.\n);
}
the output is
In ctor.
In main.
The output In dtor. is missing.
I have tried to update all the gcc compilers and mingw libraries to
the latest versions that the setup application allows me, on the
assumption that somehow I managed to get an old version of a
library during my last update, but nothing I have done restores the
static destructor output. From cygcheck, here are the versions of
things I think might matter:
gcc 3.4.1-1
gcc-ada 3.4.1-1
gcc-core 3.4.1-1
gcc-g++ 3.4.1-1
gcc-g77 3.4.1-1
gcc-java 3.4.1-1
gcc-mingw20040810-1
gcc-mingw-ada20040822-1
gcc-mingw-core 20040822-1
gcc-mingw-g++20040822-1
gcc-mingw-g7720040822-1
gcc-mingw-java 20040822-1
mingw-runtime3.7-1
Anyone have any idea how I managed to do this to myself and,
more importantly, how I can undo it?
Thanks!
#include iostream
class S
{
public:
S::S()
{
printf(In ctor.\n);
}
S::~S()
{
printf(In dtor.\n);
}
} ;
int
main()
{
printf(In main.\n);
S();
return(0);
}
--
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: Static destructors not running
William M. (Mike) Miller wrote:
I'm sure this is the result of my having done something stupid
with the setup application, but suddenly static destructors no
longer run. That is, for the following program:
#include stdio.h
struct S {
S();
~S();
} s;
S::S() {
printf(In ctor.\n);
}
S::~S() {
printf(In dtor.\n);
}
int main() {
printf(In main.\n);
}
the output is
In ctor.
In main.
The output In dtor. is missing.
I have tried to update all the gcc compilers and mingw libraries to
the latest versions that the setup application allows me, on the
assumption that somehow I managed to get an old version of a
library during my last update, but nothing I have done restores the
static destructor output. From cygcheck, here are the versions of
things I think might matter:
gcc 3.4.1-1
gcc-ada 3.4.1-1
gcc-core 3.4.1-1
gcc-g++ 3.4.1-1
gcc-g77 3.4.1-1
gcc-java 3.4.1-1
gcc-mingw20040810-1
gcc-mingw-ada20040822-1
gcc-mingw-core 20040822-1
gcc-mingw-g++20040822-1
gcc-mingw-g7720040822-1
gcc-mingw-java 20040822-1
mingw-runtime3.7-1
Anyone have any idea how I managed to do this to myself and,
more importantly, how I can undo it?
Thanks!
sorry ---
#include stdio.h
struct S
{
S();
~S();
} ;
S::S()
{
printf(In ctor.\n);
}
S::~S()
{
printf(In dtor.\n);
}
int
main()
{
struct S t;
printf(In main.\n);
t;
return (0);
}
--
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: ls finds file1 but ls file1 does not
Original Message From: Charles D. Russell Sent: 09 May 2005 20:07 ls finds file1 but ls file1 does not. How can this happen? The following example occurred just after I had renamed some *.htm files to *.html using an ash shell script. No such problem occurred, however, when I used DOS rename to make the same change. Not 100% sure what's going on here, but can I just ask one thing? $ ls _index.htm*finder.dat* lib_over.htm* setjmp.htm* time.htm* assert.htm*float.htm* lib_prin.htm* signal.htm* types.htm* charset.htm* function.htm* lib_scan.htm* stdarg.htm* wchar.htm* [etc] Did your ash script go wrong and rename all those files with actual asterisks on the end ? Documents/books_open/c/stdcbook_bad/STD_c $ ls assert.htm ls: assert.htm: No such file or directory -- THIS IS THE PROBLEM But ISTM there is no such file as assert.htm. What output do you get from ls assert.htm\* ? 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: Static destructors not running
Original Message
From: William M. (Mike) Miller
Sent: 09 May 2005 23:46
I'm sure this is the result of my having done something stupid
with the setup application, but suddenly static destructors no
longer run. That is, for the following program:
#include stdio.h
struct S {
S();
~S();
} s;
S::S() {
printf(In ctor.\n);
}
S::~S() {
printf(In dtor.\n);
}
int main() {
printf(In main.\n);
}
the output is
In ctor.
In main.
The output In dtor. is missing.
That's because stdout is already closed by the time your dtor runs. I
stepped right into it, it does the printf call but somewhere down in the dll
it checks the flags field in the stdout FILE object for read/write and finds
it's not open for either, so it's at eof. Grep 'cantwrite' if you really
want to find it.
Anyway, your dtor is called.
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: ls finds file1 but ls file1 does not
ls finds file1 but ls file1 does not. How can this happen? The following example occurred just after I had renamed some *.htm files to *.html using an ash shell script. No such problem occurred, however, when I used DOS rename to make the same change. Not 100% sure what's going on here, but can I just ask one thing? $ ls _index.htm* finder.dat* lib_over.htm* setjmp.htm* time.htm* assert.htm* float.htm* lib_prin.htm* signal.htm* types.htm* charset.htm* function.htm* lib_scan.htm* stdarg.htm* wchar.htm* [etc] Did your ash script go wrong and rename all those files with actual asterisks on the end ? Documents/books_open/c/stdcbook_bad/STD_c $ ls assert.htm ls: assert.htm: No such file or directory -- THIS IS THE PROBLEM But ISTM there is no such file as assert.htm. What output do you get from ls assert.htm\* ? ls is acting like the -F option is specified which would cause the '*' to be displayed at the end of any file name which is executable (as one prior message shows these files are). Under what shell is ls being run and is there an alias for ls that is causing this option to be invoked? If so, are there any other options in the alias? -- 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/
ls finds file1 but ls file1 does not
Response 2 to Eric Blake: Thanks. I forgot that unix had separate permissions for directories. However, I have now given myself all the permissions I know of and I still have the same problem. EXAMPLE: $ ls ass* ls: ass*: No such file or directory --BUT IT IS THERE $ ls -l total 722 -rwxrwxrwx+ 1 cdr None58614 Oct 12 1995 _index.htm* -rwxrwxrwx+ 1 cdr None 2177 Oct 12 1995 assert.htm* #Next thing to check - do you have shell globbing disabled or filtered? (For more info on #these options, read `man bash'.) #$ echo ignoring:$GLOBIGNORE options:$- #$ shopt | grep glob ___ I haven't yet puzzled out these commands, but I'm forwarding the results anyway. I doubt this is the problem, since similar results occur without globbing, and I can't imagine how my defaults could get mucked up. The installation is several years old, apart from upgrades. $ echo ignoring:$GLOBIGNORE options:$- ignoring: options:himBH $ shopt |grep glob dotglob off extglob off nocaseglob off nullgloboff #If GLOBIGNORE includes *.htm or the builtin set includes -f, bash will not expand *, but #instead looks for the literal file named ass*, which does not exist. I'm also guessing #that nullglob is off, otherwise bash would expand the failed * into no arguments at all, #which would cause a full directory listing, rather than passing the literal string with * #on to ls. _ Same problem occurs with no globbing (I was using * only to avoid spelling errors): $ ls assert.htm ls: assert.htm: No such file or directory By the way, where can I find documentation for the command $ stat -c %A . in your first post? The only stat command I can find is a C system call. $ stat bash: stat: command not found -- 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/
ls finds file1 but ls file1 does not
Original Message From: Charles D. Russell ls finds file1 but ls file1 does not. How can this happen? The following example occurred just after I had renamed some *.htm files to *.html using an ash shell script. No such problem occurred, however, when I used DOS rename to make the same change. Not 100% sure what's going on here, but can I just ask one thing? $ ls _index.htm*finder.dat* lib_over.htm* setjmp.htm* time.htm* assert.htm*float.htm* lib_prin.htm* signal.htm* types.htm* charset.htm* function.htm* lib_scan.htm* stdarg.htm* wchar.htm* [etc] Did your ash script go wrong and rename all those files with actual asterisks on the end ? Documents/books_open/c/stdcbook_bad/STD_c $ ls assert.htm ls: assert.htm: No such file or directory -- THIS IS THE PROBLEM But ISTM there is no such file as assert.htm. What output do you get from ls assert.htm\* ? _ $ ls assert.htm\* ls: assert.htm*: No such file or directory The * in the listing just indicates that the file is executable (an ls option that I use by default). Unaliasing gives: $ \ls _index.htmfinder.dat lib_over.htm setjmp.htm time.htm assert.htmfloat.htm lib_prin.htm signal.htm types.htm charset.htm function.htm lib_scan.htm stdarg.htm wchar.htm crit_pb.htm giflimits.htm stddef.htm wctype.htm ctype.htm index.htm locale.htm stdio.htm junk declare.htm intro.htm math.htm stdlib.htm errno.htm iso646.htm portable.htm string.htm express.htm lib_file.htm preproc.htmsyntax.htm -- 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: ls finds file1 but ls file1 does not
$ echo ignoring:$GLOBIGNORE options:$- ignoring: options:himBH $ shopt |grep glob dotglob off extglob off nocaseglob off nullgloboff OK, bash is not filtering the glob. But you are obviously using an alias or function for ls, since it is acting like the -F option is implicitly applied (seeing the * at the end of your files). So next, check: $ type ls $ alias ls Maybe you have an alias/function for ls that includes the --hide='*.htm' option, so that ls is doing the filtering (and not bash, like I guessed before). Also, you can escape the program name to overcome the alias - try this: $ \ls as* If it still fails, then it is back to permissions problems that are beyond me - your new ACLs don't seem to show any problems. One last possibility is whether you have a Windows setting that auto-bundles html files into an invisible directory, so that when cygwin tries to list the directory contents, it gets a different list then directly spelling the listed filenames. By the way, where can I find documentation for the command $ stat -c %A . in your first post? The only stat command I can find is a C system call. $ stat bash: stat: command not found What version of coreutils are you using? Attach the output of `cygcheck -svr' as described in cygwin.com/problems.html, then consider upgrading. It may also be an old version of cygwin that has since been fixed that is giving you the ls error. stat(1) is provided by coreutils, as a nice wrapper around the stat(2) system call. Once you have upgraded, `stat --help' or `info coreutils stat' will tell you more. -- Eric Blake -- 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: sshd owned by root error
On 5/9/05, Corinna Vinschen wrote: On May 6 16:42, Christopher Faylor wrote: On Fri, May 06, 2005 at 12:41:55PM -0400, Igor Pechtchanski wrote: On Fri, 6 May 2005, Ordal, Peter wrote: This has been discussed several places before, I know. Still, I had a different experience than previous posts. I found that what owned by root meant was actually owned by the account running sshd. So, when I ran /usr/sbin/sshd -D under my domain account, I had to chown /var/empty to my account. The above might be a good candidate for the FAQ... I think the error message should probably be changed instead, although I suspect that the upstream openssh maintainers might balk at that. They will, no doubt about it. The test for ownership is generally guarded by a test for the root user. Only on Cygwin the test also tests for the user running sshd. So that's FAQ fodder. This issue seems closely related to the Why doesn't su work? FAQ at: http://cygwin.com/faq/faq0.html#SEC42; perhaps I will expand that entry. -- 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/
ls finds file1 but ls file1 does not
Ross Boulet wrote: ls is acting like the -F option is specified which would cause the '*' to be displayed at the end of any file name which is executable (as one prior message shows these files are).? Under what shell is ls being run and is there an alias for ls that is causing this option to be invoked?? If so, are there any other options in the alias? _ This has been my default for years so I give it no thought but doubt it is doing anything unexpected: $ alias ls alias ls='ls -aF' I use bash for terminal interaction, \bin\sh for shell scripts. -- 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: sqlite / pysqlite ... RFC/ITP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Schormann wrote: I'm not sure just *how* off-topic this is, let's see ... AFAIK, ITP usually go to the cygwin-apps ML. - Is anyone else actually interested in this, or might I be better off to keep it to my own? FWIW, I would definitely be interested in a sqlite3 (and sqlite2, still in wide use e.g. by PHP scripts) package. - Reini, will the sqlite package ever be part of the standard cygwin mirrors, or would I have to maintain that, too? Is there any serious reason against uploading it? If you ITP and produce an usable package it automatically gets uploaded on Cygwin mirrors and is installable using setup.exe, yes. but also for each version of the cygwin dll itself. I'm not aware of any big backward-compatibility issue with cygwin1.dll that would require multiple versions, but I guess this question should go mainly to Reini...? Note also that this would be my first ITP ever. As Wikipedia people put it Be bold! ;-) Lapo - -- L a p o L u c h i n i l a p o @ l a p o . i t w w w . l a p o . i t / -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkKAROkACgkQaJiCLMjyUvtHEACdG6S53psvXqDrRyBCfBt/mGHh TTcAnAgnZZPdSlXLLqgDI7DDKpE+3hnT =b6Uv -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/
ls finds file1 but ls file1 does not
Eric Blake wrote: So next, check: $ type ls $ alias ls ___ $ type ls ls is aliased to `ls -aF' $ alias ls alias ls='ls -aF' __ Maybe you have an alias/function for ls that includes the --hide='*.htm' option, so that ls is doing the filtering (and not bash, like I guessed before). Also, you can escape the program name to overcome the alias - try this: $ \ls as* ___ $ \ls assert.htm ls: assert.htm: No such file or directory $ \ls as* ls: as*: No such file or directory ___ If it still fails, then it is back to permissions problems that are beyond me - your new ACLs don't seem to show any problems. One last possibility is whether you have a Windows setting that auto-bundles html files into an invisible directory, so that when cygwin tries to list the directory contents, it gets a different list then directly spelling the listed filenames. By the way, where can I find documentation for the command $ stat -c %A . in your first post? The only stat command I can find is a C system call. $ stat bash: stat: command not found What version of coreutils are you using? Attach the output of `cygcheck -svr' as described in cygwin.com/problems.html, then consider upgrading. It may also be an old version of cygwin that has since been fixed that is giving you the ls error. stat(1) is provided by coreutils, as a nice wrapper around the stat(2) system call. Once you have upgraded, `stat --help' or `info coreutils stat' will tell you more. __ I am attaching cygcheck in case you can find something obvious. However,I am reluctant to upgrade because the use of large static fortran arrays with cygwin/g77 seems to be a fragile issue and my current installation is now working (but only with -mno-cygwin). From this mailing list, there is clearly a problem, but I have seen no explanation or remedy from the experts, just at best another user saying this worked for me. Cygwin Configuration Diagnostics Current System Time: Mon May 09 23:35:14 2005 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: .\ C:\cygwin\home\cdr\script C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\System32\Wbem c:\Program Files\Common Files\Sonic Shared\Ligos\GoMotion c:\Program Files\Common Files\Sonic Shared\Ligos\Decoders c:\Program Files\Common Files\Sonic Shared\MainConcept c:\Program Files\Common Files\Adaptec Shared\System C C:\cygwin\ut Output from C:\cygwin\bin\id.exe (nontsec) UID: 1007(cdr) GID: 513(None) 513(None) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1007(cdr) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\cdr' MAKE_MODE = `unix' PWD = `/home/cdr/junk' USER = `cr' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\cdr\Application Data' AR = `ar' ARCDIR = `/home/cdr/cygarc' ARCEXT = `.tar' ARCFLAGS = `--posix -cf' ARCMGR = `tar' ARFLAGS = `rv' BIGSTACK = `-Wl,--stack,0x40' BINDIR = `/usr/local/bin' CC = `gcc' CFLAGS = `-g -DALPHA -ansi' CLIENTNAME = `Console' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DELL03' COMSPEC = `C:\WINDOWS\system32\cmd.exe' CR = `/home/cdr' CRTMP1 = `/home/cdr/tmp1' CRTMP = `/home/cdr/tmp' CRW = `/cygdrive/c/Documents and Settings/cdr/My Documents' CRWP = `'/cygdrive/c/Documents and Settings/cdr/My Documents'' CVS_RSH = `/bin/ssh' ETCDIR = `/home/cdr/etc' FC = `g77' FCHEK = `c:/d/bin/ftnchek' FCHEKFLAGS = ` -sixchar -nonovice -noverbose -nopretty -usage=1 -notruncation -array=0 -library -noextern ' FFLAGS = `-ggdb -fbounds-check -march=pentium -fno-automatic -fugly-assumed -w' FPP = `fpp' FP_NO_HOST_CHECK = `NO' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\cdr' HOSTNAME = `dell03' INCDIR = `/usr/local/include' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' JRW = `/cygdrive/c/Documents and Settings/Judith Russell/My Documents' LARCH_PATH = `/usr/local/bin/lclintlib' LCLIMPORTDIR = `/usr/local/bin/lclintimp' LIBDIR = `/usr/local/lib' LINT = `lclint' LINTFLAGS = `-I/usr/local/include:/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/include' LOGONSERVER = `\\DELL03' MAKEFIG = `/home/cdr/config.mk' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' MINGW = `-mno-cygwin' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/home/cdr' OS = `Windows_NT' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PPFLAGS = `-C -P -traditional' PRINTER = `HP OfficeJet R40xi' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0207' PROGRAMFILES =
