Xwin and urxvt-X quit when copy selection
1, Specify -clipboard option to Xwin.exe 2, Open an urxvt-X window 3, Mouse drag and select a text range 4, Then urxvt-X is silently terminated, and Xwin process is terminated, too (the selection wasn't copied) Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.3.0 (10703000) Build Date: 2009-12-22 Contact: cygwin-xf...@cygwin.com XWin was started with the following command line: XWin -multiwindow -clipboard -silent-dup-error -notrayicon -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning 2010-01-17 08:56:24 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 2010-01-17 08:56:24 _XSERVTransOpen: transport open failed for inet6/cls:0 2010-01-17 08:56:24 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 2010-01-17 08:56:25 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2010-01-17 08:56:25 (II) xorg.conf is not supported 2010-01-17 08:56:25 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2010-01-17 08:56:25 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2010-01-17 08:56:25 LoadPreferences: Done parsing the configuration file... 2010-01-17 08:56:25 winGetDisplay: DISPLAY=:0.0 2010-01-17 08:56:25 winDetectSupportedEngines - Windows NT/2000/XP 2010-01-17 08:56:25 winDetectSupportedEngines - DirectDraw installed 2010-01-17 08:56:25 winDetectSupportedEngines - DirectDraw4 installed 2010-01-17 08:56:25 winDetectSupportedEngines - Returning, supported engines 0007 2010-01-17 08:56:25 winSetEngine - Multi Window or Rootless = ShadowGDI 2010-01-17 08:56:25 winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel 2010-01-17 08:56:25 winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32 2010-01-17 08:56:25 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2010-01-17 08:56:25 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2010-01-17 08:56:25 null screen fn ReparentWindow 2010-01-17 08:56:25 null screen fn RestackWindow 2010-01-17 08:56:25 InitQueue - Calling pthread_mutex_init 2010-01-17 08:56:25 InitQueue - pthread_mutex_init returned 2010-01-17 08:56:25 InitQueue - Calling pthread_cond_init 2010-01-17 08:56:25 InitQueue - pthread_cond_init returned 2010-01-17 08:56:25 winInitMultiWindowWM - Hello 2010-01-17 08:56:25 winInitMultiWindowWM - Calling pthread_mutex_lock () 2010-01-17 08:56:25 Screen 0 added at XINERAMA coordinate (0,0). 2010-01-17 08:56:25 winMultiWindowXMsgProc - Hello 2010-01-17 08:56:25 winMultiWindowXMsgProc - Calling pthread_mutex_lock () 2010-01-17 08:56:25 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2010-01-17 08:56:25 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2010-01-17 08:56:30 winPointerWarpCursor - Discarding first warp: 640 512 2010-01-17 08:56:30 (--) 5 mouse buttons found 2010-01-17 08:56:30 (--) Setting autorepeat to delay=500, rate=31 2010-01-17 08:56:30 (--) winConfigKeyboard - Layout: 0409 (0409) 2010-01-17 08:56:30 (--) Using preset keyboard for English (USA) (409), type 4 2010-01-17 08:56:30 Rules = base Model = pc105 Layout = us Variant = none Options = none 2010-01-17 08:56:30 winInitMultiWindowWM - pthread_mutex_lock () returned. 2010-01-17 08:56:30 winProcEstablishConnection - Hello 2010-01-17 08:56:30 winInitClipboard () 2010-01-17 08:56:30 winProcEstablishConnection - winInitClipboard returned. 2010-01-17 08:56:30 winClipboardProc - Hello 2010-01-17 08:56:30 DetectUnicodeSupport - Windows NT/2000/XP 2010-01-17 08:56:30 (II) xorg.conf is not supported 2010-01-17 08:56:30 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2010-01-17 08:56:30 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2010-01-17 08:56:30 LoadPreferences: Done parsing the configuration file... 2010-01-17 08:56:30 winGetDisplay: DISPLAY=:0.0 2010-01-17 08:56:30 winDetectSupportedEngines - Windows NT/2000/XP 2010-01-17 08:56:30 winGetDisplay: DISPLAY=:0.0 2010-01-17 08:56:30 winInitMultiWindowWM - pthread_mutex_unlock () returned. 2010-01-17 08:56:30 winClipboardProc - DISPLAY=:0.0 2010-01-17 08:56:30 winGetDisplay: DISPLAY=:0.0 2010-01-17 08:56:30 winInitMultiWindowWM - DISPLAY=:0.0 2010-01-17 08:56:30 winDetectSupportedEngines - DirectDraw installed 2010-01-17 08:56:30 winDetectSupportedEngines - DirectDraw4 installed 2010-01-17 08:56:30 winDetectSupportedEngines - Returning, supported engines 0007 2010-01-17 08:56:30 winSetEngine - Multi Window or Rootless = ShadowGDI 2010-01-17 08:56:30 winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32 2010-01-17 08:56:30 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2010-01-17 08:56:30 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 2010-01-17 08:56:30 null screen fn ReparentWindow 2010-01-17 08:56:30 null screen fn RestackWindow
cygpath output unnecessary ending slash/
When specify --windows or --mixed form, cygpath will append `/' to the result path when it is a directory, this is unnecessary and inconformity, for example: cygpath -u some/dir some/dir cygpath -m some/dir some/dir/ cygpath -w . x:\some\dir\ The ending `\' is only needed when the win32 path points to the drive root, for example /cygdrive/c = C:\, and even this is not a must, because in most cases the path will join another path segment `cygpath -w /cygdrive/c`/path/segment and the slash after the drive letter is duplicated. A severe problem with the ending back-slash \ is it will cause to escape the following quote (, ') character, if [ $cygwin = true ] ; then PROJECT_HOME=`cygpath -w $PWD` else PROJECT_HOME=`pwd` fi # do with $PROJECT_HOME ... The PROJECT_HOME looks like T:\TEMP\ and it cause the following statement can't be parsed correctly: # do with T:\TEMP\ ... the \ is escaped, then apache-forrest-0.8/main/forrest.build.xml /mnt/t/apache-forrest-0.8/tools/ant/bin/ant: eval: line 301: unexpected EOF while looking for matching `' /mnt/t/apache-forrest-0.8/tools/ant/bin/ant: eval: line 302: syntax error: unexpected end of file -- 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: ldd in cygwin
On 2009-10-1 13:44, Steven Woody wrote: Hi, In Linux, we can get a library dependency list by running of 'ldd'. In windows, executable still depend on libraries, such as DLLs, but I don't find a 'ldd' command in cygwin. Is there any tool that will do the job? Thanks. There is a cygwin ldd, in cygwin $ cd /etc/setup $ zgrep ldd * cygwin.lst.gz:usr/bin/ldd.exe -- 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] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-18 14:09, Christopher Faylor wrote: I think the main person you should be thanking isn't a guy. Ok. Thank you gods. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Mounting EXT2FS as Windows filesystem
On 2009-5-18 20:24, Kelly Jones wrote: I just did: dd if=/dev/zero of=test.fs bs=1 count=1 /usr/sbin/mke2fs.exe test.fs to create an EXT2FS. Question: how do I mount this so that Windows sees it as a regular filesystem? My goal is to create something that's both a single file and also a filesystem. Reason: Mozy backup encrypts files but not filenames. If I have a single file that's also a filesystem, I can just back that up and filename encryption is automatic. I tried doing this w/ ZIP files. Windows Explorer recongizes these as folders, but many Windows apps don't. I've been using TrueCrypt volumes for years, it has win32 and linux versions (maybe Mac and more?), the volume image is portable, though encryption isn't my purpose, but it's a valuable add. However you can't disable encryption. And, there is ext2fs IFS driver, see http://www.fs-driver.org/ Both TrueCrypt and Ext2fs IFS driver don't support mountpoint directly. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 10:09, IWAMURO Motonori wrote: 2009/5/17 Lenikle...@bodz.net: Thanks, but where can I get this patch? You can checkout it from CVS HEAD. Thanks for your information, well, I'm not expect to build from source, that really frustrates me, and brings me even more problems. Is there any mirror site for nightly builds? so I can use rsync to get it (If this patch is too minor to increase any of the version numbers). I've just looked at snapshots, but the last update time is 2009-05-13. I can't build from source, here are some errors, I guess there will be more errors, so I hope someone will compile cygpath at the first time, 6 weeks to the next release maybe too long to wait. 1, cvs update failed: ... (ignored) cvs update: Updating src/winsup/testsuite/winsup.api/samples cvs update: Updating src/winsup/utils cvs update: Updating src/winsup/w32api cvs update: Updating src/winsup/w32api/include cvs update: Updating src/winsup/w32api/include/GL cvs update: Updating src/winsup/w32api/include/ddk cvs update: Updating src/winsup/w32api/include/directx cvs update: Updating src/winsup/w32api/lib cvs update: Updating src/winsup/w32api/lib/ddk cvs update: Updating src/winsup/w32api/lib/directx cvs update: closing down connection to cygwin.com: Transport endpoint is not connected 2, configure failed: bash-3.2$ ./configure 5 [main] expr 952 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ./configure: line 56: 952 Segmentation fault (core dumped) expr a : '\(a\)' /dev/null 21 4 [main] expr 2808 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3516 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3328 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2648 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 900 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 1840 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2972 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) Thanks, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
rsync: send_files failed to open
11044 files in 3.87GB are correctly rsynced, while several files are failed.
see the output.
These files are marked as Permission denied (13), and my local
directories are writable.
--
# rsync -amv --delete --delete-excluded --exclude-from
./.msync/mod/cygwin.ex --log-file=/var/log/rsync/cygwin.log
rsync://ftp.kaist.ac.kr/cygwin/ cygwin
Welcome to KAIST File Archive, ftp.kaist.ac.kr!
(AKA ftp.kr.debian.org, kr.archive.ubuntu.com, ftp2.kr.vim.org,
{cvsup,ftp}2.kr.freebsd.org)
...
Contact f...@ftp.kaist.ac.kr for any problem or suggestion.
For more information, visit: http://ftp.kaist.ac.kr/
receiving file list ... done
rsync: send_files failed to open
release-2/.unionfs/automake/automake1.9/automake1.9-1.9.6-3-src.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/glpk/libglpk-devel/libglpk-devel-4.35-1.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/hdf5-1.6.8-1-src.tar.bz2_HIDDEN~ (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/hdf5-1.6.8-1.tar.bz2_HIDDEN~ (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/.unionfs/hdf5/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/setup.hint_HIDDEN~ (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/libhdf5-devel/libhdf5-devel-1.6.8-1.tar.bz2_HIDDEN~
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/hdf5/libhdf5-devel/md5.sum (in cygwin): Permission
denied (13)
rsync: send_files failed to open release-2/.unionfs/qhull/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/.unionfs/qhull/setup.hint_HIDDEN~ (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/GNOME/libxml/libxml-devel/libxml-devel-1.8.17-3.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/WordNet/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/apache2/apache2-devel/apache2-devel-2.2.6-1.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/aspell/aspell-dev/aspell-dev-0.60.5-1.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/aspell/aspell-en/aspell-en-6.0.0-1-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/autoconf/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/autoconf/setup.hint (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/bash/bash-completion/bash-completion-20060301-2-src.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/bcrypt/bcrypt-1.1-1-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/bool/bool-0.2.1-1-src.tar.bz2 (in cygwin): Permission denied
(13)
rsync: send_files failed to open release-2/brltty/tcl-brlapi/md5.sum
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/compface/md5.sum (in
cygwin): Permission denied (13)
rsync: send_files failed to open release-2/cron/cron-4.1-6-src.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/cron/md5.sum (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/csih/md5.sum (in cygwin):
Permission denied (13)
rsync: send_files failed to open release-2/curl/curl-7.16.3-1.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/cyrus-sasl/cyrus-sasl-2.1.19-3-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync: send_files failed to open
release-2/epstool/epstool-3.08-2-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/esound/libesound-devel/libesound-devel-0.2.36-1.tar.bz2 (in
cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/esound/libesound-devel/md5.sum (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/esound/libesound0/setup.hint (in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/exif/libexif/libexif-devel/libexif-devel-0.6.16-1.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open release-2/exim/exim-4.68-2.tar.bz2
(in cygwin): Permission denied (13)
rsync: send_files failed to open
release-2/expat/expat-2.0.1-1-src.tar.bz2 (in cygwin): Permission
denied (13)
rsync: send_files failed to open
release-2/expat/libexpat1-devel/md5.sum (in cygwin): Permission denied
(13)
rsync: send_files failed to open
release-2/gail/gail-1.8.8-1-src.tar.bz2 (in cygwin): Permission denied
(13)
rsync: send_files failed to open
release-2/gcc/gcc-objc/gcc-objc-3.4.4-3-src.tar.bz2 (in cygwin):
Permission denied (13)
rsync:
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 19:53, Corinna Vinschen wrote:
On May 17 15:52, Lenik wrote:
On 2009-5-17 10:09, IWAMURO Motonori wrote:
2009/5/17 Lenikle...@bodz.net:
Thanks, but where can I get this patch?
You can checkout it from CVS HEAD.
[...]
6 weeks to the next release maybe too long to wait.
We have about 2 weeks between the test releases.
Corinna
Thank you, I'll be very happy if I can apply your great patch in next
morning if not earlier. I'd rather hope I can get everything immediately
when I read your reply, and IMHO that should be very easy, all what you
have to do is make your working directory public and accessible. Stupid
idea, heh? :)
Currently I resolved it by a simple function:
function _u2w() {
local p=$(cygpath -au $1)
if [ ${p:0:5} = /mnt/ -o ${p:0:10} = /cygdrive/ ]; then
p=${p:1}
p=${p#*/}
p=${p/\//:/}
else
if [ ${p:0:9} = /usr/bin/ ]; then p=${p:4}; fi
if [ ${p:0:9} = /usr/lib/ ]; then p=${p:4}; fi
p=$(cygpath -am /)$p
fi
p=${p//\//\\}
echo $p
}
path=$(_u2w $path)
Lenik
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: expr error
On 2009-5-17 22:53, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Are you sure you don't have some competing tools getting in the way of proper cygwin operation? No, I've set PATH to cygwin/bin only, before execute expr. stackdump added. Exception: STATUS_ACCESS_VIOLATION at eip=0524 eax=0524 ebx=0001 ecx=7C80E6CB edx= esi=691C4DA4 edi=0005 ebp=0022CD28 esp=0022CD1C program=C:\lam\sys\cygwin-1.7\bin\expr.exe, pid 1392, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022CD28 0524 (, 691E, 0022CD90, 61020340) 0022CDB8 61020273 (, 0022CDF0, 610066A0, 7FFDB000) End of stack trace 63574 [main] expr 1392 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 65368 [main] expr 1392 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: expr error
On 2009-5-18 7:42, Dave Korn wrote: Lenik wrote: Are you sure you don't have some competing tools getting in the way of proper cygwin operation? No, I've set PATH to cygwin/bin only, before execute expr. Doesn't necessarily mean there aren't system-wide hooks being loaded into every application running. This is hard to say, but I think my system is ok, all tools in coreutils except expr are ok to run. stackdump added. Can you get this to reproduce under GDB? A backtrace from the exception caught there, plus the output from info files, would tell us more. From the tiny bit of stackdump it managed to output before crashing, it does look like either the stack is very corrupted, or the program counter ended up in a rather unexpected area of memory owing to some intercepting DLL or similar. I don't know how to do in detail, this is what I get, I don't have debug symbols. (gdb) run Starting program: /usr/bin/expr [New thread 3988.0xd84] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 3988.0x9f4] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) Thanks, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: expr error
ok, (gdb) run Starting program: /usr/bin/expr [New thread 2412.0x92c] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New thread 2412.0xcb8] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) bt #0 0x0524 in ?? () #1 0x69181041 in ?? () from /usr/bin/cyggmp-3.dll #2 0x691c9000 in ?? () from /usr/bin/cyggmp-3.dll #3 0x691ca000 in ?? () from /usr/bin/cyggmp-3.dll #4 0x0022cdb8 in ?? () #5 0x61020273 in per_module::run_ctors () from /usr/bin/cygwin1.dll #6 0x006fa418 in ?? () #7 0x61020340 in dll::init () from /usr/bin/cygwin1.dll #8 0x in ?? () (gdb) info files Symbols from /usr/bin/expr. Win32 child process: Using the running image of child thread 2412.0x92c. While running this, GDB does not access memory from... Local exec file: `/usr/bin/expr', file type pei-i386. Entry point: 0x401000 0x00401000 - 0x00419038 is .text 0x0041a000 - 0x0041a034 is .data 0x0041b000 - 0x0041d380 is .rdata 0x0041e000 - 0x0041e280 is .bss 0x0041f000 - 0x0041f8c4 is .idata 0x7c921000 - 0x7c99d23a is .text in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c99e000 - 0x7c9a1200 is .data in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c9a3000 - 0x7c9b27e4 is .rsrc in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c9b3000 - 0x7c9b5eac is .reloc in /mnt/c/WINDOWS/system32/ntdll.dll 0x7c801000 - 0x7c8841e9 is .text in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c885000 - 0x7c887600 is .data in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c88a000 - 0x7c9173fc is .rsrc in /mnt/c/WINDOWS/system32/kernel32.dll 0x7c918000 - 0x7c91dc84 is .reloc in /mnt/c/WINDOWS/system32/kernel32.dll 0x61001000 - 0x6113f610 is .text in /usr/bin/cygwin1.dll 0x6114 - 0x611414b8 is .autoload_text in /usr/bin/cygwin1.dll 0x61142000 - 0x61167028 is .data in /usr/bin/cygwin1.dll 0x61168000 - 0x611bfd44 is .rdata in /usr/bin/cygwin1.dll 0x611c - 0x611f25d8 is .bss in /usr/bin/cygwin1.dll 0x611f3000 - 0x611fbb0c is .edata in /usr/bin/cygwin1.dll 0x611fc000 - 0x611fc400 is .rsrc in /usr/bin/cygwin1.dll 0x611fd000 - 0x61212a40 is .reloc in /usr/bin/cygwin1.dll 0x61213000 - 0x6121b1e0 is .cygwin_dll_common in /usr/bin/cygwin1.dll 0x6121d000 - 0x6122 is .idata in /usr/bin/cygwin1.dll 0x6122 - 0x6130 is .cygheap in /usr/bin/cygwin1.dll 0x77da1000 - 0x77e155c9 is .text in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e16000 - 0x77e18c00 is .data in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e1b000 - 0x77e43878 is .rsrc in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e44000 - 0x77e48af8 is .reloc in /mnt/c/WINDOWS/system32/advapi32.dll 0x77e51000 - 0x77ed3743 is .text in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77ed4000 - 0x77eda90d is .orpc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edb000 - 0x77edbc00 is .data in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edc000 - 0x77edc3f8 is .rsrc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77edd000 - 0x77ee1494 is .reloc in /mnt/c/WINDOWS/system32/rpcrt4.dll 0x77fc1000 - 0x77fcd224 is .text in /mnt/c/WINDOWS/system32/secur32.dll 0x77fce000 - 0x77fce480 is .data in /mnt/c/WINDOWS/system32/secur32.dll 0x77fcf000 - 0x77fcf418 is .rsrc in /mnt/c/WINDOWS/system32/secur32.dll 0x77fd - 0x77fd0884 is .reloc in /mnt/c/WINDOWS/system32/secur32.dll 0x69181000 - 0x691c4db8 is .text in /usr/bin/cyggmp-3.dll 0x691c5000 - 0x691c8e54 is .data in /usr/bin/cyggmp-3.dll 0x691c9000 - 0x691c9004 is .rdata in /usr/bin/cyggmp-3.dll 0x691ca000 - 0x691ca170 is .bss in /usr/bin/cyggmp-3.dll 0x691cb000 - 0x691cf8c6 is .edata in /usr/bin/cyggmp-3.dll 0x691d - 0x691d0410 is .idata in /usr/bin/cyggmp-3.dll 0x691d1000 - 0x691d2680 is .reloc in /usr/bin/cyggmp-3.dll 0x65b81000 - 0x65b86558 is .text in /usr/bin/cygintl-8.dll 0x65b87000 - 0x65b8703c is .data in /usr/bin/cygintl-8.dll 0x65b88000 - 0x65b88854 is .rdata in /usr/bin/cygintl-8.dll 0x65b89000 - 0x65b895d8 is .bss in /usr/bin/cygintl-8.dll 0x65b8a000 - 0x65b8a5ae is .edata in /usr/bin/cygintl-8.dll 0x65b8b000 - 0x65b8b7e0 is .idata in /usr/bin/cygintl-8.dll 0x65b8c000 - 0x65b8c460 is .reloc in /usr/bin/cygintl-8.dll 0x67c71000 - 0x67c86fe8 is .text in /usr/bin/cygiconv-2.dll 0x67c87000 - 0x67c87008 is .data in /usr/bin/cygiconv-2.dll 0x67c88000 - 0x67d6481c is .rdata in
Re: expr error
On 2009-5-18 11:45, Dave Korn wrote: Lenik wrote: ok, Thanks. Program received signal SIGSEGV, Segmentation fault. 0x0524 in ?? () (gdb) bt #0 0x0524 in ?? () #1 0x69181041 in ?? () from /usr/bin/cyggmp-3.dll #2 0x691c9000 in ?? () from /usr/bin/cyggmp-3.dll #3 0x691ca000 in ?? () from /usr/bin/cyggmp-3.dll #4 0x0022cdb8 in ?? () #5 0x61020273 in per_module::run_ctors () from /usr/bin/cygwin1.dll #6 0x006fa418 in ?? () #7 0x61020340 in dll::init () from /usr/bin/cygwin1.dll #8 0x in ?? () (gdb) info files The info files output confirms there's nothing unusual loaded into the process memory. That makes me think it's not BLODA. The presence of cyggmp-3.dll in the stack trace is interesting; that stack trace looks like it's probably correct, and we are running start-up constructors. Symbols from /usr/bin/expr. 0x69181000 - 0x691c4db8 is .text in /usr/bin/cyggmp-3.dll 0x691c5000 - 0x691c8e54 is .data in /usr/bin/cyggmp-3.dll 0x691c9000 - 0x691c9004 is .rdata in /usr/bin/cyggmp-3.dll 0x691ca000 - 0x691ca170 is .bss in /usr/bin/cyggmp-3.dll 0x691cb000 - 0x691cf8c6 is .edata in /usr/bin/cyggmp-3.dll 0x691d - 0x691d0410 is .idata in /usr/bin/cyggmp-3.dll 0x691d1000 - 0x691d2680 is .reloc in /usr/bin/cyggmp-3.dll 0x65b81000 - 0x65b86558 is .text in /usr/bin/cygintl-8.dll 0x65b87000 - 0x65b8703c is .data in /usr/bin/cygintl-8.dll 0x65b88000 - 0x65b88854 is .rdata in /usr/bin/cygintl-8.dll 0x65b89000 - 0x65b895d8 is .bss in /usr/bin/cygintl-8.dll 0x65b8a000 - 0x65b8a5ae is .edata in /usr/bin/cygintl-8.dll 0x65b8b000 - 0x65b8b7e0 is .idata in /usr/bin/cygintl-8.dll 0x65b8c000 - 0x65b8c460 is .reloc in /usr/bin/cygintl-8.dll 0x67c71000 - 0x67c86fe8 is .text in /usr/bin/cygiconv-2.dll 0x67c87000 - 0x67c87008 is .data in /usr/bin/cygiconv-2.dll 0x67c88000 - 0x67d6481c is .rdata in /usr/bin/cygiconv-2.dll 0x67d65000 - 0x67d654b8 is .bss in /usr/bin/cygiconv-2.dll 0x67d66000 - 0x67d66172 is .edata in /usr/bin/cygiconv-2.dll 0x67d67000 - 0x67d6734c is .idata in /usr/bin/cygiconv-2.dll 0x67d68000 - 0x67d68d00 is .reloc in /usr/bin/cygiconv-2.dll Now, this is interesting. All your DLLs are in very different places to mine, in a working instance of expr.exe: 0x63f41000 - 0x63f84db8 is .text in /usr/bin/cyggmp-3.dll 0x63f85000 - 0x63f88e54 is .data in /usr/bin/cyggmp-3.dll 0x63f89000 - 0x63f89004 is .rdata in /usr/bin/cyggmp-3.dll 0x63f8a000 - 0x63f8a170 is .bss in /usr/bin/cyggmp-3.dll 0x63f8b000 - 0x63f8f8c6 is .edata in /usr/bin/cyggmp-3.dll 0x63f9 - 0x63f90410 is .idata in /usr/bin/cyggmp-3.dll 0x63f91000 - 0x63f92680 is .reloc in /usr/bin/cyggmp-3.dll 0x6f5c1000 - 0x6f5c6558 is .text in /usr/bin/cygintl-8.dll 0x6f5c7000 - 0x6f5c703c is .data in /usr/bin/cygintl-8.dll 0x6f5c8000 - 0x6f5c8854 is .rdata in /usr/bin/cygintl-8.dll 0x6f5c9000 - 0x6f5c95d8 is .bss in /usr/bin/cygintl-8.dll 0x6f5ca000 - 0x6f5ca5ae is .edata in /usr/bin/cygintl-8.dll 0x6f5cb000 - 0x6f5cb7e0 is .idata in /usr/bin/cygintl-8.dll 0x6f5cc000 - 0x6f5cc460 is .reloc in /usr/bin/cygintl-8.dll 0x674c1000 - 0x674d6fe8 is .text in /usr/bin/cygiconv-2.dll 0x674d7000 - 0x674d7008 is .data in /usr/bin/cygiconv-2.dll 0x674d8000 - 0x675b481c is .rdata in /usr/bin/cygiconv-2.dll 0x675b5000 - 0x675b54b8 is .bss in /usr/bin/cygiconv-2.dll 0x675b6000 - 0x675b6172 is .edata in /usr/bin/cygiconv-2.dll 0x675b7000 - 0x675b734c is .idata in /usr/bin/cygiconv-2.dll 0x675b8000 - 0x675b8d00 is .reloc in /usr/bin/cygiconv-2.dll So I think you must have rebased, yes? Interesting. (gdb) info reg eax0x52486245376 ecx0x7c80e6cb2088822475 edx0x00 ebx0x11 esp0x22cd0c0x22cd0c ebp0x22cd180x22cd18 esi0x691c4da41763462564 edi0x2032 eip0x5240x524 eflags 0x10206[ PF IF RF ] cs 0x1b27 ss 0x2335 ds 0x2335 es 0x2335 fs 0x3b59 gs 0x00 (gdb) info frame Stack level 0, frame at 0x22cd10: eip = 0x524; saved eip 0x69181041 called by frame at 0x22cd14 Arglist at 0x22cd08, args: Locals at 0x22cd08, Previous frame's sp is 0x22cd10 Saved registers: eip at 0x22cd0c (gdb) quit Those all look sensible. Right, I think I have a guess what's going on. Please try re-installing libgmp3 using setup.exe and see if it solves the problem for you. I think this might be the same as http://www.cygwin.com/ml/cygwin/2009-02/msg00461.html http://www.cygwin.com/ml/cygwin/2009-02/msg00466.html http://sourceware.org/ml/binutils/2008-07/msg00372.html cheers, DaveK Yes
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-17 15:52, Lenik wrote: 2, configure failed: bash-3.2$ ./configure 5 [main] expr 952 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) ./configure: line 56: 952 Segmentation fault (core dumped) expr a : '\(a\)' /dev/null 21 4 [main] expr 2808 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3516 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 3328 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2648 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 900 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 1840 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) 5 [main] expr 2972 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) The expr error is fixed, and I can build cygpath from source now. Though I don't have NTDDK in hand, I'm suprised how it could be compiled. I can get the correct result from the new cygpath now, without -C option. Thank you guys. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
On 2009-5-16 23:49, Corinna Vinschen wrote: Looks like cygpath gets the wcstombs system call from ntdll rather than from cygwin1.dll due to a linking order problem. Unfortunately ntdll exports a couple of convenient C functions like wcstombs, or even sprintf. I applied a patch so the next version of cygpath should do the conversion more correctly. Corinna Thanks, but where can I get this patch? Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
(This mail is encoded in utf-8) After tested with 1.7.0-48, many problems are eliminated. But cygpath doesn't return good pathnames, see: 1, Get absolute path of current directory: C:\Profiles\Shecti\桌面 set LANG=zh_CN.GBK cygpath -am . C:/Profiles/Shecti/桌面 (good) C:\Profiles\Shecti\桌面 set LANG=zh_CN.GBK cygpath -au . /mnt/c/Profiles/Shecti/桌面/ (good) C:\Profiles\Shecti\桌面 set LANG=zh_CN.UTF-8 cygpath -am . C:/Profiles/Shecti/ (bad) C:\Profiles\Shecti\桌面 set LANG=zh_CN.UTF-8 cygpath -au . /mnt/c/Profiles/Shecti/桌面/ (good) C:\Profiles\Shecti\桌面 set LANG=C cygpath -am . C:/Profiles/Shecti/ (bad) C:\Profiles\Shecti\桌面 set LANG=C cygpath -au . /mnt/c/Profiles/Shecti/桌面/ (good) Conclusion: 1.1 only GBK works for `cygpath -am .' (also -aw) 1.2 all work for `cygpath -au .' 2, Get absolute path of specified path C:\Profiles\Shecti\桌面set LANG=zh_CN.GBK cygpath -am C:\Profiles \Shecti\桌面 C:/Profiles/Shecti/妗岄潰 (bad) C:\Profiles\Shecti\桌面set LANG=zh_CN.GBK cygpath -au C:\Profiles \Shecti\桌面 /mnt/c/Profiles/Shecti/妗岄潰 (bad) C:\Profiles\Shecti\桌面set LANG=zh_CN.UTF-8 cygpath -am C:\Profiles\Shecti\桌面 C:/Profiles/Shecti/ (bad) C:\Profiles\Shecti\桌面set LANG=zh_CN.UTF-8 cygpath -au C:\Profiles\Shecti\桌面 /mnt/c/Profiles/Shecti/桌面 (good) C:\Profiles\Shecti\桌面set LANG=C cygpath -am C:\Profiles\Shecti\桌面 C:/Profiles/Shecti/ (bad) C:\Profiles\Shecti\桌面set LANG=C cygpath -au C:\Profiles\Shecti\桌面 /mnt/c/Profiles/Shecti/桌面 (good) Conclusion: 2.1 none works for `cygpath -am PathContainsNonascii' 2.2 GBK doesn't work for `cygpath -au PathContainsNonascii' Now the problem is, I must use GBK for 1.1, and I cannot use GBK for 2.2. and no more choice. -_-||... Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: zip, unzip doesn't support locale settings
On 2009-5-13 11:23, Christopher Faylor wrote: On Tue, May 12, 2009 at 10:58:00PM +0800, Lenik wrote: (This mail is encoded in utf-8) What is the point of three separate messages when you've already made the point in another thread? cgf Sorry, I think individual package maintainers may notice. please remove it. Thanks, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Proposal: the filename encoding in C locale uses UTF-8 instead of SO/UTF-8
http://cygwin.com/ml/cygwin/2009-05/msg00245.html? I found this web page doesn't display utf-8 characters correctly. BTW, I'm using thunderbird as news reader. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.7, Win 2008 and rebase
On 2009-5-14 5:11, Darren Syzling wrote: I've just installed cygwin 1.7 for use under Winn 2008 - the latest version of 1.7 setup released today. I've read the threads on rebase issues with Vista but so far none of the suggestions help with my git-svn issue. After installation I ran through: ash /usr/bin/rebaseall /usr/bin/peflagsall Rebooted a number of times but whenever I use run git svn: git svn --version I receive: 183 [main] perl 3588 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\bin\cygsvn_subr-1-0.dll to same address as parent(0x6FB3) != 0x6FE6 46 [main] perl 3488 fork: child 3588 - died waiting for dll loading, errno11 Any suggestions or have I may be missed some steps with the new version of rebase? Regards Darren I have uninstalled Vista and backed to XP, the following script is used to launch cpan for the same error in Vista. I don't know whether it can solve git svn's problem. And it's written several months ago for cygwin 1.7.0-35(or earlier), maybe not work for the most latest version. 1) bash session: find /etc/setup -name '*.lst.gz' | xargs gzip -d -c | grep -E \.(dll|so)\$ | sed -e '/cygwin1.dll$/d' -e 's/^/\//' /tmp/libs greplib/perl5 /tmp/libs /tmp/libs-perl5 grep -v lib/perl5 /tmp/libs /tmp/libs-nonperl find /usr/lib/perl5 -iname *.dll /tmp/libs-perl5 sort -u /tmp/libs-perl5 /tmp/libs-p 2) quit bash and start a new cmd.exe session: rebase -vdb 0x7000 -o 0x10 -T /tmp/libs-nonperl rebase -vdb 0x1000 -o 0x2 -T /tmp/libs-p See also, http://lenik.99jsj.com/programming/cygwinperl-fatal-error-under-vista Good luck, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin 1.7, Win 2008 and rebase
On 2009-5-14 8:13, Lenik wrote: On 2009-5-14 5:11, Darren Syzling wrote: I've just installed cygwin 1.7 for use under Winn 2008 - the latest version of 1.7 setup released today. I've read the threads on rebase issues with Vista but so far none of the suggestions help with my git-svn issue. After installation I ran through: ash /usr/bin/rebaseall /usr/bin/peflagsall Rebooted a number of times but whenever I use run git svn: git svn --version I receive: 183 [main] perl 3588 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\bin\cygsvn_subr-1-0.dll to same address as parent(0x6FB3) != 0x6FE6 46 [main] perl 3488 fork: child 3588 - died waiting for dll loading, errno11 Any suggestions or have I may be missed some steps with the new version of rebase? Regards Darren I have uninstalled Vista and backed to XP, the following script is used to launch cpan for the same error in Vista. I don't know whether it can solve git svn's problem. And it's written several months ago for cygwin 1.7.0-35(or earlier), maybe not work for the most latest version. 1) bash session: find /etc/setup -name '*.lst.gz' | xargs gzip -d -c | grep -E \.(dll|so)\$ | sed -e '/cygwin1.dll$/d' -e 's/^/\//' /tmp/libs grep lib/perl5 /tmp/libs /tmp/libs-perl5 grep -v lib/perl5 /tmp/libs /tmp/libs-nonperl find /usr/lib/perl5 -iname *.dll /tmp/libs-perl5 sort -u /tmp/libs-perl5 /tmp/libs-p 2) quit bash and start a new cmd.exe session: rebase -vdb 0x7000 -o 0x10 -T /tmp/libs-nonperl rebase -vdb 0x1000 -o 0x2 -T /tmp/libs-p See also, http://lenik.99jsj.com/programming/cygwinperl-fatal-error-under-vista Good luck, Lenik and you may try different values for base/offset, using a larger value instead of 0x10, that's how I resolved the cpan's problem. Maybe someone will make a better rebaseall utility. Hope helps. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Question of the necessity of rebaseall
Imagebase in PE header is something a bit of optional, that means if two dlls with same imagebase, the OS kernel will automaticly relocate one of them, to put them in different virtual spaces. So, rebase should be a utility for optimizing the overall start-up speed, to reduce avoidable relocations, rather then fix start-up errors. Any idea? Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Strange behavior of cygwin setup preferences
When I have a fresh new installed OS, say XP, and the first time to install cygwin using cygwin setup utility, I can see a lot of components. After the first installation, however it's completed installed or be canceled, Then I launch the setup again, most components are gone. It looks like this, the setup remembered which components I've selected, and saved my selection to the win32 registry or somewhere, whatever, I don't know where it saved and I can't find it. Is there any command line option to force the setup.exe consider it's the first to install? Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
On 2009-5-14 8:55, Larry Hall (Cygwin) wrote: Lenik wrote: Imagebase in PE header is something a bit of optional, that means if two dlls with same imagebase, the OS kernel will automaticly relocate one of them, to put them in different virtual spaces. So, rebase should be a utility for optimizing the overall start-up speed, to reduce avoidable relocations, rather then fix start-up errors. Any idea? cygwin1.dll cannot be relocated if the fork semantics are to work. So while what you say above is true for apps in general, it's not true for Cygwin apps. I can't figure out how fork will break the relocation, for libraries have been loaded, they're already relocated before invoke into fork, and for libraries haven't been loaded, they don't need to share memory after new processes created by fork. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question of the necessity of rebaseall
On 2009-5-14 9:34, Larry Hall (Cygwin) wrote: Lenik wrote: On 2009-5-14 8:55, Larry Hall (Cygwin) wrote: Lenik wrote: Imagebase in PE header is something a bit of optional, that means if two dlls with same imagebase, the OS kernel will automaticly relocate one of them, to put them in different virtual spaces. So, rebase should be a utility for optimizing the overall start-up speed, to reduce avoidable relocations, rather then fix start-up errors. Any idea? cygwin1.dll cannot be relocated if the fork semantics are to work. So while what you say above is true for apps in general, it's not true for Cygwin apps. I can't figure out how fork will break the relocation, for libraries have been loaded, they're already relocated before invoke into fork, and for libraries haven't been loaded, they don't need to share memory after new processes created by fork. You have it backwards. Forking doesn't break the relocation. Relocation breaks forking. cygwin1.dll needs to have a very special memory layout to implement the fork semantics in Win32. If this memory layout is disrupted, fork breaks. Relocating cygwin1.dll disrupts the required memory layout. 'rebaseall' does its best to locate all Cygwin DLLs that it knows of into a layout that avoids collisions. This maintains the required memory layout so fork can do its job. Could you explain in more detail? I can't find any document about this special memory layout. Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin programs doesn't support non-ASCII filenames
On 2009-5-9 23:44, Corinna Vinschen wrote: On May 9 23:12, Lenik wrote: The same result, it shows that `cat' from binutils can support locale well, while `d' isn't. Ok, but that's not Cygwin's problem, just the d tool would need an update at one point, perhaps. OTOH, what you're doing is a bit borderline. When you start this stuff from cmd, you will have to enter the filename in the notation valid for the locale in which the application works. For d, which only works in the C locale, you would have to give the pathname using the SO/UTF-8 sequences. Right now I have no idea if there's a workaround for that, but keep in mind that we're at the beginning of real native language support. Unfortunately it's all a bit more complicated than on non-Windows systems, given the UTF-16-ness of the underlying system. I'd like to know if there is any build plan to upgrade tools like d, zip, unzip, jar, etc. to support locale settings, rather than C only. So I can tell customers when our cygwin-based scripts will work for Chinese path names. Or is there documented ways to build with locale support from source code? Currently the two tools `jar' and `unzip' which don't support locale settings prevent my scripts being widely deployed. Thank you Corinna, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin programs doesn't support non-ASCII filenames
On 2009-5-12 16:30, Corinna Vinschen wrote: On May 12 15:49, Lenik wrote: I'd like to know if there is any build plan to upgrade tools like d, zip, unzip, jar, etc. to support locale settings, rather than C only. So I can tell customers when our cygwin-based scripts will work for Chinese path names. That depends on the package maintainers and it will certainly not be done within just a couple of days. After all, the Cygwin distro is a volunteer effort. Corinna Is there any hint on how to add locale support to existing packages at source code level? I guess that a specific package maintainer maybe work on a central version, so any change to `grep' or `unzip' for example, will be applied on that central version, so various distros like RHEL, Ubuntu, etc. can share the same changement? If so that is, my changement on `grep' may be required to be test/return-test on the various distros, and only if the package maintainer considers the changement won't break the consistency between the various distros, he will then accept the changes and release it to the cygwin? If I changed a specific package in cygwin distro, I shall send to that specific package maintainer, right? And I still think it may be better to add locale support in cygwin layer(maybe it's not enabled by default, though), if you write a program operates with path names, (most programs access files) you won't do anything about locale settings in common sense, and I didn't see there is necessary to setlocale or somewhat before fopen/fstat() operations in that famous APUX book. C:\Profiles\Shecti set LANG=zh_CN.GBK cat 你好 123 C:\Profiles\Shecti set LANG=C cat 你好 123 C:\Profiles\Shecti set LANG= cat 你好 cat: 你好: No such file or directory The default LANG isn't C neither GBK in codepage 936, I guess it is set to GB2312, but I'm not sure. How can I know the default LANG? Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
d tool doesn't support locale setting
(This mail is encoded in utf-8) bash-3.2$ ls .zip .gz bash-3.2$ echo $LANG bash-3.2$ export LANG=zh_CN.GBK bash-3.2$ ls 好.gz 你好 世界.zip bash-3.2$ d 世界.zip /mnt/c/Profiles/Shecti/lt/世界.zip doesn't exist! FYI 你 = \u4f60 好 = \u597d 世 = \u4e16 界 = \u754c -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
zip, unzip doesn't support locale settings
(This mail is encoded in utf-8) bash-3.2$ ls .zip .gz bash-3.2$ echo $LANG bash-3.2$ export LANG=zh_CN.GBK bash-3.2$ zip a * zip warning: name not matched: 好.gz zip warning: name not matched: 你好 zip error: Nothing to do! (a.zip) bash-3.2$ unzip 世界.zip unzip: cannot find or open 世界.zip, 世界.zip.zip or 世界.zip.ZIP. FYI 你 = \u4f60 好 = \u597d 世 = \u4e16 界 = \u754c -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gzip, gunzip doesn't support locale settings
(This mail is encoded in utf-8) bash-3.2$ ls .zip .gz bash-3.2$ echo $LANG bash-3.2$ export LANG=zh_CN.GBK bash-3.2$ ls 好.gz 你好 世界.zip bash-3.2$ gzip 你好 gzip: 你好: No such file or directory bash-3.2$ gunzip 好.gz gzip: 好.gz: No such file or directory FYI 你 = \u4f60 好 = \u597d 世 = \u4e16 界 = \u754c -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin programs doesn't support non-ASCII filenames
On 2009-5-12 21:54, Corinna Vinschen wrote: On May 9 23:12, Lenik wrote: (This mail is encoded in utf-8) [...] The two chinese characters encoding in: GB2312: d7 c0 c3 e6 UTF-8: e6 a1 8c e9 9d a2 Unicode: \u684c \u9762 [...] This is a new test don't use cygpath: C:\Profiles\Shecti set LANG= bash -c cat ?? cat: ??: No such file or directory I'm just looking into this issue and I do not quite understand how you came up with the filename in this example. Above you mention that the mail is in UTF-8. However, when I look into this email using `od -t x1', the multibyte sequence in your example is e4 bd a0 e5 a5 bd, rather than the aforementioned UTF-8 sequence e6 a1 8c e9 9d a2. Nor does it match the aforementioned GB2312 sequence d7 c0 c3 e6. Can you please explain how the multibyte sequence in the example is related to the above GB2312 and UTF-8 sequences? Corinna Sorry, there are two examples, the first using 桌面, and the second using 你好. You may test either. 桌面：e6 a1 8c e9 9d a2, GB2312=d7 c0 c3 e6 你好：e4 bd a0 e5 a5 bd, GB2312=c4 e3 ba c3 Thanks, Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin programs doesn't support non-ASCII filenames
(This mail is encoded in utf-8) On 2009-5-9 18:02, Corinna Vinschen wrote: [Repeated and additional question. I accidentally sent this as PM. Sorry about that. Let's keep this on the list, please] On May 9 11:43, Lenik wrote: (My system locale is zh_CN) What ANSI codepage is that? And what OEM codepage uses the console Window by default? `chcp' shows codepage is 937 I don't know what's difference between ANSI codepage and OEM codepage. 1, test path set LANG= cygpath -am . C:/Profiles/Shecti/?? set LANG=zh_CN.GBK cygpath -am . C:/Profiles/Shecti/?? set LANG=C cygpath -am . C:/Profiles/Shecti/×ÀÃæ Can you please give us the exact name of the directory in either UTF-8 or UTF-16 notation? The two chinese characters encoding in: GB2312: d7 c0 c3 e6 UTF-8: e6 a1 8c e9 9d a2 Unicode: \u684c \u9762 2, the `test' utility set LANG= bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi fail C:/Profiles/Shecti/?? What you're actually testing here all the time is cygpath in the first place. If you stop using cygpath, start a bash shell and use the Cygwin commands with the paths in POSIX notation, you would have much less trouble. Cygwin is a POSIX emulation layer, after all. Well, I test the pathnames using cygpath because I want to get absolute path so the chinese characters will be included in this test, and I can't type these characters in the console window. The second reason is, I associated .sh file type with bash, as: .sh=C:\lam\sys\cygwin-1.7\bin\bash -c $(cygpath -u '%0') %* This is a new test don't use cygpath: C:\Profiles\Shecti set LANG= bash -c cat 你好 cat: 你好: No such file or directory C:\Profiles\Shecti set LANG=zh_CN.GB2312 bash -c cat 你好 cat: 你好: No such file or directory C:\Profiles\Shecti set LANG=zh_CN.GBK bash -c cat 你好 123 C:\Profiles\Shecti set LANG=zh_CN.UTF-8 bash -c cat 你好 123 C:\Profiles\Shecti set LANG= bash -c d 你好 /mnt/c/Profiles/Shecti/你好 doesn't exist! C:\Profiles\Shecti set LANG=zh_CN.GBK bash -c d 你好 /mnt/c/Profiles/Shecti/你好 doesn't exist! C:\Profiles\Shecti set LANG=zh_CN.UTF-8 bash -c d 你好 /mnt/c/Profiles/Shecti/你好 doesn't exist! The same result, it shows that `cat' from binutils can support locale well, while `d' isn't. If you give me the above information I'll look into fixing cygpath. The GB2312 charset is a subset of GBK charset, and the characters ` ??' is included in GB2312 charset. So in this example, GB2312 SHOULD WORK. Sorry, no. It's documented that GBK is supported, GB2312 isn't. From what I read about GB2312 it's not actually a subset of GBK in terms of character definitions, it's just a subset in terms of supported characters. AFAICS, GB2312 uses chars 0x7f in multibyte sequences which is not feasible for Cygwin. We could support EUC-CN, which seems to be another way to encode GB2312 chars, but I'm not exactly willing to add that now. I'd rather stabilize what we have now and add further charset support in a later, official 1.7 release. So you can use LANG=zh_CN.GBK, but not LANG=zh_CN.GB2312. It's just treated as invalid input. Better: Use LANG=zh_CN.UTF-8. Yes, GB2312 is a subset in terms of supported characters. Is there anyway to know the default locale of current cygwin installation? From the test I found that `unset LANG' and `set LANG=zh_CN.GB2312' just get the same results, so I thought that GB2312 is the default locale. And, I'd like to use UTF-8 too, but I won't chcp to 65001, this will introduce a lot of new problems when deploy to customers' machines. while most programs and files are encoded in GB2312 in the real world. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin programs doesn't support non-ASCII filenames
On 2009-5-9 23:44, Corinna Vinschen wrote: On May 9 23:12, Lenik wrote: (This mail is encoded in utf-8) On 2009-5-9 18:02, Corinna Vinschen wrote: [Repeated and additional question. I accidentally sent this as PM. Sorry about that. Let's keep this on the list, please] On May 9 11:43, Lenik wrote: (My system locale is zh_CN) What ANSI codepage is that? And what OEM codepage uses the console Window by default? `chcp' shows codepage is 937 937?!? Per MSDN there's no 937 codepage, rather a 936 codepage Sorry, it's 936. Ok, but that's not Cygwin's problem, just the d tool would need an update at one point, perhaps. OTOH, what you're doing is a bit borderline. When you start this stuff from cmd, you will have to enter the filename in the notation valid for the locale in which the application works. For d, which only works in the C locale, you would have to give the pathname using the SO/UTF-8 sequences. Right now I have no idea if there's a workaround for that, but keep in mind that we're at the beginning of real native language support. Unfortunately it's all a bit more complicated than on non-Windows systems, given the UTF-16-ness of the underlying system. d is an example, there's more. so I guess it should be resolved in cygwin maybe better... Though I maybe able to use UTF-8 sequences to invoke d tool, but I can't do anything about cwd, for example: bash-3.2$ pwd /mnt/c/Profiles/Shecti/桌面 bash-3.2$ ls Gears Shortcut Sample.lnk hello setup.xj worker.js e-3.4.lnk reply.txt sms.xls bash-3.2$ d - : 0 Jan 01 1970 桌面 The default lcoale is C, as demanded by POSIX. Everything else is in responsibility of the application. Please read But set LANG=C will get a different result, C:\Profiles\Shecti set LANG= bash -c cat 你好 cat: 你好: No such file or directory C:\Profiles\Shecti set LANG=C bash -c cat 你好 123 So I guess the default locale isn't C. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin programs doesn't support non-ASCII filenames
(My system locale is zh_CN) 1, test path set LANG= cygpath -am . C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK cygpath -am . C:/Profiles/Shecti/桌面 set LANG=C cygpath -am . C:/Profiles/Shecti/×ÀÃæ 2, the `test' utility set LANG= bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GB2312 bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D; else echo fail $D; fi ok C:/Profiles/Shecti/桌面 set LANG=C bash -c D=$(cygpath -am .); if [ -d $D ]; then echo ok $D;else echo fail $D; fi fail C:/Profiles/Shecti/×ÀÃæ 3, the `cp' utility set LANG= bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/桌面/a.zip': No such file or directory fail set LANG=zh_CN.GB2312 bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/桌面/a.zip': No such file or directory fail set LANG=zh_CN.GBK bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi ok set LANG=C bash -c F=$(cygpath -am .)/a.zip; if cp -f $F xyz; then echo ok $D; else echo fail $D; fi cp: cannot stat `C:/Profiles/Shecti/×ÀÃæ/a.zip': No such file or directory fail 4, the `d' utility set LANG= bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GB2312 bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=zh_CN.GBK bash -c D=$(cygpath -am .); if d $D; then echo ok $D; else echo fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/桌面 doesn't exist! fail C:/Profiles/Shecti/桌面 set LANG=C bash -c D=$(cygpath -am .); if d $D; then echo ok $D; elseecho fail $D; fi /mnt/c/Profiles/Shecti/▒æ¡▒é¢/C:/Profiles/Shecti/×ÀÃæ doesn't exist! fail C:/Profiles/Shecti/×ÀÃæ Problems: (1) Executables `test', `cp' (and rm, cat, stat, find, etc. seems like all of binutils) supports locale settings, while `d' (and gcc, zip, unzip, gzip, gunzip, jar, vi, etc. not of binutils) are not. (2) Even programs of binutils may not support locale settings correctly, The GB2312 charset is a subset of GBK charset, and the characters ` 桌面' is included in GB2312 charset. So in this example, GB2312 SHOULD WORK. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Bug: Cygwin won't export environ vars to win32 programs, when the current work dir contains non-ascii characters.
On 2009-5-4 16:43, Corinna Vinschen wrote: On Apr 29 16:20, Lenik wrote: (Following example is based on bash, but the same to ash, tcsh, ksh, etc., so this should be bug of cygwin.) [...] (2) With Chinese characters, most variables are lost: C:\Profiles\Shecti\??bash -c cmd /c set COMSPEC=C:\WINDOWS\system32\cmd.exe PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS PROMPT=$P$G C:\Profiles\Shecti\?? [...] cygwin1.dll v0.0 ts=2009/1/27 23:49 Cygwin DLL version info: DLL version: 1.7.0 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 192 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Cygdrive default prefix: Build date: Tue Jan 27 16:49:28 CET 2009 Shared id: cygwin1S5 Try with the latest Cygwin 1.7 DLL. Yours from January still has a bug which results in a broken environment when using native chars in environment variables. This bug has been fixed in 1.7.0-46. Corinna It works. (1.7.0-47) Thank you -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin default path, or system-wide environment?
Here I means when running bash or other shell in non-interactive mode, how can I set up environment variables, and without touch the Win32 System Environment? Default PATH, for example. When PATH variable isn't set, there is a default PATH. But if you set the PATH variable, the default PATH is gone, and then you must add the x:\cygwin\bin to the PATH manually. C:\Profiles\Shectipath PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\cygwin\bin C:\Profiles\Shectibash -c echo $PATH /mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/usr/bin C:\Profiles\Shectiset PATH= C:\Profiles\Shectic:\cygwin\bin\bash -c echo $PATH /usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:. Well, it seems just fine, but NO, THERE IS A BIG PROBLEM, because not everyone have a clean OS, some of them have already installed a cygwin, but in different versions. I found that cygwin-1.7 is very suitable to deploy, because cygwin-1.7 supports fstab, so you don't have to trick with the Win32 Registry any more, you just config the etc/fstab, different cygwins will have their different mount points and won't bother each other at all. But if I must include a specific version of cygwin\bin in the PATH, then this co-existence is break. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Can cygwin boot faster?
I feel it has been slightly faster in cygwin-1.7 than cygwin-1.6. But it
is still very slow compared to msys-1.10. What does cygwin indeed
execute when start up? Is it loaded too much, for example the network
libraries? I noticed that paths leading with two slashes '//', which is
often created by path join functions, for example $prefix/somewhere,
when $prefix points to the root /. When such paths (//...) are
accessed, cygwin seems to treat it as some kind of URL and halt for
several seconds, while msys always merge the duplicated slashes to '/...'.
Because of the slow speed, when I'm programming with cygwin, I will
carefully to invoke command calls to the cygwin executables, to reduce
the start up cost. for example, if I want to uppercase a string, I will
do it in 26 built-in variable expansion as:
VAR=${VAR//a/A}
VAR=${VAR//b/B}
VAR=${VAR//c/C}
...
VAR=${VAR//z/Z}
rather then by simply execute:
VAR=$(echo $VAR | tr [a-z] [A-Z])
because, this execution will add 2 times of start-up delay, one for
`bash`, and other one for `tr`. When my script will uppercase 100 or
more words, that delay is unaffordable.
# toupper VAR
function toupper() {
local v=${!1}
v=${v//a/A}
v=${v//b/B}
v=${v//c/C}
v=${v//d/D}
v=${v//e/E}
v=${v//f/F}
v=${v//g/G}
v=${v//h/H}
v=${v//i/I}
v=${v//j/J}
v=${v//k/K}
v=${v//l/L}
v=${v//m/M}
v=${v//n/N}
v=${v//o/O}
v=${v//p/P}
v=${v//q/Q}
v=${v//r/R}
v=${v//s/S}
v=${v//t/T}
v=${v//u/U}
v=${v//v/V}
v=${v//w/W}
v=${v//x/X}
v=${v//y/Y}
v=${v//z/Z}
eval $1=\$v\
}
bash-3.2$ time -p for ((i=1; i100; i++)); do var=$(echo $i | tr [a-z]
[A-Z]); done
real 13.57
user 8.40
sys 6.90
bash-3.2$ time -p for ((i=1; i100; i++)); do var=$i; toupper var; done
real 0.12
user 0.12
sys 0.00
If I try it on linux, though the first always slower, but it's a lot
faster then in cygwin.
This may be not a good example, what I mean is, I must consider the
start up cost in cygwin, I write scripts in bash, and using binutils
etc. to get the programs look more elegant and more precise, and more
portable, but If I consider too much start up cost, the result code must
be very dirty.
Any ideas?
Lenik
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Bash doesn't launch the applications directly.
Eric Blake e...@byu.net 写入消息 news:496f34bb.6080...@byu.net... -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Lenik on 1/14/2009 5:59 PM: Hi, all I noticed that when bash launches a program, for example win32 notepad.exe or cygwin sleep, it in fact launches another bash which launches the final program, Any idea? Yes. It's called forking (a concept that Windows does not have natively, but which cygwin does a LOT of work to emulate). The way Unix apps (including bash) start another program is to first fork themselves, then in that fork, exec the target program. The fork accounts for the second bash process. Depending on the nature of the called process, you might also see those additional processes stick around. If the child is a cygwin process (like sleep), exec() is decently emulated, where the forked bash goes away and you are left with only one running sleep process. But if it is a windows How fast does the emulation implemented? process (like notepad), cygwin has to insert a shim process in between to handle signal handling in order to abort notepad if you type ctrl-c in bash, as well as collect the correct exit status. Is there any option to disable the shim process? I have tried to launch notepad in background: # calc In such situation, we won't ever press ctrl-c or ctrl-z, (maybe until fg %1), but there still got 2 bash processes. If I just want to send the launch signal to win32, and don't care what if user press ctrl-c in the bash. I tried `cygstart `which notepad`', this did launch another bash, too (while it launches cygstart.exe and which.exe additionally). Though the cygstart and shim are then immediately terminated, but it cost the launching time. Ultimately, bash could be made faster by using posix_spawn() instead of fork(), for much of what it does. However, that would require 1) an upstream patch to bash to use posix_spawn(), including a fallback implementation of posix_spawn on platforms that don't yet implement it (such an implementation is possible, since gnulib already provides one, but the upstream maintainer is hard to convince, and even if the patch existed, it has already missed the bash 4.0 cutoff), and 2) an implementation of posix_spawn() in cygwin that directly spawns processes using native Windows concepts (the bash fallback implementation of posix_spawn() would still end up using fork() under the hood, giving no speedups until we have a native version). http://cygwin.com/acronyms/#PTC Is it possible to make cygstart as a bash built-in? And thus will get another benefit that after cygstart.exe terminated, the parent-children relationship between the bash and notepad can be maintained. Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Bash doesn't launch the applications directly.
Hi, all I noticed that when bash launches a program, for example win32 notepad.exe or cygwin sleep, it in fact launches another bash which launches the final program, # sleep 10 - running process: bash (start here) bash sleep 10 This slows down the launching procedure. Any idea? Lenik -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
