RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
> From: Andrey Repin > Mode on the *nix side seems unimportant, as Samba fakes ACL, if client do not understand native > modes. It is unimportant if the samba share is just a file server for Windows machines. But if you also work on 'nix machines, locally on that server or via nfs, then you want modes that actually make sense from a 'nix POV. "All files are executable" does not qualify... Greetings, (s) M. Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
> From Andrey Repin [snip] >> 0744 for global, 0755 for homes (the relevant share in my case), 0022 >> as cygwin umask. Sorry, correction: create mask 0744, create mode 0755. Which does help my confusion: >> I would expect files created on the cygwin side to have 0755 on the >> linux side (or possibly masked by global and/or umask). I do not see >> how I end up with 0764. [snip] > Another point of note: from my memory, samba fakes ACLs to represent permissions. This may include > many strange things. > For example, most of that ^^ directory content has 0777 perms, but when I look from Cygwin, it > coming out more granular. Which is why in this discussion I have always checked the mode on the nix side, using ssh. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
> Greetings, Michel Bardiaux! > >> I have also tried the same as you did (len.sh on a samba share) and >> saw the same problem. Then I saw that the len.sh got a (cygwin *and* >> linux) mode of -rwxrw-r-- *without* doing any chmod. Then I saw that >> *every* file I create on the samba share, gets the same mode! > > testparm -s > please. Yes, this explains a lot - but not completely. The relevant lines being the create masks: 0744 for global, 0755 for homes (the relevant share in my case), 0022 as cygwin umask. I would expect files created on the cygwin side to have 0755 on the linux side (or possibly masked by global and/or umask). I do not see how I end up with 0764. Greetings, (s) M. Bardiaux Load smb config files from /etc/samba/smb.conf Processing section "[home]" Processing section "[homes]" Processing section "[www]" Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER [global] dos charset = CP850 unix charset = UTF-8 display charset = LOCALE workgroup = MDB realm = netbios name = BESDEV01 netbios aliases = netbios scope = server string = Samba 3.0.24 interfaces = bind interfaces only = No security = DOMAIN auth methods = encrypt passwords = Yes update encrypted = No client schannel = Auto server schannel = Auto allow trusted domains = Yes map to guest = Never null passwords = No obey pam restrictions = No password server = besprd01 smb passwd file = /etc/samba/smbpasswd private dir = /etc/samba passdb backend = smbpasswd algorithmic rid base = 1000 root directory = guest account = pkdev enable privileges = Yes pam password change = No passwd program = passwd chat = *new*password* %n\n *new*password* %n\n *changed* passwd chat debug = No passwd chat timeout = 2 check password script = username map = password level = 0 username level = 0 unix password sync = No restrict anonymous = 0 lanman auth = Yes ntlm auth = Yes client NTLMv2 auth = No client lanman auth = Yes client plaintext auth = Yes preload modules = use kerberos keytab = No log level = 0 syslog = 0 syslog only = No log file = /var/log/samba/log.%m max log size = 1000 debug timestamp = Yes debug hires timestamp = No debug pid = No debug uid = No enable core files = Yes smb ports = 445 139 large readwrite = Yes max protocol = NT1 min protocol = CORE read bmpx = No read raw = Yes write raw = Yes disable netbios = No reset on zero vc = No acl compatibility = auto defer sharing violations = Yes nt pipe support = Yes nt status support = Yes announce version = 4.9 announce as = NT max mux = 50 max xmit = 16644 name resolve order = lmhosts host wins bcast max ttl = 259200 max wins ttl = 518400 min wins ttl = 21600 time server = No unix extensions = Yes use spnego = Yes client signing = auto server signing = No client use spnego = Yes enable asu support = No svcctl list = deadtime = 0 getwd cache = Yes keepalive = 300 kernel change notify = Yes fam change notify = Yes lpq cache time = 30 max smbd processes = 0 paranoid server security = Yes max disk size = 0 max open files = 1 open files database hash size = 10007 socket options = TCP_NODELAY use mmap = Yes hostname lookups = No name cache timeout = 660 load printers = Yes printcap cache time = 750 printcap name = cups server = iprint server = disable spoolss = No addport command = enumports command = addprinter command = deleteprinter command = show add printer wizard = Yes os2 driver map = mangling method = hash2 mangle prefix = 1 max stat cache size = 0 stat cache = Yes machine password timeout = 604800 add user script = rename user script = delete user script = add group script = delete group script = add user to group script = delete user from group script = set primary group script = add machine script = shutdown script = abort shutdown script = username map script = logon script = logon path = \\%N\%U\profile logon drive =
RE: Building for nocygwin
> As Earnie wrote, now you should use the appropriate mingw32 or mingw64 cross > compiler, > both of which are available as part of the Cygwin distro. > This *is* the general solution. I *get* that. My problem was, the web is so cluttered with pages mentioning the no-cygwin thing (including the cygwin FAQ!) that finding a good howto is nearly impossible. Lots of pages about running the mingw toolchain on mingw/msys, but at some point in the past I had installed cygwin *and* msys, and managing the path, the profile scripts, etc was a real pain, so never again. With the benefit of Csaba's hint, the basic recipe is now: 1. Install mingw-gcc-core (which pulls other necessary packages) 2. i686-pc-mingw32-gcc -o jef.exe jef.c With that under my belt, I can start thinking about adding spices, herbs, truffles, and soy sauce :-) Is there a deep reason not to amend the FAQ?
RE: Building for nocygwin
[snip] > That is the "general solution". The error message was appropriate and gave a > clue. Beyond that > you'll need to communicate a patch to the maintainers of the package that is > still using -mno-cygwin. Let me rephrase. gcc-3 -mno-cygwin -o foo.exe foo.c under cygwin, works to create a windows executable that does not reference the cygwin dlls. (provided of course that foo.c does not call any APIs that can only be provided by cygwin, like fork). That *was* a general solution. What is the equivalent using gcc-4 under cygwin?
RE: Building for nocygwin
[snip] > Sure, --host=i686-pc-mingw32 or some other appropriate host string during > configure. > You'll need to make sure you have the appropriate files for cross compiling. > The -mno-cygwin has been gone for some months moving into years. That much I could guess. I am pretty sure I could muddle through until I can configure and build, say, libav. I was hoping for a general solution. (s) M. Bardiaux
FW: cygwin 1.7.13-1: can't execute shell scripts on samba share
Sorry, forgot to change the recipient. -Original Message- > [snip] > >> lgiambro@lorien ~ >> $ cat len.sh >> #!/bin/sh >> echo it works > > And man sh states " --norc Do not read and execute the personal > initialization file ~/.bashrc if the > shell is interactive. This option is on by default if > the shell is invoked > as sh." > Which eliminates bashrc as a possible culprit. > bash as sh will use ~/.profile in interactive and -login mode. Yes, I forgot about .profile. The OP should check his .profile does nothing that could cause it to fail when the current directory is a samba share. > My guess is the remote disk handler is causing Cygwin to not see the file as > executable. Then why would getfacl, and ls, say it *is* executable? (In the OP case; in my case you are absolutely right).
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] >> Y: /cygdrive/y smbfs binary,noacl,auto 0 0 > That won't work. Don't try to overload the cygdrive prefix for single > drives, that's not supported. Ooops. How do I restore the normal default? It no longer appears in 'mount'. > Use something like > Y: /my_y_drive whatever binary,noacl 0 0 Yep, that worked.
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] > You could mount the samba share with "noacl", > see http://cygwin.com/cygwin-ug-net/using.html#mount-table > Corinna Thanks for the suggestion. I have added this to /etc/fstab: Y: /cygdrive/y smbfs binary,noacl,auto 0 0 Closed all cygwin windows, reopened one (mintty), mount says: C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) Y: on /cygdrive/y type smbfs (binary,noacl) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type smbfs (binary,posix=0,user,noumount,auto) created (again...) len.sh on the samba drive, and again: $ getfacl len.sh # file: len.sh # owner: # group: user::rwx group::rw- mask:rwx other:r-- Curiouser and curiouser: the file begins with #!, hence with noacl it should be executable by anyone, right? But I still have permission denied, unless I chmod 777. BTW: I am now playing around with execute mode and samba drives to help solve the OP's problem, maybe find a bug. I actually use cygwin with ssh, scp, svn, etc. so that I do *not* have to cope with the idiosyncrasies of multiple security layers: windows + samba + linux. So, adding a 4th one is akin to masochism! Greetings, (s) M. Bardiaux
Building for nocygwin
A number of open-source projects (a.o. libav) indicate the use of -mnocygwin to build, on cygwin, libraries or executables that do not need the cygwin dll Section 6.10 of the FAQ also says so, but also states "This section has not yet been updated for the latest net release.". And indeed, gcc 4.5.3 just kicks you out with "The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.". Using gcc-3, or setting it using /etc/alternatives, works but of course it is better to use the more recent compiler. Could someone publish the appropriate recipe? TiA, (s) Michel Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
[snip] > lgiambro@lorien ~ > $ cat len.sh > #!/bin/sh > echo it works And man sh states " --norc Do not read and execute the personal initialization file ~/.bashrc if the shell is interactive. This option is on by default if the shell is invoked as sh." Which eliminates bashrc as a possible culprit. I have also tried the same as you did (len.sh on a samba share) and saw the same problem. Then I saw that the len.sh got a (cygwin *and* linux) mode of -rwxrw-r-- *without* doing any chmod. Then I saw that *every* file I create on the samba share, gets the same mode! First things first, is there a workaround? Yes, chmod 777 len.sh *done on linux* works. And it actually works too when done on cygwin. However, recreating len.sh on cygwin, then a chmod 700 len.sh again on cygwin, does not work, again "./len.sh: Permission denied". But the mode seen on the linux side is -rwx--. I have also tried deleting then recreating the file in cygwin, then closing all cygwin processes and unmapping and remapping the samba drive. No cigar. Then I tried cacls in various situations. It turns out that with mode 777, cacls reveals "Everyone:F", but with mode 700 we get: len.sh F (special access:) Everyone:(special access:) And getfacl says: # file: len.sh # owner: # group: user::rwx group::--- mask:rwx other:--- Now I would say cygwin behaves as expected in my case: owner has execute permission, but who is the owner? Unfortunately this can only be *part* of the explanation, since for the OP it is # file: len.sh # owner: lgiambro # group: releng user::rwx group::--- mask:rwx other:--- (see thread head for the cacls). His samba setup is obviously better than mine. But now I cant be sure my workaround (mode 777) will work in his case. Hope these can help. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: cygwin 1.7.13-1: can't execute shell scripts on samba share
2 suggestions: 1. What happens if len.sh is in your Cygwin home, that is on the local drive? 2. What happens with "sh -x ./len.sh" (on the network drive)? HaND, -Original Message- No. That works. presumably because it's executing "bash" and not the script itself. -Len On Apr 18, 2012, at 1:49 PM, Earnie Boyd wrote: > On Wed, Apr 18, 2012 at 11:44 AM, Len Giambrone > wrote: >> I'm can't execute shell scripts on a samba share served by our linux boxes. >> >> lgiambro@lorien //kitserver/kits >> $ ls -la len.sh >> -rwx-- 1 lgiambro releng 24 Apr 18 10:48 len.sh >> >> lgiambro@lorien //kitserver/kits >> $ cat len.sh >> #!/bin/sh >> echo it works >> >> lgiambro@lorien //kitserver/kits >> $ ./len.sh >> -bash: ./len.sh: Permission denied > > I suppose the same happens if you execute len.sh similar to the following? > > $ bash -x ./len.sh > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [ANNOUNCEMENT] New package: _autorebase. Call rebaseall after installing new or updated DLLs
> I've added a new package called _autorebase to the Cygwin distro. This works very well indeed. After reinstalling setup and catching up with 1 month of updates, bringing me from uname 1.7.10 to 1.7.11 (which means autorebase MUST have done something, right?) I have just made a moderately large make (of what does not matter) of 48 source files using "make -j" (unlimited parallelism) on a not-so-large PC (dual 2GHz, 2GB) with all the Avast! filters turned on. The system froze nearly solid for 5 minutes but actually completed the build with no fork misses whatsoever. Congrats!
RE: aplus-fsf (XWarpPointer)
[snip] > -L../../src/MSTypes -L -lX11 -lpthread -ldl -lm mainC.o aplus_main.o aplus_uext.o matherr.o [snip] Problem here ...^^^ Literally it means "gcc please also look for libraries in directory -lX11", effectively gobbling up -lX11 (no, you don't get a message because the directory -lX11 does not exist!). Either a bug in the configure file (& bros.) for aplus, or it expects you to specify some variable that has to be expanded after the -L, maybe the path to the X libraries? Try configure --help. HaND, Michel Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: aplus-fsf (XWarpPointer)
> My current stumbling block: > When compiling aplus-fsf-4.22/src/main/aplus_main.c > I get many errors related to X11. > > case in point: > undefined reference to '_XWarpPointer' in AGIF.o Not a *compile* problem but a *link* problem. Probably missing -lX11. What is the last, failing, command executed by your build process? HaND, Michel Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: sys/filio.h
> [...] Can you either confirm that the defined variable is named "cygwin", or tell me what the > actual name is? __CYGWIN__ (*2* underscores, twice) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FW: Unfolding the stack
[snip] > This is hard in C, and harder in code compiled by gcc [snip] I know that, and am willing to accept the risk since any info is better than none. I just wish for a more efficient mechanism than I am now using. > If you're using C++, [snip] Nope. > Alternatively, you could compile with -g and try to traverse the debug info tables gdb uses to work > around everything nasty gcc does, but there's no clean API there that I know of. Since cygwin_stackdump does not dare to tread there... > Out of curiosity, what is your library currently using to generate backtraces? Well you just snipped it: pipe/fork/dup to catch the stderr of cygwin_stackdump called in the forked process. > There's a backtrace facility in glibc (man backtrace), but it's got a > long list of caveats as well, > including death by -fomit-frame-pointer (it doesn't use any debug/unwind info emitted by the compiler). In what package? I have cygwin basics + gcc installed, and no backtrace in any .h. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unfolding the stack
To complete the port of some library to Cygwin, I need a way to produce
a traceback with as much info as possible. Currently I have something
that works but not that well. There are basically 3 parts:
* Gather all the stack frames; see below.
* Assign the PCs in each frame to some executable image; done via dlfcn.
To be discussed later.
* Convert the PCs to function+source+line; done via addr2line. Ditto.
Despite a lot of web digging I have not (yet?) found a better way than
this classic unixish song-and-dance:
int
backtrace(void** buf, int bufsiz)
{
int res;
int p[2];
pid_t child;
FILE* thePipe = (NULL);
charline[1024];
void* unused;
if (pipe(p) < 0){
debug(-1, "*** Pipe() failed\n");
return -1;
}
if ((child=fork())<0) {
debug(-1, "*** Fork() failed\n");
return -1;
} else if (child == 0) {
// In child. Make p[1] its stderr
close(0);
close(1);
dup2 (p[1], 2);
close (p[0]);
close (p[1]);
cygwin_stackdump();
exit(0);
}
// In our process. Read from the pipe.
close (p[1]);
if((thePipe=fdopen(p[0], "rb"))==NULL) {
debug(-1, "*** fdopen failed\n");
return -1;
}
res = 0;
while(fgets(line, sizeof(line), thePipe)) {
if(res>=bufsiz)
break;
while(isspace(line[strlen(line)-1]))
line[strlen(line)-1]=0;
if(strcmp(line, "Stack trace:")==0 ||
strncmp(line, "Frame", 5)==0)
continue;
if(strcmp(line, "End of stack trace")==0)
break;
if(sscanf(line, "%8X %8X", (int*)&unused,
(int*)(buf+res))!=2) {
debug(-1, "*** sscanf failed\n");
return -1;
}
res++;
}
fclose(thePipe);
return res;
}
Where debug(-1,...) is essentially fprintf(stderr,...).
Now this is acceptable for a traceback following the raising of some
error condition, but seems much too heavy for using in a leak detector.
Does anyone know of an equivalent API under cygwin? Or could we consider
adding such a variation of cygwin_stackdump to the cygwin DLL?
TiA
Michel Bardiaux
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Oracle OCI under cygwin
> Cygwin applications don't use the WIN32 environment. Rather they have
> their own copy of the environment in a POSIX layout. What happens is
> probably that the OCI lib calls GetEnvironmentString ("TNS_ADMIN",...)
> and gets nothing back, since the variable is just not in the Win32
> environment of the Cygwin application.
>
> The workaround is to do this before calling ani OCI lib function:
>
> #include
>
> cygwin_internal (CW_SYNC_WINENV);
>
> This call copies the POSIX environment over to the Win32 environment
> of the calling process, so the OCI lib functions should find the
> TNS_ADMIN variable when called *after* the above call.
This worked like a charm. Thank you.
I suppose the same should be done whenever one calls a function in a non-cygwin
DLL that relies on Win32 environment variables?
Oracle OCI under cygwin
I have an up-to-date cygwin on XP SP3 (and yes, rebasealled). I have also installed the Oracle basic (NOT instant) client for Win32. And I have a C application that queries an Oracle DB using OCI. Another relevant bit of setup info: environment variable TNS_ADMIN = \\besprd01\techdoc\database\oracle\OracleNet_WinClient (set in XP Control Panel). Now, when compiled with MS Visual Studio 2010 Express, and run from a DOS (sic) box, the app works fine, which proves both the app and the setup are basically fine. Ditto when run from a Cygwin mintty. But if I compile my app with cygwin, and run it in mintty (of course), I get an error message meaning essentially that OCILogon failed because it did not find an Oracle config file called tnsnames.ora that is supposed to be in $TNS_ADMIN. Strace gives no clue - because the app WORKS when run by strace! The Win32 PROCMON shows that tnsnames.ora is looked for in %TNS_ADMIN% for the pure win32 app, but in the local directory for the cygwin app. Indeed, if I kluge my code in the cygwin case to temporarily chdir to $TNS_ADMIN (rewritten as a cygwin path of course) just before calling OCILogon, it works. So, it is all rather mysterious. My guess is that some magic is done inside cygwin that intercepts some "system calls" (though there is not really such a thing in Windows) made by the Oracle libs and transforms them in some way. But I am not familiar enough with cygwin internals to go much farther (besides, my C++ is minimal). Help? Please? Pretty please? (s) Michel Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: FAQ #4.43
> On Feb 21 14:24, Michel Bardiaux wrote: >> You can add to the BLODA list: >> >> AVAST! (www.avast.com). But no need to desinstall; just disable >> permanently the FILESYSTEM and BEHAVIOR realtime shields. The others >> (web, p2p, mail, IM) do not seem to interfere with cygwin. > > Thanks, I added that to the FAQ. > > > Corinna Additional info: after rebaseall, I have had absolutely no fork failures at all even with ALL AVAST! shields enabled.
FW: Env variable USER
> On Thu, Feb 23, 2012 at 8:22 AM, Michel Bardiaux wrote: >> >> 1. Is USER supposed to be set? > > Yes. > >> 2. If yes, by what script or process? > > /etc/profile Then mine is indeed damaged, it contains just this: PATH="/usr/local/bin:/usr/bin:/bin:$PATH" Looks like it was *lost* and this was a pathetic attempt by me at recreating it. But with your info I could do a web search (could not before, cygwin+variable+USER finds way too many hits) and that led me to /etc/defaults/etc/profile. Thanks again.
Env variable USER
It seems that my latest frenzy of setups (the ones that first screwed
up, then failed to fix, then at last fixed, coreutils) had some nasty
side effects. The first I see is that USER is no longer defined in the
environment, at least for bash in mintty. Quite likely one of the bash
config files in /etc that is supposed to set it up (at least I assume
supposed to!), has been damaged, but has not been rebuilt because setup
considers it a "customized" file.
Note that I am 100% sure USER *was* set about 1 week ago, since an app
that worked then, now crashes because getenv("USER") return NULL.
Hence, 2 (related) questions:
1. Is USER supposed to be set?
2. If yes, by what script or process?
Tia
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FAQ #4.43
You can add to the BLODA list: AVAST! (www.avast.com). But no need to desinstall; just disable permanently the FILESYSTEM and BEHAVIOR realtime shields. The others (web, p2p, mail, IM) do not seem to interfere with cygwin. Michel Bardiaux -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Unable to install coreutils 8.15-1(?) - error in coreutils.sh exit code 127
> On 2/20/2012 12:35 PM, Eric Blake wrote: >> That link error is typically a sign of cygwin1.dll being too old >> compared to what coreutils 8.15 is expecting. Are you sure your >> cygwin1.dll comes from 1.7.10, and that it wasn't in-use when you >> upgraded in such a manner that you are still running cygwin 1.7.9 in memory? > Interesting. uname -a is reporting 1.7.9. You might be right! I'll try to find a time to reboot and > check this out. I had the same problem yesterday after trying to install "chere": cygwin executables not doing anything, but cygcheck saying all packages OK. After a lot of floundering, FAQing, web searches, trying to force reinstall of coreutils 8.15, then forcing reinstall from local disk of everything, still no cigar. Reading this thread this morning put me on the right track: force downgrade of coreutils to 8.14-1. Then cygwin works again, but that can only be a temporary fix, since every time one runs setup, it upgrades coreutils to 8.15... Anyway, after reboot, uname -a says 1.7.9-1. And indeed, opening cygwin1.dll in "dependency walker" (a Win32, not a cygwin, tool) shows that sys_siglist is not defined. But cygcheck states that 1.7.10-1 is installed! Hence I forced reinstall of pkg "cygwin" (while it upgrades coreutils). Now everything is fine. I suppose we'll never know what began the problem. Still, cygcheck should NOT have reported 1.7.10-1 as OK when it was not... Thanks to the whole cygwin community for help on this in particular, and for a fine ware in general. Michel Bardiaux --- "As far as I can see all I see is C" -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
