Cygwin 1.7.7 - /bin/ls hangs?
Hi all, I recently upgraded to 1.7.7 and a script that I use to set up a lot of environment variables is now hanging. The problem is quite unpredictable and I am struggling to find ways to reliably reproduce or diagnose. I am using csh (tcsh) and 'source'-ing a script but I have seen 'bash' hang just running: bash-3.2$ ls /usr/bin (although not today!) Typically I do something like: % source /cygdrive/h/jek/bin/jSetfor.csh and with 'echo' set it runs to: ... if ( -d /cygdrive/s/syb1503/shared ) then setenv SYBASE_JRE /cygdrive/s/syb1503/shared/`ls $SYBHOME/shared/|fgrep jre|tail -1` ls /cygdrive/s/syb1503/shared/ tail -1 Run again and this time it gets further but hangs with: ... if ( -d /cygdrive/s/syb1503/REP-15_2/lib3p ) then endif setenv SYBASE_RPL `ls $SYBHOME|fgrep RPL-|tail -1` ls /cygdrive/s/syb1503 fgrep RPL- My guess is a timing issue - perhaps in the pipe? Any thoughts on what is going wrong or what I can do to avoid it? Many thanks and Happy New Year, - jon. -- 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: drand48() (and erand48) returns only zeros and pthread application problems
About drand48() (and erand48) returns only zeros and pthread
application problems, I send this mail to both cygwin and newlib
mailist.
I have compared Cygwin with FreeBSD function implementation:
=> In Cygwin newlib, srand48 and drand48 use "__rand48_seed" and
"__rand48_mult" that are defined as:
#define __rand48_seed _REENT_RAND48_SEED(r)
#define __rand48_mult _REENT_RAND48_MULT(r)
#define _REENT_RAND48_SEED(ptr)
((ptr)->_r48->_seed)
#define _REENT_RAND48_MULT(ptr)
((ptr)->_r48->_mult)
where "r" has "_REENT" value, defined as# define
_REENT (__getreent()) that is a pointer to thread data
so, in cygwin srand48 and drand48 uses __getreent()->_r48->_seed
and __getreent()->_r48->_multi that are thread local variables.
=> In FreeBSD libc, last version, srand48 and drand48 use
"_rand48_seed" and "_rand48_mult" that are defined as a global
variable:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/_rand48.c
unsigned short _rand48_seed[3] = {
RAND48_SEED_0,
RAND48_SEED_1,
RAND48_SEED_2
};
unsigned short _rand48_mult[3] = {
RAND48_MULT_0,
RAND48_MULT_1,
RAND48_MULT_2
};
=> As Christopher Faylor said in his mail, I think the solution
would be to modify newlib implementation (files: drand48.c erand48.c
jrand48.c lcong48.c lrand48.c mrand48.c nrand48.c rand48.c
rand48.h seed48.c srand48.c) and adapt freebsd last version, using
global variables for seed, mult and rest internal srand48/drand48
variables.
=> This modifications will solve the two problems: lack of seed
initialization and pthread drand48 problems.
On Wed, Dec 29 2010 01:34:18 -0500, Christopher Faylor wrote:
> On Wed, Dec 29, 2010 at 03:47:42AM +0100, Jorge D?az wrote:
> >I am working with cygwin environment (Cygwin 1.7.7 + Newlib 1.18)
> >where drand48 function returns always zero values.
> >
> >The problem was reported in 2004 at cygwin mailist:
> >1) http://cygwin.com/ml/cygwin/2004-11/msg00488.html
> >2) http://cygwin.com/ml/cygwin/2004-11/msg00513.html
> >
> >It seems the problem is at drand48 internal initialization. As a
> >workaround if srand48 is called at program beginning, future drand48
> >calls works ok, but this srand48 call is not mandatory.
> >
> >A main problem related with drand48 returning only zeros are cygwin
> >pthread applications that uses drand48:
> >1) We execute srand48 initialization as a workaround of drand48
> >problems in main function.
> >2) After this, if we create several threads, the new threads created
> >in application, has the same zeros problem, but we called srand48 in
> >main function.
> >
> >The application behavior in Cygwin is like every thread has its own
> >"srand48, drand48 and erand48" internal environment and the generated
> >numbers are isolated. In linux and solaris, generated numbers are
> >mixed between all threads.
>
> That is exactly what is happening but, as I noted in the above discussion,
> this behavior is a bug.
>
> I've implemented a workaround which will show up in the next snapshot.
> But, perhaps someone will want to figure out what's wrong with newlib and
> implement a real fix.
>
> I see that freebsd doesn't have this problem so, since that is the code
> base from which the *48 functions are derived, maybe this has actually
> been fixed and newlib could benefit from that.
>
> 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
[ANNOUNCEMENT] [experimental] Updated: readline-6.1.2-1, libreadline7-6.1.2-1
A new release 6.1.2-1 for readline and libreadline7 is now available for testing, while leaving 6.0.3-2 as current. NEWS: = This is a test release of a new upstream release. I'm working on preparing bash 4.1 for cygwin, which requires a newer readline package; once that is working, I will promote this package to current. Use of this update requires libgcc1 and libncurses10 (setup.exe doesn't make it easy to list different dependencies for a test package than for the current package). See also the upstream documentation in /usr/share/doc/readline/. NOTES: == Be aware that an issue with offering libreadline as both a static and dynamic library has been identified - some functions, such as rl_function_of_keyseq, cannot work correctly with both library styles without some additional __declspec decoration in the dynamic case. This release caters to static compilation (and packages like bash that use the problematic functions from dynamic readline have to add a minimal workaround); it is possible that a future package will either be dynamic-only, or that compiling against the static readline-6.0 will require the declaration of a preprocessor macro, so that dynamic linking works without requiring patches to every client. DESCRIPTION: The readline library will read a line from the terminal and return it, allowing the user to edit the line with emacs or vi editing keys. It also allows a history feature, for editing previous entries, making command line interfaces easier-to-use and more intuitive. libreadline7 provides the .dlls needed for readline and history expansion for dynamic linking in other programs, including bash and gdb; it is required for a minimal cygwin installation. The 7 in libreadline7 distinguishes incompatible API changes made to the prior libreadline5 and libreadline6 libraries still available on the mirrors. readline provides the documentation and the static libraries required for static linking; you should only need it if you plan on compiling an application that links with -lreadline or -lhistory. UPDATE: === To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'libreadline7' from the 'Base' category (it should already be selected), or 'readline' in the 'Devel' category. Since this is an experimental release, you will need to use the 'Exp' radio button to get access to this version. Be sure that you do not have any cygwin programs running during the upgrade. DOWNLOAD: = Note that downloads from cygwin.com aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Eric Blake volunteer cygwin readline maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to 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=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. This document details the changes between this version, readline-6.1, and the previous version, readline-6.0. 1. Changes to Readline a. The SIGWINCH signal handler now avoids calling the redisplay code if one arrives while in the middle of redisplay. b. Changes to the timeout code to make sure that timeout values greater than one second are handled better. c. Fixed a bug in the redisplay code that was triggered by a prompt containing invisible characters exactly the width of the screen. d. Fixed a bug in the redisplay code encountered when running in horizontal scroll mode. e. Fixed a bug that prevented menu completion from properly completing filenames. f. Fixed a redisplay bug caused by a multibyte character causing a line to wrap. g. Fixed a bug that caused key sequences of two characters to not be recognized when a longer sequence identical in the first two characters was bound. h. Fixed a bug that caused history expansion to be attempted on $'...' single-quoted strings. i. Fixed a bug that caused incorrect redisplay when the prompt contained multibyte characters in an `invisible' sequence bracketed by \[ and \]. j. Fixed a bug that caused history expansion to short-circuit after encountering a multibyte character. k. Fixed a bug that caused applications using the callback interface to not react to SIGINT (or other signals) until another cha
Re: [ANNOUNCEMENT] [experimental] Updated: readline-6.1.2-1, libreadline7-6.1.2-1
FYI. The new readline update has resolved the bash/readline spinout in vi command mode that I reported earlier. Thanks. Eric. -- 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
privilege problem with permanent virtual drives defined as DOS devices
Hello, a privilege problem occures with permanent virtual drives defined as DOS devices. $> uname -a CYGWIN_NT-6.0 meow2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin when have defined dos devices to access a particular path as a permanent virtual drive in each session like the following example: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices] "K:"="\\??\\C:oracle\\doc\\10.2\\doc" no access is possible with a normal user or an admin user with a restricted token - only users with an elevated admin token can access it if explicitly mounted a "No such file or directory" is issued when trying to access the mount point via ls or df while not using an elevated admin token as normal user $_%> df /k df: `/k': No such file or directory df: no file systems processed as elevated admin $_#> df /k Filesystem 1K-blocks Used Available Use% Mounted on K: 110687816 81352392 29335424 74% /k if not explicitly mounted no cygdrive entry occures for such users this privilege problem didn't occure with version before 1.7 $> uname -a CYGWIN_NT-6.0 meow2 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin regards kf -- 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
Why are some default Windows environment variables not set when logging in via ssh?
When I run a cygwin bash terminal directly from Windows, I get all the standard Windows environment variables properly set. However, when I login in via ssh, some are properly set (e.g., $USERPROFILE, $ALLUSERSPROFILE, $HOMEDRIVE) but others are unset (e.g., $TEMP, $TMP, $APPDATA, $LOCALAPPDAT, PROGRAMFILES). - Is this just a weird artifact of the fact that sshd is run by cyg_server rather than by the actual user (which perhaps explains why the variable $USERNAME is set to cyg_server)? - Even so, why would PROGRAMFILES not be set right since that is presumably not user-dependent? - Is there any logic behind which variables work and which ones don't? - Is there any way to "fix" this so that the variables are set "normally"? (I could kluge this by setting them manually in my bashrc but I would prefer for them to be set right automatically) THanks -- 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
Owner/Group showing up as "??????????" on some Windows files despite mkpasswd/mkgroup
When I do an 'ls -al' (or a getfacl) on some files, I get: owner/group = ???/???, implying that the numeric uid/gid are not found in the passwd/group file. This occurs even though I ran: mkpasswd -cl > /etc/passwd mkgroup --local > /etc/group The /owner and /primary group are displayed in subinacl (often as 'trustedinstaller'). Note that 'trustedinstaller' doesn't appear in my passwd or group files. So, question is why doesn't 'ls -al' and 'getfacl' give a more 'human readable' answer than '???' even if trustedinstaller is a bogus name. Or should I just think of ?? as cygwin for trustedinstaller? --- For example: $ ls -al /c/Window/notepad.exe -rwxrwx---+ 4 193536 2009-07-13 21:39 /c/Windows/notepad.exe $ ls -aln /c/Window/notepad.exe -rwxrwx---+ 4 4294967295 4294967295 193536 2009-07-13 21:39 /c/Windows/notepad.exe $]subinacl /noverbose /nostatistic /fileC:\\Windows\\notepad.exe /display = +File C:\Windows\notepad.exe = /control=0x1c00 /owner =trustedinstaller /primary group =trustedinstaller /audit ace count =1 /aace =everyone Type=0x2 Flags=0xc0 AccessMask=0xd0116 /perm. ace count =4 /pace =trustedinstaller Type=0x0 Flags=0x0 AccessMask=0x1f01ff /pace =builtin\administrators Type=0x0 Flags=0x0 AccessMask=0x1200a9 /pace =system Type=0x0 Flags=0x0 AccessMask=0x1200a9 /pace =builtin\users Type=0x0 Flags=0x0 AccessMask=0x1200a9 -- 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
