Re: the soft link of cygwin must have system attribute of window
nwpu053...@gmail wrote: > Can the limitation be canceled? I don't think so, not without slowing things down by making *every* file have to be opened to check if it is a symlink, instead of only files with the (otherwise uncommon) system attribute. cheers, DaveK -- 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
the soft link of cygwin must have system attribute of window
Can the limitation be canceled? -- 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: nasm -- what format does cygwin use?
Tim Prince wrote: > Linda Walsh wrote: >> I am trying to compile a program that use nasm and it thought that >> gnuwin32 was a format for nasm (don't know if it used to be, but it's >> not now). >> >> Does cygwin use standard linux format now 'elf', or is it using >> win32?..or >> something else)? > If running inside cygwin, you let the cygwin developers make the choice, > which the binutils as will select automatically (PE-i386?). Well, nasm != binutils, so in theory it could do things differently if it chose. > nasm might > be used, I suppose, with mingw, as your comment almost implies, so > becomes off topic for this list, if you refer to development for > non-cygwin targets. Nope, it has nothing to do with that. nasm is an assembler. It generates relocatable object files. It has no concept of an ABI, or a system library, or anything like that. Linda, my reading of the "nasm -hf" output suggests you'd want the win32 output format. If you check the generated .o files it using "objdump -h" you should see "file format pe-i386", which is right. After you've got .o files, you'll still need to link them; hopefully your makefiles will work with cygwin's LD easily enough. cheers, DaveK -- 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: nasm -- what format does cygwin use?
Linda Walsh wrote: I am trying to compile a program that use nasm and it thought that gnuwin32 was a format for nasm (don't know if it used to be, but it's not now). Does cygwin use standard linux format now 'elf', or is it using win32?..or something else)? If running inside cygwin, you let the cygwin developers make the choice, which the binutils as will select automatically (PE-i386?). nasm might be used, I suppose, with mingw, as your comment almost implies, so becomes off topic for this list, if you refer to development for non-cygwin targets. -- 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: nasm -- what format does cygwin use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 12/4/2009 5:21 PM: > Does cygwin use standard linux format now 'elf', or is it using win32?..or > something else)? Cygwin is a windows app, therefore it uses PE-COFF like all other windows apps. Reading the list archives would have made it abundantly clear that there are some things (like lazy linking, if you specify libraries in the wrong order) that work on Linux but not on cygwin, exactly because cygwin does NOT, nor will it ever, be ELF. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksZsBMACgkQ84KuGfSFAYDiPACeJOkht57E+OHlMUPhnka+0GWq CTYAnjSS0+iOYB7jdGMTykmDxjNqBnnb =wu4d -END PGP SIGNATURE- -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Eliot Moss wrote: I should have asked you in my last email: should I have reloaded cygwin prior to attempting to use the steps you prescribed in your response? What does "reloaded" mean? Reinstalled, in other words. Poor choice of words on my part... Best procedure is: - reboot system - open a cmd window - start ash - do rebasing, peflags hacking from ash -- no bash subprocesses, etc. If I run vim under ash to edit the files which contain the .so, .dll, and .exe files (to remove files that rebase and peflags barf upon), won't that fire up various cygwin processes? And thus foul the rebase/peflag process? Do I need to use Windows's notepad editor or something equally lame? :-) $ /bin/rebase -d -b 0x6100 -o 0x2 -v -T dll,so.in > rebase.out ./bin/cyglsa64.dll: fixing bad relocations FixImage (./bin/cyglsa64.dll) failed with last error = 13 $ When this happens, rebase *stops*. You need to remove the file from the list and rebase again. Yup. That's what I did. Okay, it makes some sort of intuitive sense that trying to rebase a 64b dll in a 32b system should be dicey [incidentally, is there a guide somewhere to these "last error" codes?]. So I removed "./bin/cyglsa64.dll" from the dll,so.in file and retried: One might have to go into the rebase source code ... I'll give that a shot. $ /bin/rebase -d -b 0x6100 -o 0x2 -v -T dll,so.in > rebase.out ReBaseImage (./bin/cygwin1.dll) failed with last error = 6 You've probably run something that needed cygwin1.dll. Hence the reboot, etc., above, and the care not to run any bash stuff, etc. I didn't THINK I was running any bash stuff, though I did edit the dll,so.in and dot exe.in files with a copy of gvim from a non-cygwin distribution -- which I ran it by double clicking the input files' icons in the Windows explorer window (not from within any cygwin window or shell). But it's conceivable that that I might have munged my PATH or LDPATH variables, and thus directed my non-cygwin gvim to libs from the cygwin distro. If ash doesn't fire up any cygwin libraries (beyond its own executable), then I MUST have done SOMETHING similarly bone-headed. Alas, still no joy. And this time it's barfing on cygwin1.dll, pretty much one of the prime dlls I would have thought needed rebasing... Not sure what error 6 means, ... In use, I think ... Yeah, that's the way to bet... But of course, cygwin1.dll IS in use because it underlies ash.exe. No, I don't think it does -- ash is special. You must be correct, or the process would never work for ANYONE. ... And then I ran peflags as follows: Sure, that's fine ... $ /bin/peflags -d0 -v -T dll,so.in > peflags-d.out Warning: file is non-executable but has tsaware set (./bin/cyglsa.dll). If you look carefully at my instructions, I think that one says exe files only. Yup. The relevant excerpt from your instructions was: /bin/peflags -d0 -v -T > peflags-d.out /bin/peflags -t0 -v -T > peflags-t.out In my case, => dll,so.in; and => dotexe.in Both of which I generated with the find command thus: find /cygdrive/c/cygwin -iname "*.dll" -print >> dll,so.in find /cygdrive/c/cygwin -iname "*.so" -print >> dll,so.in find /cygdrive/c/cygwin -iname "*.exe" -print >> dotexe.in Don't know whether that warning's important, but with the confidence born of total ignorance, I press on: $ /bin/peflags -t0 -v -T dotexe.in > peflags-t.out Error: could not update pe characteristics (./bin/peflags.exe): Device or resource busy $ I didn't get that, I don't think, but hardly matters since you don't run peflags often and if is not the source of the fork problems :-) ... Okay, now I reboot, re-activate BitDefender's "Advanced Virus Control"... And I bring up an rxvt-native window. Windows's annoying little rotating circle cogitates for about 10 seconds before I get a prompt (reproduced below) and attempt to run an "ls" command. Notice that the prompt does not, as is ordinary, show the current directory: $ ls Yet more blue spinning circle for about the same length of time, followed by $ Wierd. Not sure what to say, but the (few) differences between what happens for me and for you may be significant. I think the key problem was that I must have in some way managed to fire up components of the cygwin1.dll via some ancillary process I had going on at the time. Else, the rebasing process wouldn't have lost its lunch upon attempting to rebase cygwin1.dll. How I did that, I can't say. But I think your admonition to perform a reboot prior to beginning the process is a good one, so I'll give it a go with that. So at last, the questions: 1) Should I have reloaded cygwin prior to running your command set? Again, I don't know what "reloaded" means. Sorry. I meant "reinstall" -- i.e., install new copies of all the cygwin distro files over the top of th
Re: [ANNOUNCEMENT] [1.7] Updated: grep-2.5.4-2
On 2009-11-25, Christopher Faylor wrote: > I've made a new version of 'grep' (http://www.gnu.org/software/grep/) > available for installation. This is the most recent version of grep > available from ftp.gnu.org + a patch from the Mandrake project which > seems to alleviate the problem mentioned here: > > http://cygwin.com/ml/cygwin/2009-11/threads.html#00779 > > i.e., "grep -i --color" doesn't always work. Thank you! I installed the Cygwin src package, copied the directory to my Linux machine, ran ./configure, make, and make install there and voilà: grep with working color! Regards, Gary -- 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
nasm -- what format does cygwin use?
I am trying to compile a program that use nasm and it thought that gnuwin32 was a format for nasm (don't know if it used to be, but it's not now). Does cygwin use standard linux format now 'elf', or is it using win32?..or something else)? Thanks, -linda -- 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
[1.5.17] sshing doesnt work for pub/priv key. Password works. Win2003
Hi, I'm having an issue ssh'ing into a cygwin box. It was running Windows 2000 and was upgraded to Windows 2003. When I turn on debugging the last lines I get are this: -- snip -- debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply Read from socket failed: Connection reset by peer -- snip -- I can ssh in and use a password via putty, but if I try this from a server it'll automatically try to use a key and die. I've tried 3 different pub/priv keys. I've done other searches on the net and found a few ideas (uninstall ssh and re-install and run ssh-host-config, an article from u of waterloo about setting it up for win2003, changing permissions of windows/unix users) without any luck. We've even tried to do a fresh install and even that didn't help. any ideas? -- Robert Westendorp -- 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: [1.7] getgroups regression?
On 12/4/2009 5:48 PM, Eric Blake wrote: On further review, I found my 1.7 /etc/group was more than twice the size of the 1.5 version; and all of that bulk came from duplicated entries. [...] But that still makes me wonder - is there anything we are doing in a typical install that might be accidentally inserting duplicate entries into /etc/group, or is this something I managed to fubar all by myself way back when I first created my side-by-side 1.5/1.7 installation (back before the transition was as smooth as it is now)? I also have duplicate entries in /etc/group in a 1.7 installation that I created last February. But I have a more recent installation with no duplicate entries. So whatever might have been wrong seems to have been fixed. Ken -- 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: [1.7] getgroups regression?
Eric Blake byu.net> writes: > > On the same machine, I see: > > cygwin-1.5$ id -G | wc > 1 24 136 > > cygwin-1.7$ id -G | wc > 1 46 264 > cygwin-1.7$ printf %s\\n `id -G` | sort -u | wc > 24 24 136 > > In other words, under cygwin 1.7, the last 22 entries are placed in the > getgroups results twice. On further review, I found my 1.7 /etc/group was more than twice the size of the 1.5 version; and all of that bulk came from duplicated entries. $ ls -l /etc/group.old /etc/group -rwxr-xr--+ 1 eblake Domain Users 75790 2008-12-15 10:56 /etc/group.old* -rwxr-xr-- 1 eblake Domain Users 151559 2009-05-11 07:51 /etc/group* $ cmp <(sort -u /etc/group.old) <(sort -u /etc/group); echo $? 0 So, cygwin 1.7 getgroups was listing duplicates because my /etc/group had duplicates. Remove the duplicates, and now I get the same results in id for 1.7 as I did for 1.5. But that still makes me wonder - is there anything we are doing in a typical install that might be accidentally inserting duplicate entries into /etc/group, or is this something I managed to fubar all by myself way back when I first created my side-by-side 1.5/1.7 installation (back before the transition was as smooth as it is now)? Meanwhile, is sorting and/or pruning duplicate getgroups results something that cygwin should consider doing? POSIX is explicit that the result is a mathematical set, and that two processes can have the same set membership but different orders based on the sequence of events that created those two processes. But will Linux ever list a duplicate, even if duplicates appear in /etc/group? -- Eric Blake -- 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
[1.7] getgroups regression?
On the same machine, I see: cygwin-1.5$ id -G | wc 1 24 136 cygwin-1.7$ id -G | wc 1 46 264 cygwin-1.7$ printf %s\\n `id -G` | sort -u | wc 24 24 136 In other words, under cygwin 1.7, the last 22 entries are placed in the getgroups results twice. -- Eric Blake -- 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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Alas, I ran the commands as you recommend below, and there is yet no joy here in Mudville. I apologize in advance for the length of this -- I'm ignorant, so I don't know which details I can omit -- but as you'll see when you arrive at the end, the questions I'm asking are in fact quite few and quite simple. I hope :-) Okay, bear in mind that I'd already run the following commands prior to attempting to use your method: $ /bin/rebaseall -b 0x3500 -v $ /bin/peflagsall I should have asked you in my last email: should I have reloaded cygwin prior to attempting to use the steps you prescribed in your response? Anyway, here's what I did, and here're the results (the file "dll,so.in" contains all the .dll and .so files I dug up running a "find" command from within the c:\cygwin directory): $ /bin/rebase -d -b 0x6100 -o 0x2 -v -T dll,so.in > rebase.out ./bin/cyglsa64.dll: fixing bad relocations FixImage (./bin/cyglsa64.dll) failed with last error = 13 $ Okay, it makes some sort of intuitive sense that trying to rebase a 64b dll in a 32b system should be dicey [incidentally, is there a guide somewhere to these "last error" codes?]. So I removed "./bin/cyglsa64.dll" from the dll,so.in file and retried: $ /bin/rebase -d -b 0x6100 -o 0x2 -v -T dll,so.in > rebase.out ReBaseImage (./bin/cygwin1.dll) failed with last error = 6 Alas, still no joy. And this time it's barfing on cygwin1.dll, pretty much one of the prime dlls I would have thought needed rebasing... Not sure what error 6 means, but according to the rebase-3.0.1.README, file: If you get any errors due to DLLs being in-use or read-only, then take the appropriate action and rerun rebaseall. Otherwise, you run the risk of fork() failing. But of course, cygwin1.dll IS in use because it underlies ash.exe. So maybe it's to be expected. I removed cygwin1.dll from dll,so.in (!) and reran the command -- but I didn't feel good about it :-| $ /bin/rebase -d -b 0x6100 -o 0x2 -v -T dll,so.in > rebase.out ./bin/tclpip84.dll: skipped because not rebaseable ./lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Win32/GUI/Scintilla/SciLexer.dll: skipped because not rebaseable ./usr/share/doc/freetype2/VERSION.DLL: skipped because not rebaseable $ Now, not knowing any better, I figured I'd better remove the above files, the ones that didn't get rebased, from dll,so.in prior to using it as input to the peflags -d0 command; under the completely naive assumption that if they didn't get rebased, they probably shouldn't have their flags tinkered with, either. And then I ran peflags as follows: $ /bin/peflags -d0 -v -T dll,so.in > peflags-d.out Warning: file is non-executable but has tsaware set (./bin/cyglsa.dll). $ Don't know whether that warning's important, but with the confidence born of total ignorance, I press on: $ /bin/peflags -t0 -v -T dotexe.in > peflags-t.out Error: could not update pe characteristics (./bin/peflags.exe): Device or resource busy $ To the error above, I can only respond, "DOH!" Okay, now I reboot, re-activate BitDefender's "Advanced Virus Control" (as opposed, I guess, to its sister feature, "Nothing Special Virus Control." And I bring up an rxvt-native window. Windows's annoying little rotating circle cogitates for about 10 seconds before I get a prompt (reproduced below) and attempt to run an "ls" command. Notice that the prompt does not, as is ordinary, show the current directory: $ ls Yet more blue spinning circle for about the same length of time, followed by $ Yep. That's what i get. Nada. Just to be safe, I run a few more random commands under both rxvt and a cygwin bash shell, with precisely the same results. So at last, the questions: 1) Should I have reloaded cygwin prior to running your command set? 2) Should I have rebased cygwin1.dll from a cmd shell prior to or after running your commands? As follows, perhaps? __ c:> cd \cygwin\bin cp cygwin1.dll cygwin1.dll.orig cp cygwin1.dll cygwin1.dll.tmp /bin/rebase -d -b 0x6100 -o 0x2 -v cygwin1.dll.tmp > rebasecyg1dll.out cp cygwin1.dll.tmp cygwin1.dll __ 3) OPTIONAL QUESTION: Odd that I didn't notice before, but you used the -d flag to rebase, which the rebase.3.0.1.README file tells me means "rebase down memory (default: up)." I'm assuming that means that you're proceeding by establishing an upper bound for these libraries and executables (in this case, virtual memory location 0x6100, or approx. the 1.63 GB mark) and rebasing the zero-th byte of each successive executable or library at a VM address 0x2 bytes (approx. 131KB) lower than the rebased VM starting address. Am I correct? Any particular reason for rebasing in a downw
Re: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes
Thanks so much for your response! A few mop-up questions below. Hope you don't mind. Eliot Moss wrote: Dear Ed -- I posted this a couple of days ago under another thread. My apologies. I thought I'd researched this carefully before posting. Should have cast my net a bit wider, I guess. Here is the rebase procedure that works for me: /bin/rebase -d -b 0x6100 -o 0x2 -v -T so files> > rebase.out I notice that the rebaseall defaults (assuming I have them correctly) for the -b and -o flags are: -b: 0x7000 -o: 0x1 Was there some bit of information in particular that caused you to choose 0x6100 and 0x2, respectively, or was it a matter of trial and error? (If you know of a good reference for windows's memory model and layout, feel free to point me in that direction). and /bin/peflags -d0 -v -T > peflags-d.out Okay, so with the -d0 flag, you're telling peflags to set the dynamicbase flag to 0 on all specified files - meaning, I guess that these libraries and executables should NOT be "randomly rebased at load time by the OS?" A naive question: why wouldn't you want that to occur? (again, if the answer to that question is too involved, feel free to point me to documentation). /bin/peflags -t0 -v -T > peflags-t.out And here the -t0 flag sets the "tsaware" flag to 0 on the specified files -- i.e., the executable/library should not be reconfigured as multi-user. Correct? I note from microsoft's site that "/TSAWARE is not valid for drivers, VxDs, or DLLs." But is there some reason you wouldn't want the .exe files to to be mult-user aware? Other than the fact that on a standalone desktop PC, it wouldn't really make much sense :-> ? Note particularly the base and -o values, and be sure the check the output. Also, you have to do all this under ash, etc., and build a list of files first with find (or just list particular directories' files). I found there ae one or two files I had to exclude because rebase halts on them. Best wishes -- Eliot Moss Thanks again for your help and patience! And again, a pointer to documentation will suffice to answer my questions -- particularly if any or all of them would require a treatise by way of answer ;-) -- Ed -- 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: Base-Files (was Re: Unset TMP/TEMP in profile?)
John? Ping?
On Dec 2 22:10, Corinna Vinschen wrote:
> On Dec 2 13:36, Christopher Faylor wrote:
> > On Wed, Dec 02, 2009 at 07:21:40PM +0100, Corinna Vinschen wrote:
> > >On Dec 2 18:21, Thomas Wolff wrote:
> > >> Corinna Vinschen wrote in another thread about setting LANG:
> > >> >>... Andy and Thomas, please work
> > >> >>out the best solution together. It should work in sh and csh. Then
> > >> >>post it as reply to http://cygwin.com/ml/cygwin/2009-12/msg00090.html
> > >> >>so
> > >> >>John can put it into the base-files package.
> > >> Our worked-out proposal is as follows:
> > >>
> > >>
> > >> /etc/profile.d/lang.sh:
> > >>
> > >> # if no locale variable is set, indicate terminal charset via LANG
> > >> test -z "${LC_ALL:-${LC_CTYPE:-$LANG}}" && export LANG=C.UTF-8
> > >>
> > >> /etc/profile.d/lang.csh:
> > >>
> > >> # if no locale variable is set, indicate terminal charset via LANG
> > >> ( test $?LC_ALL = 0 || test -z "$LC_ALL" ) && ( test $?LC_CTYPE = 0 ||
> > >> test -z "$LC_CTYPE" ) && ( test $?LANG = 0 || test -z "$LANG" ) &&
> > >> setenv LANG C.UTF-8
> > >
> > >Thanks to both of you.
> >
> > I wasn't paying attention before, so I apologize for not commenting
> > sooner but couldn't all of the above be one test statement or at least
> > handled inside '{}' rather than '()'. Maybe bash optimizes that away
> > but, if it doesn't, then forking subshells will be rather expensive on
> > Cygwin.
>
> The statement you're referring to only affects tcsh, not bash. But
> you're right, nevertheless. I would simplify this to
>
> /etc/profile.d/lang.csh:
>
> if ( $?LC_ALL == 0 && $?LC_CTYPE == 0 && $?LANG == 0 ) setenv LANG C.UTF-8
>
> This works without forking any child process. And the user might
> actually want to set one of these variables to an empty string.
It would be helpful to get a new base-files package this weekend, if
possible.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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] [1.7] Updated: cygwin-1.7.0-68
On Dec 4 20:39, Fr?d?ric Bron wrote: > > I just uploaded a new Cygwin 1.7 test release, 1.7.0-68. > > Installed this and cannot start Xwin anymore. Here is the content of > /var/log/XWin.0.log: Works fine for me. You should move this to the cygwin-xfree list. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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] [1.7] Updated: cygwin-1.7.0-68
> I just uploaded a new Cygwin 1.7 test release, 1.7.0-68. Installed this and cannot start Xwin anymore. Here is the content of /var/log/XWin.0.log: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-11 Contact: cygwin-xf...@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1920 h 1200 winInitializeDefaultScreens - Returning 2009-12-04 20:36:21 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2009-12-04 20:36:21 _XSERVTransOpen: transport open failed for inet6/VOR-CRV-01660:0 2009-12-04 20:36:21 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2009-12-04 20:36:22 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-12-04 20:36:22 (II) xorg.conf is not supported 2009-12-04 20:36:22 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-12-04 20:36:22 winPrefsLoadPreferences: /cygdrive/d/Documents/.XWinrc 2009-12-04 20:36:22 winGetDisplay: DISPLAY=:0.0 2009-12-04 20:36:22 winDetectSupportedEngines - Windows NT/2000/XP 2009-12-04 20:36:22 winDetectSupportedEngines - DirectDraw installed 2009-12-04 20:36:22 winDetectSupportedEngines - DirectDraw4 installed 2009-12-04 20:36:22 winDetectSupportedEngines - Returning, supported engines 0007 2009-12-04 20:36:22 winSetEngine - Multi Window or Rootless => ShadowGDI 2009-12-04 20:36:22 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2009-12-04 20:36:22 winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1200 depth: 32 2009-12-04 20:36:22 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-12-04 20:36:22 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2009-12-04 20:36:22 null screen fn ReparentWindow 2009-12-04 20:36:22 null screen fn RestackWindow 2009-12-04 20:36:22 InitQueue - Calling pthread_mutex_init 2009-12-04 20:36:22 InitQueue - pthread_mutex_init returned 2009-12-04 20:36:22 InitQueue - Calling pthread_cond_init 2009-12-04 20:36:22 InitQueue - pthread_cond_init returned 2009-12-04 20:36:22 winInitMultiWindowWM - Hello 2009-12-04 20:36:22 winInitMultiWindowWM - Calling pthread_mutex_lock () 2009-12-04 20:36:22 Screen 0 added at XINERAMA coordinate (0,0). 2009-12-04 20:36:22 winMultiWindowXMsgProc - Hello 2009-12-04 20:36:22 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2009-12-04 20:36:22 MIT-SHM extension disabled due to lack of kernel support 2009-12-04 20:36:22 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-12-04 20:36:22 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-12-04 20:36:22 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-12-04 20:36:23 winPointerWarpCursor - Discarding first warp: 960 600 2009-12-04 20:36:23 (--) 3 mouse buttons found 2009-12-04 20:36:23 (--) Setting autorepeat to delay=500, rate=31 2009-12-04 20:36:23 (--) winConfigKeyboard - Layout: "040C" (040c) 2009-12-04 20:36:23 (--) Using preset keyboard for "French (Standard)" (40c), type "4" 2009-12-04 20:36:23 Rules = "base" Model = "pc105" Layout = "fr" Variant = "none" Options = "none" 2009-12-04 20:36:24 winInitMultiWindowWM - pthread_mutex_lock () returned. 2009-12-04 20:36:24 winProcEstablishConnection - Hello 2009-12-04 20:36:24 winInitClipboard () 2009-12-04 20:36:24 winClipboardProc - Hello 2009-12-04 20:36:24 winProcEstablishConnection - winInitClipboard returned. 2009-12-04 20:36:24 DetectUnicodeSupport - Windows NT/2000/XP 2009-12-04 20:36:24 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2009-12-04 20:36:24 winGetDisplay: DISPLAY=:0.0 2009-12-04 20:36:24 winMultiWindowXMsgProc - pthread_mutex_lock () returned. 2009-12-04 20:36:24 winGetDisplay: DISPLAY=:0.0 2009-12-04 20:36:24 winClipboardProc - DISPLAY=:0.0 2009-12-04 20:36:24 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. 2009-12-04 20:36:24 winInitMultiWindowWM - DISPLAY=:0.0 2009-12-04 20:36:24 (II) xorg.conf is not supported 2009-12-04 20:36:24 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-12-04 20:36:24 winPrefsLoadPreferences: /cygdrive/d/Documents/.XWinrc 2009-12-04 20:36:24 winGetDisplay: DISPLAY=:0.0 2009-12-04 20:36:24 winDetectSupportedEngines - Windows NT/2000/XP 2009-12-04 20:36:24 winDetectSupportedEngines - DirectDraw installed 2009-12-04 20:36:24 winDetectSupportedEngines - DirectDraw4 installed 2009-12-04 20:36:24 winDetectSupportedEngines - Returning, supported engines 0007 2009-12-04 20:36:24 winSetEngine - Multi Window or Rootless => ShadowGDI 2009-12-04 20:36:24 winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1200 depth: 32 2009-12-04 20:36:24 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-12-04 20:36:24 winInitVisualsShadowGDI - Mask
Re: Why does exiting bash window kill off Gvim? (Windows version, but X-would be same question)
On Fri, Dec 04, 2009 at 06:03:57PM +, Andy Koppe wrote: >2009/12/4 Andy Koppe: >> 2009/12/3 Linda Walsh: >>> In bash I start a copy of gvim.exe (64-bit windows version) in background. >>> I disown the job in bash so bash no longer manages the job -- it should be >>> a free and clear process (unaffected by bash exiting). >>> >>> Yet when I exit the bash window (bash running in a console window), Gvim >>> is killed. ??Why should bash or the console exiting kill off any processes >>> running in the background? >> >> Were you closing the console window by pressing the close button? >> >> In that case, the problem is that gvim is built as a console program, >> which means that it will have attached to bash's console. When a >> console is closed, all processes attached to it are terminated. >> >> I think that's a bug, because gvim has no need for a console and >> therefore should be built with -Wl,subsystem,windows. > >Hang on, if I do this: > >$ setsid gvim -display :0 & > >in a bash console and then close the console, gvim continues to work, >so either setsid or gvim itself does detach from the console. That makes sense. Cygwin sends explicit SIGHUPs to other members of the console process group when it receives a CTRL_CLOSE_EVENT. setsid should fix that. You shouldn't need the '&' in the above scenario. Did that actually make a difference? cgf -- 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: Why does exiting bash window kill off Gvim? (Windows version, but X-would be same question)
2009/12/4 Andy Koppe: > 2009/12/3 Linda Walsh: >> In bash I start a copy of gvim.exe (64-bit windows version) in background. >> I disown the job in bash so bash no longer manages the job -- it should be >> a free and clear process (unaffected by bash exiting). >> >> Yet when I exit the bash window (bash running in a console window), Gvim >> is killed. Why should bash or the console exiting kill off any processes >> running in the background? > > Were you closing the console window by pressing the close button? > > In that case, the problem is that gvim is built as a console program, > which means that it will have attached to bash's console. When a > console is closed, all processes attached to it are terminated. > > I think that's a bug, because gvim has no need for a console and > therefore should be built with -Wl,subsystem,windows. Hang on, if I do this: $ setsid gvim -display :0 & in a bash console and then close the console, gvim continues to work, so either setsid or gvim itself does detach from the console. Andy -- 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] [1.7] Updated: cygwin-1.7.0-68
Points to you then--- part of my confusion came from thinking of you as no more foreign than say California ;-) --hsm On Fri, Dec 4, 2009 at 10:51 AM, Corinna Vinschen wrote: > On Dec 4 10:42, Hugh Myers wrote: >> Shouldn't have quibbled in the first place, just got hung up on what >> seemed foreign phrasing for English... > > Well, after all I am foreign. English being just second language and > all that... > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > 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 > > -- 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] [1.7] Updated: cygwin-1.7.0-68
On Dec 4 10:42, Hugh Myers wrote: > Shouldn't have quibbled in the first place, just got hung up on what > seemed foreign phrasing for English... Well, after all I am foreign. English being just second language and all that... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Why does exiting bash window kill off Gvim? (Windows version, but X-would be same question)
2009/12/3 Linda Walsh: > In bash I start a copy of gvim.exe (64-bit windows version) in background. > I disown the job in bash so bash no longer manages the job -- it should be > a free and clear process (unaffected by bash exiting). > > Yet when I exit the bash window (bash running in a console window), Gvim > is killed. Why should bash or the console exiting kill off any processes > running in the background? Were you closing the console window by pressing the close button? In that case, the problem is that gvim is built as a console program, which means that it will have attached to bash's console. When a console is closed, all processes attached to it are terminated. I think that's a bug, because gvim has no need for a console and therefore should be built with -Wl,subsystem,windows. Andy -- 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] [1.7] Updated: cygwin-1.7.0-68
Shouldn't have quibbled in the first place, just got hung up on what seemed foreign phrasing for English... --hsm On Fri, Dec 4, 2009 at 10:38 AM, Corinna Vinschen wrote: > On Dec 4 10:34, Hugh Myers wrote: >> Then I don't understand what "disallowed to" means. > > dup(2) didn't work right for /proc/registry. Is that better? > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > 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 > > -- 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] [1.7] Updated: cygwin-1.7.0-68
On Dec 4 10:34, Hugh Myers wrote: > Then I don't understand what "disallowed to" means. dup(2) didn't work right for /proc/registry. Is that better? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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] [1.7] Updated: cygwin-1.7.0-68
Then I don't understand what "disallowed to" means. --hsm On Fri, Dec 4, 2009 at 10:27 AM, Corinna Vinschen wrote: > On Dec 4 10:22, Hugh Myers wrote: >> Did you mean "disallowed two duplicate file descriptors"? If not what >> did you mean? > > No, I meant "to". dup(2) on /proc/registry returned with EBADF. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Project Co-Leader cygwin AT cygwin DOT com > Red Hat > > -- > 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 > > -- 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] [1.7] Updated: cygwin-1.7.0-68
On Dec 4 10:22, Hugh Myers wrote: > Did you mean "disallowed two duplicate file descriptors"? If not what > did you mean? No, I meant "to". dup(2) on /proc/registry returned with EBADF. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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] [1.7] Updated: cygwin-1.7.0-68
Did you mean "disallowed two duplicate file descriptors"? If not what did you mean? --hsm On Fri, Dec 4, 2009 at 10:01 AM, Corinna Vinschen wrote: > Hi folks, > > > I just uploaded a new Cygwin 1.7 test release, 1.7.0-68. > > This is supposed to be the last beta release. We're planning to release > Cygwin 1.7.1 officially next week. > > > Bugfixes in relation to 1.7.0-67: > = > > - Fix a bug in dup(2) which disallowed to duplicate file descriptors for > the virtual directories /proc/registry, /proc/registry32, and > /proc/registry64. > > - Fix send(2) not to split UDP datagrams into multiple network packets. > > - Make sure user space syslog entries are never of facility SYS_KERN. > > - Fix setfacl(1) to allow deletion of default entries for the owner and > owner group. > > > FAQ: > > > - Q: How do I know that I'm running Cygwin 1.7.0-68? > > A: The `uname -v' command prints "2009-12-04 17:08" > > > Have fun, > Corinna > > > *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** > > If you want to unsubscribe from the cygwin-announce mailing list, look > at the "List-Unsubscribe: " tag in the email header of this message. > Send email to the address specified there. It will be in the format: > > cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com > > If you need more information on unsubscribing, start reading here: > > http://cygwin.com/lists.html#unsubscribe-simple > > Please read *all* of the information on unsubscribing that is available > starting at this URL. > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Developer mailto:cygwin@cygwin.com > Red Hat, Inc. > > -- > 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 > > -- 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
[ANNOUNCEMENT] [1.7] Updated: cygwin-1.7.0-68
Hi folks, I just uploaded a new Cygwin 1.7 test release, 1.7.0-68. This is supposed to be the last beta release. We're planning to release Cygwin 1.7.1 officially next week. Bugfixes in relation to 1.7.0-67: = - Fix a bug in dup(2) which disallowed to duplicate file descriptors for the virtual directories /proc/registry, /proc/registry32, and /proc/registry64. - Fix send(2) not to split UDP datagrams into multiple network packets. - Make sure user space syslog entries are never of facility SYS_KERN. - Fix setfacl(1) to allow deletion of default entries for the owner and owner group. FAQ: - Q: How do I know that I'm running Cygwin 1.7.0-68? A: The `uname -v' command prints "2009-12-04 17:08" Have fun, Corinna *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=3d3dyourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:cygwin@cygwin.com Red Hat, Inc. -- 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: Problem with bash script running under NT AUTHORITY\SYSTEM
On 12/04/2009 03:46 AM, Csaba Raduly wrote: On Wed, Dec 2, 2009 at 11:50 PM, Larry Hall (Cygwin) wrote: Remember, SYSTEM is not you. Unless Louis XIV was a Cygwin user, in which case he might have said Le systéme, c'est moi! :-) On Thu, Dec 3, 2009 at 5:02 PM, Almo<> wrote: Ok, it's that SYSTEM running through cygwin has no access to the disk. So someone else wrote the script to run in DOS, and we've dropped the idea of scripting scheduled tasks with cygwin. Unless I can figure out how to get SYSTEM access to the disk through it. :) Perhaps NT AUTHORITY/SYSTEM should be given access rights to the appropriate directory (right click, Properties, Security). It's just an "account" like any other. I'm somewhat puzzled though. On my machine, SYSTEM has full access to C:. Is this a network drive ? Certainly the OP or any individual is within their rights (assuming they are the system admin) to add the access needed. Or a different user with these permissions and any others needed could be created and the service could be run under this new user instead. This, of course, isn't a "Cygwin thing" and won't be automated by Cygwin. I'm pretty confident that you weren't suggesting it should be automated but I figured I'd point this out for the sake of the archives. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: [1.5] question about python/ctypes/dlopen
> On 12/4/2009 23:33, kiorky wrote: import ctypes
ctypes.CDLL("/bin/cygwin1.dll");
>
>
> It seems to work. I suggest loading other dlls for testing.
I forgot to say that it is for that specific dll that it do not work.
But other stuff depending on geos has been compiled including gdal for example.
So i think this dll may not be broken, but something is missing, rights or so, i
dont know.
--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
signature.asc
Description: OpenPGP digital signature
Re: [1.5] question about python/ctypes/dlopen
On 12/4/2009 23:33, kiorky wrote:
JonY a écrit :
On 12/4/2009 22:53, kiorky wrote:
Hi,
have you tried loading "cyggeos_c-1.dll" instead of the import library?
Yep, just look at the second part of the first mail
It results in "bad address" instead of "permission denied"
Hi,
Sorry, I was jumping to conclusions, I'm not a python guru either. I
tried with:
>>> import ctypes
>>> ctypes.CDLL("/bin/cygwin1.dll");
It seems to work. I suggest loading other dlls for testing.
--
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: does LD_PRELOAD work under cygwin?
On Fri, Dec 04, 2009 at 01:04:33PM +0800, basic wrote:
>Hi,
> Does LD_PRELOAD work under cygwin? I've tried the following without success:
>
>gcc test.c
>gcc -shared testlib.c -o testlib.dll
>
>LD_PRELOAD=$HOME/testlib.dll ./a.exe
>
>where test.c is:
>
>#include
>
>int main()
>{
>open("", 1);
>return 0;
>}
>
>
>and testlib.c is:
>
>#include
>
>int open(const char *s, int i, ...)
>{
>puts("test");
>return 0;
>}
>
>Is there anything I'm doing wrong? Or is it just not supported?
If the above is exactly what you are doing then you're not marking
open as "dllexport" so it won't be callable.
cgf
--
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: [1.5] question about python/ctypes/dlopen
JonY a écrit : > On 12/4/2009 22:53, kiorky wrote: > Hi, > > have you tried loading "cyggeos_c-1.dll" instead of the import library? > Yep, just look at the second part of the first mail It results in "bad address" instead of "permission denied" -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature
Re: [1.5] question about python/ctypes/dlopen
On 12/4/2009 22:53, kiorky wrote:
Hello, i'm trying to use python ctypes which use under the hood dlopen.
I have a strange permission denied running this following code, if someone have
clues ...
Base code
$ cat test_ctypes.py
from ctypes import CDLL
CDLL('libgeos_c.dll.a')
Hi,
have you tried loading "cyggeos_c-1.dll" instead of the import library?
--
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: Why does exiting bash window kill off Gvim? (Windows version, but X-would be same question)
Linda Walsh wrote:
In bash I start a copy of gvim.exe (64-bit windows version) in
background.
I disown the job in bash so bash no longer manages the job -- it
should be
a free and clear process (unaffected by bash exiting).
Yet when I exit the bash window (bash running in a console window), Gvim
is killed. Why should bash or the console exiting kill off any processes
running in the background?
I have had the same frustration for a while. When in a bash shell start
gvim with:
cmd /c gvim
then you can exit the bash shell without killing gvim.
FWIW:
I am using gvim v7.0 for 32bit MS-Windows
it is set up as a server by sourcing the following in .bash_profile:
function gvim
{
if [ -z "$1" ] ; then
$VIMRUNTIME/gvim.exe --servername GVIM &
else
$VIMRUNTIME/gvim.exe --servername GVIM --remote-silent $1 &
fi
}
cheera,
roger wells
It would be the same question of it was the win32-X based Gvim -- it
would
be killed as well, but one could argue that cygwin has to shut down all
cygwin processes when it exits -- but I still don't see that as being
necessary.
It's certainly not what happens when I log into a linux workstation and
bring up Gvim displaying locally (an X version, not a Windows
version...:-)). I can terminate the tty window to a linux box and the X
program just keeps on running (unless I was running it's display
through a
copy of SSH that terminates with the window's exit. I try to avoid that
on my local network.
So why does cygwin have to terminate any processes when I exit the shell
window? If I've disowned the job, I obviously don't care about any
output
-- I could use nohup in front of it, if I wanted to capture such, but it
wouldn't matter, they all seem to be required to die, and I don't
understand why.
I find it ironic to think about the discussion about characters when
something important like jobs running in background normally doesn't even
work right, but I don't understand why it has to be that way.
I find it *especially* annoying, when it kills off a windows program --
there can be no good reason for that.
I guess I also don't quite get why I don't get back immediate control
when I start gvim under bash.exe, but if I start cmd.exe within bash,
then gvim behaves 'normally' (auto backgrounds and doesn't terminate
when cygwin does). So it's obvious that there's no reason, at least,
why cygwin should "go out of its way" to kill off any launched
processes. Or does it not do that?
linda
--
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
--
Roger Wells, P.E.
SAIC
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@saic.com
--
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: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes
Dear Ed -- I posted this a couple of days ago under another thread. Here is the rebase procedure that works for me: /bin/rebase -d -b 0x6100 -o 0x2 -v -T > rebase.out and /bin/peflags -d0 -v -T > peflags-d.out /bin/peflags -t0 -v -T > peflags-t.out Note particularly the base and -o values, and be sure the check the output. Also, you have to do all this under ash, etc., and build a list of files first with find (or just list particular directories' files). I found there ae one or two files I had to exclude because rebase halts on them. Best wishes -- Eliot Moss -- 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: [1.7] cygwin2 performance issue during compilation with autotools
Maybe is there a bug in cygcheck ? Maybe there are others ways that looking in env['PATH'] to construct your "Pathes check" that i am not aware ? Maybe PATH is not related to performance issues, afterall... But for the moment, and my current knowledge, i don't see any duplicates in the $PATH variable. kiorky a écrit : > mak...@apem3 ~ > $ echo $PATH > /cygdrive/e/minitage2/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/e/Subversion/bin:/cygdrive/e/OpenLDAP/CD > SSilver/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/system32 > /WindowsPowerShell/v1.0:/cygdrive/e/Program Files/TortoiseSVN/bin > > Do you see any duplicates ... > -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF signature.asc Description: OpenPGP digital signature
Re: R: does LD_PRELOAD work under cygwin? (solved)
On 12/04/2009 04:57 PM, basic wrote:
> On 12/04/2009 03:05 PM, Marco Atzeri wrote:
>> --- Ven 4/12/09, basic ha scritto:
>>
>>> Hi,
>>> Does LD_PRELOAD work under cygwin? I've tried the
>>> following without success:
>>
>> LDPRELOAD works with few peculiarites for multiple dll's
>> but this is not your case.
>>
>>>
>>> gcc test.c
>>> gcc -shared testlib.c -o testlib.dll
>>
>> see documentation
>> http://cygwin.com/cygwin-ug-net/dll.html
>> on how to build and link dll's
> I've read the document, but I do not see what I'm doing is any different from
> it. Any hints?
After searching the mailing lists more, I found
http://sourceware.org/ml/cygwin/2008-03/msg00547.html
I got it to work by adding a call to cygwin_internal (CW_HOOK, "open", open);
to a DllMain
function in testlib.c.
>
>>
>>>
>>> LD_PRELOAD=$HOME/testlib.dll ./a.exe
>>>
>>> where test.c is:
>>>
>>> #include
>>>
>>> int main()
>>> {
>>> open("", 1);
>>> return 0;
>>> }
>>>
>>>
>>> and testlib.c is:
>>>
>>> #include
>>>
>>> int open(const char *s, int i, ...)
>>> {
>>> puts("test");
>>> return 0;
>>> }
>>>
>>> Is there anything I'm doing wrong? Or is it just not
>>> supported?
>>>
>>> --
>>> basic
>>>
>> regards
>> Marco
>>
>>
>>
>>
>
>
> --
> basic
>
> --
> 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
>
--
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: operation not permitted when attempting to ping
On Dec 3 21:08, Robert Pendell wrote: > On Thu, Dec 3, 2009 at 7:54 PM, Larry Hall (Cygwin) wrote: > > On 12/03/2009 07:35 PM, Robert Pendell wrote: > >> > >> Whenever I use ping it returns the message socket: Operation not > >> permitted. This only happens if I am not running the shell as an > >> administrator otherwise it works fine.. The windows stock ping > >> command doesn't need admin rights to run. I am running Windows 7 and > >> cygwin 1.7. Attached is my cygcheck output. > > > > Yep. Known issue. Actually, the only reason Cygwin still has its own ping > > is > > some people prefer it over the Windows version (and the complaints against > > it have been low volume). Anyway, this is the long way of saying "That's > > the > > way it works and it's unlikely to change". > > > > Ahh... ok. I dug up an old thread on this. Looks like it is a UAC > thing then. Thanks for the info. It's UAC only indirectly. It's basically the fact that raw sockets as used by ping can only be created by admin users. That's why ping on Linux has the suid-bit set in the permission bits. We still don't support that, unfortunately. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Base-Files (was Re: Unset TMP/TEMP in profile?)
On Dec 4 10:08, Angelo Graziosi wrote: > What about USERNAME and USER? > > Some time ago, I changed my /etc/passwd so that Administrator is > called 'root' in Cygwin, but USERNAME still points to Administrator > instead USER points to 'root'. > > Following this discussion I would ask if we should have, in Cygwin, > the initialization export USERNAME="$USER" in some place... I don't see how this would be correct. $USERNAME is a variable used by Windows tools while $USER is used by POSIX tools. If your Cygwin username is different from the Windows username, then $USER and $USERNAME reflect this in their respective world. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Base-Files (was Re: Unset TMP/TEMP in profile?)
What about USERNAME and USER? Some time ago, I changed my /etc/passwd so that Administrator is called 'root' in Cygwin, but USERNAME still points to Administrator instead USER points to 'root'. Following this discussion I would ask if we should have, in Cygwin, the initialization export USERNAME="$USER" in some place... Ciao, Angelo. -- 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: R: does LD_PRELOAD work under cygwin?
On 12/04/2009 03:05 PM, Marco Atzeri wrote:
> --- Ven 4/12/09, basic ha scritto:
>
>> Hi,
>> Does LD_PRELOAD work under cygwin? I've tried the
>> following without success:
>
> LDPRELOAD works with few peculiarites for multiple dll's
> but this is not your case.
>
>>
>> gcc test.c
>> gcc -shared testlib.c -o testlib.dll
>
> see documentation
> http://cygwin.com/cygwin-ug-net/dll.html
> on how to build and link dll's
I've read the document, but I do not see what I'm doing is any different from
it. Any hints?
>
>>
>> LD_PRELOAD=$HOME/testlib.dll ./a.exe
>>
>> where test.c is:
>>
>> #include
>>
>> int main()
>> {
>> open("", 1);
>> return 0;
>> }
>>
>>
>> and testlib.c is:
>>
>> #include
>>
>> int open(const char *s, int i, ...)
>> {
>> puts("test");
>> return 0;
>> }
>>
>> Is there anything I'm doing wrong? Or is it just not
>> supported?
>>
>> --
>> basic
>>
> regards
> Marco
>
>
>
>
--
basic
--
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: Problem with bash script running under NT AUTHORITY\SYSTEM
On Wed, Dec 2, 2009 at 11:50 PM, Larry Hall (Cygwin) wrote: > Remember, SYSTEM is not you. Unless Louis XIV was a Cygwin user, in which case he might have said Le systéme, c'est moi! On Thu, Dec 3, 2009 at 5:02 PM, Almo <> wrote: > > Ok, it's that SYSTEM running through cygwin has no access to the disk. > > So someone else wrote the script to run in DOS, and we've dropped the idea > of scripting scheduled tasks with cygwin. Unless I can figure out how to get > SYSTEM access to the disk through it. :) Perhaps NT AUTHORITY/SYSTEM should be given access rights to the appropriate directory (right click, Properties, Security). It's just an "account" like any other. I'm somewhat puzzled though. On my machine, SYSTEM has full access to C:. Is this a network drive ? Csaba -- Life is complex, with real and imaginary parts -- 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
