Re: Cannot exec() program outside of /bin if PATH is unset
In message CAMCbSMrar1Zu4p6gN=gc8-xqe-8rutmp3er0ujen--chkzc...@mail.gmail.com
you write:
This might the way the pkgIndex.tcl file for this particular extension
has been implemented, but like Jan says, that is not the Tcl way.
Here is a sample that illustrates the more acceptable procedure:
# Tcl package index file, version 1.0
if {![package vsatisfies [package provide Tcl] 8.6]} {return}
package ifneeded itcl 4.0b7 [list load [file join $dir itcl40b7.dll] itcl]
package ifneeded Itcl 4.0b7 [list load [file join $dir itcl40b7.dll] itcl]
The variable dir is set by the package management subsystem and the
effect is that the _full_ path is constructed before the DLL is
actually loaded.
Regards,
Arjen
2014-10-10 13:24 GMT+02:00 Jan Nijtmans jan.nijtm...@gmail.com:
2014-10-10 12:34 GMT+02:00 Corinna Vinschen corinna-cyg...@cygwin.com:
On Oct 9 11:46, tedno...@bellsouth.net wrote:
I'm pretty sure I've got some programs loading Tcl extensions that
cd into the directory with the extension dlls, load the extension and then
change back to where ever they were.
Hmm. If so, it's quite a weird way to handle this, rather than
loading the modules with full path.
Is that a Tcl feature, or is it how certain Tcl apps are implemented?
I can't really believe the former...
This is certainly not a Tcl feature! The standard Tcl extension
mechanism always uses the full path simply because Tcl
cannot depend on platform-specific ways to search for
such libraries elsewhere.
I'm willing to test this;I don't believe such a change
will break anything in my Tcl environment.
Regards,
Jan Nijtmans
Hmm,
It's been a while, but I think it is something like the extension is
a DLL, but it depends on another DLL. Consider for instance, mysqltcl.
If you want to deploy that, you need the mysqltcl.dll and the mysql dll,
so you either have to be in the same dir when you load the extension,
or put that dir in PATH.
Unfortunately, I can't run a test release on my work machine, or take
my work progs home.
--
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: Cannot exec() program outside of /bin if PATH is unset
In message 20141009162906.ga25...@calimero.vinschen.deyou write: Any other idea what *might* be broken if we remove CWD from the DLL search path? Corinna I'm pretty sure I've got some programs loading Tcl extensions that cd into the directory with the extension dlls, load the extension and then change back to where ever they were. -- 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
ezmlm problems with yahoo/ATT senders
I've tried reporting this several different ways, apparently into a black hole, so I'll try it here on the front list. I preiodically get messages from ezmlm to the effect Hi! This is the ezmlm program. I'm managing the cygwin#cygwin.com mailing list. Messages to you from the cygwin mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. The referenced attached message is from the Yahoo/ATT mailer and the key thing is an error message + URL, which apparently ezmlm never passes to anyone responsible: Permanent Failure: 554 REPLY: 554_5.7.9_Message_not_accepted_for_policy_reasons. See_http://postmaster.yahoo.com/errors/postmaster-28.html Checking the supplied URL reveals that the cygwin list does not comply with the sender verification magic that Yahoo wants to see when an email comes from a Yahoo/ATT address and is to be distributed to an ATT/Yahoo adress. I have a bellsouth.net address which now falls under Yahoo/ATT (and I'm sure there are many others on the list in a similar situation). This means that *any* message *to* the cygwin list *from* an ATT/Yahoo address will not be delivered to me (or any other ATT/Yahoo user) and will be kicked back, putting us all on ezmlm's naughty list. This is not something I can fix -- it has to be addressed at the mailing list level as noted in the error URL. I apologize for putting this here, but hopefully someone wil now see it. Ted Nolan -- 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: ezmlm problems with yahoo/ATT senders
In message 53b16935.4040...@cygwin.comyou write: On 06/30/2014 08:05 AM, tednolan wrote: been obvious to you but your email to the list on this topic usurped a thread on a totally different subject. https://cygwin.com/ml/cygwin/2014-06/msg00443.html We ask that email sent to this list that isn't in response to an existing thread be composed as a new message. -- Larry Yes, my bad, sorry. I forgot to trim the references. -- 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 on Max OS X ?
In message col129-w5d99d52355f33d9159fa1cb...@phx.gblyou write: I have an iMac 27 64-bit words running OS X Mavericks. Can I install Cygwin on my iMac? I know it's not necessary, but I thought it might be helpful for working on system porting/compatibility problems. Dick McCullough Only in the sense that your can run a Windows emulator on OX X and run cygwin in that. A quick google suggest that OS X can run VirtualBox or QEMU -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How to set big font for xterm in cygwin/X
In message 92c60106-8a54-434b-a470-744b8e4d4...@gmail.comyou write: Now I can use cygwin/X to run gtk3-demo, but my eyes is bad and xterm font = in cygwin/X is very small, how can I set to bigger font for xterm? Thanks a= lot.= Well, if you hold down the ctrl key and hit the right mouse button, you will get a menu of VT Fonts and select Large or Huge. Or you could do what I've done -- Make a my_xterm shell script: ## #!/bin/sh # export LANG=C export XTERM_LOCALE=C exec xterm \ -fa lucidatypewriter -fs 16 \ -fg green \ -bg black $* ## I find the green on black much easier to read than other combinations. -- 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
Has anyone built Linux Firefox on cygwin?
I would like to have a native X11 cygwin Firefox. Has anyone been able to build this? As I recall, it was a bear to build even under Linux, and when I started trying to do it under cygwin a few months ago I went down a rathole somewhere and never did get anything working before I had to move on. -- 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: libtool: link: object name conflicts in archive
In message 20140416080331.gn3...@calimero.vinschen.deyou write: --KC+fneiph5CALyUl Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ../../libtool: line 1117: lib: command not found This is *so* wrong. That's very likely a problem in the configury then, and you should try to find out how configure gets the idea to use a tool called lib. How did you run configure? This might be a result of using wrong arguments. Also, the upstream devs might have an idea why the build process tries to use MS tools when building for Cygwin. Corinna I have run into a couple of configure scripts that when they see you are running cygwin think that means they should try to build a native Windows version rather than follow the linux-like path to a native Cygwin version.. It's very irritating. -- 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
Wow, just hit RCS bug
I just hit the worst Cygwin bug I've encountered, the RCS bug which silently corrupts text files 256K. That's the last thing I expect from a version control system! After some moments of panic, I was able to retrieve a good copy from backups, but have lost my revision history. Anyway, I immediately did a list search and found this is a known bug. Shouldn't this package be pulled? Just for the record, the suggested env var fix RCS_MEM_LIMIT=0 to force stdio does not work for me, but the RCS_MEM_LIMIT=10240 to allow 10megs of diffs does.. -- 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: Wow, just hit RCS bug
In message 87bnw12nuu.fsf@Rainer.invalidyou write: tedno...@bellsouth.net writes: Just for the record, the suggested env var fix RCS_MEM_LIMIT=0 to force stdio does not work for me, but the That was never suggested as a fix, but to show that the problem occurs with files much less than 256kiB size when forcing the code path through stdio (which is what the 0 setting does). The RCS test suite passes on Cygwin since it never actively tests this code path. http://thread.gmane.org/gmane.os.cygwin/142346 RCS_MEM_LIMIT=10240 to allow 10megs of diffs does.. Which will fail once you happen upon a diff that gets that large. Ah, OK -- I was just looking for a fix or workaround and didn't read what the =0 was supposed to do closely enough. I can't see ever getting up to 10M of diffs, but still I consider it an existential level bug for a version control system and think the package should be removed. It's almost as bad as if ls -l foo unlinked foo. -- 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: Wow, just hit RCS bug
In message CAFWoy7HdXgKXnPKNTsEUo38ttbj=fcr4krrolnsyxdvfuof...@mail.gmail.com you write: RCS does a great job for smaller projects when I don't need the overhead of any of the popular larger systems. It has saved me many times when I'm working on a short document or a set of scripts on my desktop machine. I'd miss it if it were removed simply due to the lack of handling 10Meg of diffs or similar. Wonder if this bug could be fixed some way? Well, I agree, or I wouldn't be using RCS in the first place. But even though I'm the only coder on the project, I've managed to work the main library file up to 256+ K, and I suspect it's not at all rare for RCS projects to have files in that range. 256K is the key number, not 10M. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How big are your /etc/passwd and /etc/group files?
In message 52ec4727.2000...@gmail.comyou write: On 1/31/2014 5:03 PM, Corinna Vinschen wrote: On Jan 31 22:40, Frank Fesevur wrote: 2014-01-31 Corinna Vinschen: Is anybody here who's using /etc/passwd and/or group files of more than 16K in size? The new way to store the stuff would make Cygwin definitely faster, but it would struggle with... uhm... 2.6 Megs file on the 32 bit version of Cygwin, Hmm. I'm wondering how to solve that elegantly. Corinna Every process needs to load only the current user's entry up front. Somewhere down the road it only *might* have to do things like translate from uid/gid into a string for directory listings, in some cases only a handful of these translations. It's essentially a (old dbm style unix) database lookup. So defer the database lookups to a libgdbm that goes against a (old dbm style unix) database, and don't keep that in memory, unless you want a small LRU algorithm in there to keep a small fixed number. I bet the tiny delay later on a ls or other unix translation won't be very noticeable. Maybe an /etc/nsswitch.conf to choose the desired behavior? -- 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: Windows 7 64 Bit - Mounting Network Drives
In message a85cced36f59429ab961dec7c79b4...@bl2pr02mb449.namprd02.prod.outlook .comyou write: Windows Explorer readily shows drives H: and Z:. That looks like they are reall y mounted to me, but I wouldn't know what constitutes a rigorous test or even w hat the definition of really mounted actually is. My experience with cygwin is that if I can open a DOS command window and successfully do: dir k: Drive k will be accessible as /cygdrive/k -- 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: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In message 52d98e1d.8010...@redhat.comyou write: No. You have to fix things _in the parent, before the fork()_ for everything to be hunky-dory. The easiest way to do that is to fflush(NULL) before fork()ing. You learn something new every day. Usually just after you needed to know it. -- 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: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In message 20140116085026.ga26...@calimero.vinschen.deyou write: Can you change your testcase another bit, please? Enable your `ftell' printf, but rather than printing the result of ftell, print the result of lseek: fprintf(stderr, (%s) (%s) %d %ld\n, infile, outfile, i, lseek(fileno(fp), 0, SEEK_CUR)); I would be curious what happens on Solaris here. OK, I took the original test case and made your lseek change. Here are the Solaris FreeBSD results. Here is Solaris 9: =SOLARIS Script started on Thu Jan 16 23:47:20 2014 solabel10% ./a.out test_data (00.tif) (00.eps) 1 45 Running 0 child (01.tif) (01.eps) 2 15 Running 1 child (02.tif) (02.eps) 3 0 Running 2 child (00.tif) (00.eps) 4 45 Running 3 child (01.tif) (01.eps) 5 15 Running 4 child (02.tif) (02.eps) 6 0 Running 5 child (00.tif) (00.eps) 7 45 Running 6 (01.tif) (01.eps) 8 45 Running 7 (02.tif) (02.eps) 9 45 Running 8 Final wait Final wait Final wait Final wait Final wait Final wait Final wait child Final wait child child Final wait solabel10% exit solabel10% script done on Thu Jan 16 23:47:29 2014 =END SOLARIS Freebsd 4.9: =FREEBSD 4.9 loft% ./a.out test_data (00.tif) (00.eps) 1 45 Running 0 (01.tif) (01.eps) 2 45 child Running 1 (02.tif) (02.eps) 3 45 child Running 2 Final wait child Final wait Final wait =END FREEBSD 4.9 FreeBSD 9.1: =FREEBSD 9.1 (00.tif) (00.eps) 1 45 Running 0 (01.tif) (01.eps) 2 45 Running 1 (02.tif) (02.eps) 3 45 Running 2 Final wait child child Final wait Final wait child brookside% =END FREEBSD 9.1 FreeBSD 8.1: =FREEBSD 8.1 %./a.out test_data (00.tif) (00.eps) 1 45 Running 0 (01.tif) (01.eps) 2 45 child Running 1 (02.tif) (02.eps) 3 45 child Running 2 Final wait child Final wait Final wait =END FREEBSD 8.1 -- 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: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In message 52d63ce2.9060...@lysator.liu.seyou write: On 2014-01-15 05:53, Lord Laraby wrote: On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote: In message 52d55d96.8070...@redhat.com you write: Your program may be violating POSIX, which would trigger undefined behavio r. Quoting POSIX: pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_0 5 [long quote elided] Yikes! That's pretty impenatrable. And if it says what I think it says, it seems to violate the way I've understood Unix fork() and how fds (and stdio buffers) are inherited since forever. However.. Do I understand that to say that if the first thing my child does is fclose(fp); everything should be hunky-dory? Because I just tried that, and it's still not. My two cents say, since the child is not referencing 'fp' at all, there is no violation of the POSIX semantics in this situation. It actually does seem, however, that the fork is closing, or at least forgetting the stdio file position of, fp when it forks. A possible memory corruption during fork from which fgets can not recover? Let me requote one little bit quoted by Eric: (If the only action performed by one of the processes is one of the exec functions or _exit() (not exit()), the handle is never accessed in that process.) Ted is using exit() in the children, not _exit(), and the above indicates that exit() in fact accesses the handle. My guess would be that fclose(3) also accesses the handle. But, reading about _exit(), it seems that handle accesses are implementation defined, so I'm not sure it will help in all situations. Cheers, Peter Well, all I can say in this instance, is that arguably conforming to the bare letter of the standard (if that's in fact what is happening) is not the right thing. People certainly don't expect that stdio file pointers that exist at fork() time and which are never used by a child will be reset in the parent. I mean, if they can't even be fclose()-ed to take them out of the picture, what chance have you got? -:) FWIW, FreeBSD, Linux and Solaris all compile and run the test program with the behavoir I expect.. -- 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: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In message 20140115163354.ga30...@calimero.vinschen.deyou write: --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Jan 15 10:28, tedno...@bellsouth.net wrote: In message 52d63ce2.9060...@lysator.liu.seyou write: On 2014-01-15 05:53, Lord Laraby wrote: On Tue, Jan 14, 2014 at 10:50 AM, Ted Nolan wrote: In message 52d55d96.8070...@redhat.com you write: Your program may be violating POSIX, which would trigger undefined b= ehavio r. Quoting POSIX: pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#ta= g_15_0 5 [long quote elided] Yikes! That's pretty impenatrable. And if it says what I think it s= ays, it seems to violate the way I've understood Unix fork() and how fds (and stdio buffers) are inherited since forever. However.. Do I understand that to say that if the first thing my child does is fclose(fp); everything should be hunky-dory? Because I just tried that, and it's still not. =20 My two cents say, since the child is not referencing 'fp' at all, there is no violation of the POSIX semantics in this situation. It actually does seem, however, that the fork is closing, or at least forgetting the stdio file position of, fp when it forks. A possible memory corruption during fork from which fgets can not recover? Let me requote one little bit quoted by Eric: (If the only action performed by one of the processes is one of the exec functions or _exit() (not exit()), the handle is never accessed in that process.) Ted is using exit() in the children, not _exit(), and the above indicates that exit() in fact accesses the handle. My guess would be that fclose= (3) also accesses the handle. But, reading about _exit(), it seems that handle accesses are implementa= tion defined, so I'm not sure it will help in all situations. Cheers, Peter =20 Well, all I can say in this instance, is that arguably conforming to the bare letter of the standard (if that's in fact what is happening) is not the right thing. People certainly don't expect that stdio file pointers that exist at fork() time and which are never used by a child will be reset in the parent. I mean, if they can't even be fclose(= )-ed to take them out of the picture, what chance have you got? -:) =20 FWIW, FreeBSD, Linux and Solaris all compile and run the test program with the behavoir I expect.. Just for completeness: I can test on Linux, but not on FreeBSD and Solaris. Does the testcase also work as expected on both of them, after you added fclose to the child? On Linux it does. Thanks, Corinna Well, it appears I spoke too soon about Solaris. I saw that it terminated rather than running forever, and assumed it was working correctly. That turns out not to be the case: For 3 lines in the input file, it somehow gets up to 8 processes before terminating. Here's what I can say per OS: FreeBSD 4.9 FreeBSD 8.1 FreeBSD 9.1 Original test case works. Test case with fclose() works Test case with _exit() instead of exit() works Solaris 9: Original test case fails (but terminates) Test case with fclose() fails Test case with _exit() instead of exit() works Cygwin: Original test case fails (never terminates) Test case with fclose() fails Test case with _exit() instead of exit() works Gentoo Linux: Original test case works Test case with fclose() -- don't have access right now Test case with _exit() instead of exit() -- don't have access rght now So, as per other posters, exit() is wrong and should be _exit(). I accept that, and will fix it, but it still seems to be that the Linux and FreeBSD behavior is better here. If the spec allows spooky action at a distance, that's not the same as encouraging it.. -- 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: fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
In message 52d55d96.8070...@redhat.comyou write: Your program may be violating POSIX, which would trigger undefined behavior. Quoting POSIX: pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_05 [long quote elided] Yikes! That's pretty impenatrable. And if it says what I think it says, it seems to violate the way I've understood Unix fork() and how fds (and stdio buffers) are inherited since forever. However.. Do I understand that to say that if the first thing my child does is fclose(fp); everything should be hunky-dory? Because I just tried that, and it's still not. -- 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
fork() + file descriptor bug in 1.7.27(0.271/5/3) 2013-12-09 11:54
Hello,
I'm running:
CYGWIN_NT-6.1 prog5 1.7.27(0.271/5/3) 2013-12-09 11:54 x86_64 Cygwin
gcc (GCC) 4.8.2
on a 64 bit Win7 system.
I have just run into an odd bug, which I have boiled down into the program
below (which started as a mod to tiff2ps).
If you compile this program:
=CUT HERE=
#include stdio.h
#include stdlib.h
#include unistd.h
#include string.h
#include sys/types.h
#include sys/wait.h
int main(int argc, char **argv)
{
FILE *fp;
char buf[4096];
char infile[4096];
char outfile[4096];
int i = 0;
int running_children = 0;
int child_limit = 20;
int wait_status;
if (argc == 1) {
fp = stdin;
} else if (argc == 2) {
fp = fopen(argv[1], r);
if (!fp) {
fprintf(stderr, Can't open input list %s\n, argv[1]);
exit(1);
}
} else {
fprintf(stderr, Usage: multi_tiff2ps [spec_file]\n);
exit(1);
}
while( fgets(buf, sizeof(buf), fp) ) {
++i;
if(sscanf(buf, %s %s, infile, outfile) != 2) {
fprintf(stderr, Malformed spec line %d (%s)\n,
i, buf);
continue;
}
//fprintf(stderr, (%s) (%s) %d %ld\n, infile,
// outfile, i, ftell(fp));
fprintf(stderr, Running %d\n, running_children);
if (running_children = child_limit) {
fprintf(stderr, Initial wait\n);
wait(wait_status);
--running_children;
}
switch (fork()) {
/* error */
case -1:
fprintf(stderr,
Can't fork new tiff2ps process!\n);
exit(1);
break;
/* child */
case 0:
fprintf(stderr, child\n); fflush(stderr);
exit(0);
break;
/* parent */
default:
++running_children;
break;
}
}
for(i = 0; i running_children; i++) {
fprintf(stderr, Final wait\n);
wait(wait_status);
}
exit(0);
}
=End code=
and run it with this data:
00.tif 00.eps
01.tif 01.eps
02.tif 02.eps
It will run forever.
However, if you uncomment the fprintf with the ftell(), it runs as
expected.
It works correctly on linux.
Anyone seen this before?
Is there a fix?
Thanks!
Ted Nolan
--
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
