Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
Hello, I've modified my patch, to change the restart process. It does not use anymore the winProcEstablishConnection wrapper to restart the clipboard but directly the winInitClipboard function. This allows to restart the clipboard more quickly and if the clipboard thread cannot connects to the server (there is a loop on connection with a delai between retries), it will die. One question : I have written my patch for the git version of the X server and the patch is not working as it on the 1.8.0-1 version. Which version would you like, perhaps the two ? Michel Hummel 2010/9/20 Michel Hummel hummel.mic...@gmail.com: 2010/9/20 Jon TURNEY jon.tur...@dronecode.org.uk: On 18/09/2010 19:44, michel hummel wrote: I have checked the code of the clipboard thread and the race condition you talk about should not be a problem. Before to start a new clipboard thread, the code waits for the end of the first thread (pthread_join) then fixe the variable g_fClipboardLaunched = FALSE; g_fClipboardStarted = FALSE; So the new thread will never be launched before the old one has terminated. I have a proposition of modification to make the clipboard thread more robust. 1/ Adding a cleanup function which will be automaticaly called at the end of the thread. I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() 2/ You said that having a long-lived thread will be a good solution to simplify the code. I have an other proposition which needs less modification and can simplify the code : By using also here the macro pthread_cleanup_push() we can automaticaly restart the thread on every unexpected exit. We just have to delete this restart when the exit is expected (ie. End of the function) With this solution we don't have to take care about the thread being killed by anyone, it will be restarted. You will need to have some kind of back-off mechanism (i.e. a delay before retrying to connect) so that that this doesn't constantly try to connect if the server gets into a state where it can't accept the connection or the connection is constantly getting closed. Like I’ve implemented it : - The clipboard thread uses the winProcEstablishConnection wrapper to restart and so it’s waiting for a new client connection before trying to reconnect himself. - An other point, the restart mechanism will only be activated if the clipboard thread has successfully been connected, otherwise the clipboard thread will dies and not restarts (this will prevent an infinite loop on connection error) Those two mechanisms and the loop on XOpenDisplay with the sleep (WIN_CONNECT_DELAY) between each retries should do the job isn't it ? But if you think a connection delay is also needed in the restart process can add one without problem 3/ An other thing I saw is that when the Xwindow part of the clipboard is killed by an other application, the thread will still be alive but the clipboard doesn't work anymore. A solution can be : when an winClipboardErrorHandler() is catched, check for this Xwindow window and whenever this window doesn't exist anymore, create a new one. Would it not be simpler to restart the clipboard thread in this situation as well, rather than having code to recrate the window? You are absolutely right, I just have to replace the window creation with a pthread_exit(NULL); What do you think about my suggestions ? I tested them and they seem to work as expected. For example, I skipped the wrapper of XQueryTree (actualy needed for xdmcp) and the clipboard is now working with xdmcp/gdm, etc. If you don't like something in my propositions, please tell me what and I will try to adapt it. If you are interested in a patch doing this, I will be happy to give it after a quick review and a clean That would be great, thank you. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin crash after the launch of startkde on a remote Red Hat 5 machine
On 22/09/2010 10:03, Michel Hummel wrote: Hello, I've modified my patch, to change the restart process. It does not use anymore the winProcEstablishConnection wrapper to restart the clipboard but directly the winInitClipboard function. This allows to restart the clipboard more quickly and if the clipboard thread cannot connects to the server (there is a loop on connection with a delai between retries), it will die. One question : I have written my patch for the git version of the X server and the patch is not working as it on the 1.8.0-1 version. Which version would you like, perhaps the two ? A patch against current git master is fine, although I don't think there have been significant changes in this area recently, so why it doesn't work for 1.8.0-1 as well is mysterious. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
业务
各位老板、财务：您好！ 本公司可以代开全国各地的票据 一:增值税:1:17%专用增值2:普通增值3:海关增值 二:国税:1:商品销售2:货物统一销售3:工业统一销售。 三:地税:1:建筑业2:广告业3:机动车销售4:税务代开 5:运输6:加工修理等专用发票。 其它服务:租赁费、会议费、住宿费、咨询费、服务费、定额餐饮等 代理全国各大城市税票： 广东.上海.浙江.江苏.北京.辽宁.福州.厦门.长沙.等. 郑重承诺 以上票据均为各单位在税务局所申领，可验证后付款。 联 系 人:何小晴 热线电话:15889545405 业务 Q Q：1322668584 办公邮箱:www221...@163.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin/X bug? suspend-resume issues
I saw the stuff about the SIGSEGV, that's quite interesting. My X server hasn't segfaulted yet, but considering the usability, it might as well have. As an update, I noticed today that my desktop has done it too (also Win 7 x64, same setup), and the corresponding XWin log is attached - seems the bug isn't caused by that odd bpp: 0 stuff after all... Cheers, Henry Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Build Date: 2010-08-06 Contact: omitted XWin was started with the following command line: X :0 -multiwindow ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1440 h 900 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [145553.690] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 [145553.690] (II) xorg.conf is not supported [145553.690] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [145553.690] LoadPreferences: /home/Henry/.XWinrc not found [145553.690] LoadPreferences: Loading /etc/X11/system.XWinrc [145553.690] LoadPreferences: Done parsing the configuration file... [145553.690] winGetDisplay: DISPLAY=:0.0 [145553.690] winDetectSupportedEngines - Windows NT/2000/XP [145553.706] winDetectSupportedEngines - DirectDraw installed [145553.706] winDetectSupportedEngines - Allowing PrimaryDD [145553.706] winDetectSupportedEngines - DirectDraw4 installed [145553.706] winDetectSupportedEngines - Returning, supported engines 001f [145553.706] winSetEngine - Multi Window or Rootless = ShadowGDI [145553.706] winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel [145553.737] winAllocateFBShadowGDI - Creating DIB with width: 1440 height: 900 depth: 32 [145553.737] winFinishScreenInitFB - Masks: 00ff ff00 00ff [145553.737] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [145553.737] null screen fn ReparentWindow [145553.737] null screen fn RestackWindow [145553.737] InitQueue - Calling pthread_mutex_init [145553.737] InitQueue - pthread_mutex_init returned [145553.737] InitQueue - Calling pthread_cond_init [145553.737] InitQueue - pthread_cond_init returned [145553.737] winInitMultiWindowWM - Hello [145553.737] winInitMultiWindowWM - Calling pthread_mutex_lock () [145553.737] winMultiWindowXMsgProc - Hello [145553.737] Screen 0 added at virtual desktop coordinate (0,0). [145553.737] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [145553.753] MIT-SHM extension disabled due to lack of kernel support [145553.768] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [145553.831] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [145553.831] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [145553.878] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [145553.878] [dix] Could not init font path element /usr/share/fonts/Type1/, removing from list! [145554.876] winPointerWarpCursor - Discarding first warp: 720 450 [145554.876] (--) 16 mouse buttons found [145554.876] (--) Setting autorepeat to delay=500, rate=31 [145554.876] (--) Windows keyboard layout: 0409 (0409) US, type 4 [145554.876] (--) Found matching XKB configuration English (USA) [145554.876] (--) Model = pc105 Layout = us Variant = none Options = none [145554.876] Rules = base Model = pc105 Layout = us Variant = none Options = none [145554.876] winInitMultiWindowWM - pthread_mutex_lock () returned. [145554.892] winInitMultiWindowWM - pthread_mutex_unlock () returned. [145554.892] winGetDisplay: DISPLAY=:0.0 [145554.892] winInitMultiWindowWM - DISPLAY=:0.0 [145554.892] winMultiWindowXMsgProc - pthread_mutex_lock () returned. [145554.892] winMultiWindowXMsgProc - pthread_mutex_unlock () returned. [145554.892] winProcEstablishConnection - Hello [145554.892] winInitClipboard () [145554.892] winProcEstablishConnection - winInitClipboard returned. [145554.892] winClipboardProc - Hello [145554.892] DetectUnicodeSupport - Windows NT/2000/XP [145554.892] winGetDisplay: DISPLAY=:0.0 [145554.892] winGetDisplay: DISPLAY=:0.0 [145554.892] winMultiWindowXMsgProc - DISPLAY=:0.0 [145554.892] winClipboardProc - DISPLAY=:0.0 [145554.907] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [145554.907] winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. [145554.923] winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. [145556.857] OS has icon alpha channel support: yes [149536.583] winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 [149536.583] winWindowProc - WM_DISPLAYCHANGE - new width: 1360 new height: 768 [149536.583] winAllocateFBShadowGDI - Creating DIB with width: 1360 height: 768 depth: 32 [149538.034] winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 [149538.034] winWindowProc -
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On Sep 22 07:45, Yoni Londner wrote:
Hi,
There's also the problem of handling NFS shares. However, I just had an
idea how to speed up symlink_info::check without neglecting NFS shares.
This will take some time, though since it turns a lot of code upside
down. Stay tuned.
This sounds great! Cygwin filesystem performance is a very important
issue, and any improvement is more than welcome!
Unfortunately it didn't work out the way I anticipated. See below.
I don't understand how you think this should work. The filter expression
given to NtQueryDirectoryFile is either a constant string and has
to match
the filename exactly, or it contains wildcards. This is documented
behaviour:
http://msdn.microsoft.com/en-us/library/ff567047%28VS.85%29.aspx
So, foo works, foo* works, but a list like foo foo.exe foo.lnk
does not.
There are two options for stat() and other places the need file info
(such as check_symlink):
1) CreateFile(the_dir), then NtQueryDirectoryFile(foo*) and
retrieve all the info (including the hardlink), filter out the
How are you going to do that? Pray tell me the NtQueryDirectoryFile
info class which returns the number of hardlinks to a file. To the
best of my knowledge there is none.
Then there are the FileIdBothDirectoryInformation and
FileIdFullDirectoryInformation info classes, which were a nice idea, but
they have a downside, as you can see in fhandler_disk_file::readdir.
First, it doesn't exist on pre-XP systems. Second, there are a couple
of filesystems out in the wild which don't support the call. Third,
worse, there are filesystems which implement the call wrongly. Forth,
there's MSFT NFS which does not return dangling symlinks in calls to
NtQueryDirectoryFile, unless the info class is FileNamesInformation.
Last but not least, hardlink count and permissions are still missing.
So, using FileIdBothDirectoryInformation is far from being a swiss army
knife.
results in user-mode (foo, foo.exe, foo.lnk), and then call
CloseHandle().
2) CreateFile(the_dir), NtQueryDirectoryFile(foo),
NtQueryDirectoryFile(foo.exe), NtQueryDirectoryFile(foo.lnk),
CloseHandle(). The calls to NtQueryDirectoryFile() should be with
RestartScan=1, so that the the_dir handle can be reused. Also
ReturnSingleEntry=1 can be set to improve performance.
That was the method I tried. It doesn't work. This is documented
in the aforementioned link to the NtQueryDirectoryFile man page:
The FileName is used as a search expression and is captured
on the very first call to ZwQueryDirectoryFile for a given handle.
^
Subsequent calls to ZwQueryDirectoryFile will use the search expression
set in the first call.
The FileName parameter passed to subsequent calls will be ignored.
^
You can't use RestartScan in conjunction with another filter expression
to restart the scan with another filter expression. Either you are
lucky and the filename exists without .exe or .lnk suffix so that it's
returned by the first call, or what you get is the status code
STATUS_NO_MORE_FILES in any subsequent call with changed filter
expression. So, if you use this method you would have to close and
reopen the directory handle for every iteration on the suffix. Which in
turn slows down the method enormously. The end result was slower than
the current implementation.
When I have time I will try the #1 solution as well, but it requires
some more changes in symlink_info and needs more time, so it's kind of
on the backburner for now. I can see how general file access can
profit from a faster symlink_info::check which does not open every
file, but that won't affect stat() in the first place, rather other
calls which don't need stat-like info.
This is instead what is done today in cygwin:
3) CreateFile(foo), NtQueryFileInformation(), CloseHandle() (and
repeat this for foo.exe and foo.lnk)
Well, it's more like
Repeat CreateFile(foo${SUFFIX}) until file is found, then call
NtQueryFileInformation(), CloseHandle() exactly once.
I did some performance tests comparing #1 #2 and #3.
I found out that #1 and #2 are both around 10x to 100x (!!!) times
faster than #3.
I guess so, but you can also get such figures by just using `ls',
not `ls -l'. But afaics you're comparing apples with oranges
since you deliberately drop information. Where is the hardlink
count? Where are the POSIX permissions?
I checked out why, and found out that #1 and #2 don't modify the
access time of the file, whereas #3 does. This already immediately
I just checked this and I can't see that it does. If it would do
so, shouldn't the access time be different every time I call stat?
$ stat foo | grep 'Access: [0-9]'
Access: 2010-09-09 16:27:20.769055700 +0200
$ stat foo | grep 'Access: [0-9]'
Access: 2010-09-09 16:27:20.769055700 +0200
$ stat foo | grep 'Access:
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On Sep 22 11:32, Corinna Vinschen wrote: On Sep 22 07:45, Yoni Londner wrote: I checked out why, and found out that #1 and #2 don't modify the access time of the file, whereas #3 does. This already immediately I just checked this and I can't see that it does. If it would do so, shouldn't the access time be different every time I call stat? $ stat foo | grep 'Access: [0-9]' Access: 2010-09-09 16:27:20.769055700 +0200 $ stat foo | grep 'Access: [0-9]' Access: 2010-09-09 16:27:20.769055700 +0200 $ stat foo | grep 'Access: [0-9]' Access: 2010-09-09 16:27:20.769055700 +0200 I tried it on Windows XP SP3 and Windows 7. Did you test this on a noacl mount, or on a filesystem which doesn't keep permissions, like FAT? If so, then I know what happens. This is the executable test in fhandler_base::fstat_helper. It reads the first two bytes from the file to identify executables by their magic number. This is especially done to identify shell scripts by their #! magic, so that they are marked as executable in st_mode. You can switch this off by specifing the exec or notexec mount options. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance
On Wed, Sep 22, 2010 at 07:50:14AM +0200, Yoni Londner wrote: Hi, I'm not exactly concerned about Linux being way faster accessing an NTFS drive. After all it's the OS itself and comes with it's own NTFS driver which obviously is streamlined for typical POSIX operations. I did not test compare to using the Linux NTFS, rather I compared with Linux on VMWARE using the same Windows NTFS.SYS (via the same kernel32.dll APIs): Cygwin: C:/cygwin/bin/ls.exe /bin - cygwin1.dll - kernel32.dll - NTOS kernel - NTFS.SYS driver - HD linux: /bin/ls /mnt/hgfs/C/cygwin/bin - glibc - linux kernel - VMWARE hgfs driver - vmware_player.exe (on Win32) - kernel32.dll - NTOS kernel - NTFS.SYS driver - HD As you can see the VMWARE path is much longer than Cygwin, and it passes the same APIs and NTFS.SYS driver, and yet it executes much faster. This helps us understand that there is a lot that still can be done in Cygwin's filesystem performance. What is /mnt/hgfs/C in this case? How is it mounted? cgf
Re: Odd apparent cursor movement in mintty (+emacs)
On 22.09.2010 09:25, Gary wrote: In some file^H^H^H^Hbuffer in emacs(-nox), with mintty maximised, cursor movement appears incorrect - moving the cursor forward[1] (emacs' forward-char via C-f / cursor right key) incorrectly positions the visible cursor 'n' characters forward. The insertion position is correct, however - it only moves one character forward. emacsclient 23.2, GNU Emacs 23.2.1, if it makes any difference. [1] backward, too, but up and down seem unaffected Do you have any non-ASCII characters on the affected lines? If so, it sounds like a mismatch of character encoding between mintty and emacs' assumption. What's your locale environment variables? -- 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
[xkeyboard-config] can't compile source tarball, missing dependencies
Hi, When I try to compile xkeyboard-config (cygport xkeyboard-config*.cygport compile), I get 2 errors : macros AC_PROC_INTLTOOL and AM_GLIB_GNU_GETTEXT are undefined. Solution : install packages 'intltool' and 'libglib2.0-devel' More details : configure.in uses AC_PROC_INTLTOOL and AM_GLIB_GNU_GETTEXT. AC_PROC_INTLTOOL is defined in /usr/share/aclocal/intltool.m4 from 'intltool' package AM_GLIB_GNU_GETTEXT is defined in /usr/share/aclocal/glib-gettext.m4 from 'libglib2.0-devel' package Suggestion : add 'intltool' and 'libglib2.0-devel' in section Build requirements: of README Build requirements: autoconf2.5-2.65-1 automake1.11-1.11.1-1 cygport-0.9.88-1 gawk-3.1.7-1 gettext-devel-0.17-11 make-3.81-2 sed-4.2.1-1 intltool-0.41.1-1 libglib2.0-devel-2.24.1-1 I hope this is the right mailing list for this kind of request. Regards -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to enable the very convenient copy/paste editing method in Cgywin?
On Wed, Sep 22, 2010 at 7:10 AM, Andy Koppe wrote: On 22 September 2010 01:54, SJ Wright wrote: New on me. I'll start using mintty asap. Must be better than Terminator. I did a cutesy thing with an echo-ed ellipse to mark time while a script iterated over some lines in a list: rxvt wrapped each unbroken string to 80 characters while Terminator ran them off the right-hand side of the window before doing so. You set it as many times as you want to 80x24 or 80x40 (or whatever) and it still does what it pleases. That is precisely the point of Terminator. It is an infinitely wide terminal. I used it for quite a while to avoid gcc command lines from being wrapped. But now I have a widescreen monitor and 207 columns in a fullscreen mintty window :) ... tabbed terminal emulator. How's mintty on that btw? It'll start your Cygwin shell unless told otherwise on the command line. Lines wrap at the screen edge. There are no tabs (but you can switch among mintty windows with Ctrl+Tab). Ouch. I just tried Ctrl+Tab and the mintty window simply disappeared, leaving the shell process (bash or ssh) behind without a window (visible or otherwise). :( -- Life is complex, with real and imaginary parts. Ok, it boots. Which means it must be bug-free and perfect. -- Linus Torvalds People disagree with me. I just ignore them. -- Linus Torvalds -- 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: Odd apparent cursor movement in mintty (+emacs)
On 9/22/2010 3:25 AM, Gary wrote: In some file^H^H^H^Hbuffer in emacs(-nox), with mintty maximised, cursor movement appears incorrect - moving the cursor forward[1] (emacs' forward-char via C-f / cursor right key) incorrectly positions the visible cursor 'n' characters forward. The insertion position is correct, however - it only moves one character forward. Can you give a precise recipe (as simple as possible) for reproducing this problem? I just started emacs in a maximized mintty window and had no problem with cursor movement. 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: Odd apparent cursor movement in mintty (+emacs)
On 22 September 2010 08:58, Gary wrote: Thomas Wolff wrote: On 22.09.2010 09:25, Gary wrote: In some file^H^H^H^Hbuffer in emacs(-nox), with mintty maximised, cursor movement appears incorrect - moving the cursor forward[1] (emacs' forward-char via C-f / cursor right key) incorrectly positions the visible cursor 'n' characters forward. The insertion position is correct, however - it only moves one character forward. emacsclient 23.2, GNU Emacs 23.2.1, if it makes any difference. [1] backward, too, but up and down seem unaffected Do you have any non-ASCII characters on the affected lines? If so, it sounds like a mismatch of character encoding between mintty and emacs' assumption. What's your locale environment variables? In that case wouldn't it also happen when mintty was not maximised? Quoting Simon Tatham yet again: In bug reports, try to make very clear what are actual facts and what are speculations. Leave out speculations if you want to, but don't leave out facts. So please do answer Thomas' questions. If possible, attach the file that shows the problem. 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: how to enable the very convenient copy/paste editing method in Cgywin?
On 22 September 2010 11:11, Csaba Raduly wrote: I just tried Ctrl+Tab and the mintty window simply disappeared, leaving the shell process (bash or ssh) behind without a window (visible or otherwise). :( Uh oh. Works fine for me of course, so here's a load of questions: - What versions of mintty, Cygwin, and Windows were you using? - Are any 3rd party window/taskbar/tray management utilities involved? AutoHotkey? - Did you confirm that the mintty process had died, or could the window just have been hidden? - How many mintty windows were open at the time? Were any of them minimised? - Can you reproduce the problem? If you want a workaround, you can disable the Ctrl[+Shift]+Tab shortcuts on the Keys page of the options, in which case they'll send keycodes to the application instead. (Btw, those can be mapped to switch session in GNU screen.) 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: how to enable the very convenient copy/paste editing method in Cgywin?
Andy Koppe wrote: On 22 September 2010 01:54, SJ Wright wrote: New on me. I'll start using mintty asap. Must be better than Terminator. I did a cutesy thing with an echo-ed ellipse to mark time while a script iterated over some lines in a list: rxvt wrapped each unbroken string to 80 characters while Terminator ran them off the right-hand side of the window before doing so. You set it as many times as you want to 80x24 or 80x40 (or whatever) and it still does what it pleases. Except that Console2 unerringly preferred my old MinGW .bashrc file to my Cygwin one, I wouldn't recommend it to anyone looking for a tabbed terminal emulator. How's mintty on that btw? It'll start your Cygwin shell unless told otherwise on the command line. Lines wrap at the screen edge. There are no tabs (but you can switch among mintty windows with Ctrl+Tab). 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 Sorry, I should have been more specific. I meant to ask, are there any plans to make MinTTY multi-tab capable, or is it there already? I presumed if it was the going thing as a substitute to RXVT, it would perform similarly when tasked to run scripts and such. Steve W. -- 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 cannot I see serial devices using ls
I have decided to port some code to cygwin from linux. It uses serial ports and under linux I can ls -l /dev/tty* If I do this under cygwin I get nothing. If I do ls -l /dev I only get a few device. However if I do ls -l /dev/ttyS0 or ls -l /dev/com1 then I get what I would expect. I have searched cygwin FAQ etc and this forum but didn't find anything. Anybody any ideas what I have to do? -- View this message in context: http://old.nabble.com/why-cannot-I-see-serial-devices-using-ls-tp29779076p29779076.html Sent from the Cygwin list mailing list archive at Nabble.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
I: R: why cannot I see serial devices using ls
2nd trial --- Mer 22/9/10, JonMcG ha scritto: I have decided to port some code to cygwin from linux. It uses serial ports and under linux I can ls -l /dev/tty* If I do this under cygwin I get nothing. If I do ls -l /dev I only get a few device. However if I do ls -l /dev/ttyS0 or ls -l /dev/com1 then I get what I would expect. I have searched cygwin FAQ etc and this forum but didn't find anything. Anybody any ideas what I have to do? -- see POSIX name on http://www.cygwin.com/cygwin-ug-net/using-specialnames.html and the related script http://cygwin.com/ml/cygwin/2004-03/txt00028.txt Regards Marco -- 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
/dev/ttys* under cygwin problem
Hi all, as mentinoned in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html i have set CGWIN to tty . But there are no tty devices under /dev. $ echo $CYGWIN tty So what is wrong ?? Have a nice time Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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
R: /dev/ttys* under cygwin problem
--- Mer 22/9/10, DEWI - N. Zacharias ha scritto: Hi all, as mentinoned in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html i have set CGWIN to tty . But there are no tty devices under /dev. $ echo $CYGWIN tty So what is wrong ?? Have a nice time Norbert the TTY is not really needed anymore, see hand of the paragraph It should not be set when using other terminals (i.e., mintty or xterm). About the other question, the /dev directory is a bit unusal, as it is populated by element that are usually not visible with $ls /dev see POSIX name on http://www.cygwin.com/cygwin-ug-net/using-specialnames.htm try $ ls -l /dev/tty crw--w--w- 1 xxx 5, 0 2010-09-22 15:21 /dev/tty $ ls -l /dev/tty1 and so on. Marco -- 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: OpenGL / GLUT / FreeGlut and the mouse wheel in PyMol.
Jan Gebauer mail at jan-gebauer dot de wrote: Hi, Hi Jan, I'm new to this mailing list and hope my question is not a total obvious one, but at the end of the day I'm more a scientist than a programmer. So I hope I got the facts right. I'm trying to build PyMol, an open-core molecular visualisation program with cygwin (www.pymol.org). This software uses OpenGL for displaying three-dimensional structures of proteins on the screen and allows manipulating these structure in various ways in 3D. It also allows true three-dimensional display with the (Nvidia) shutter glasses. It took my a while to get all the dependencies right, but I was finally able to build it successfully and it works in nearly all aspects. However, the program does not recognise any input in the graphic/display window from the mouse wheel, although the TKinter/Tcl based menu window does accept scroll events. Together with a colleague, we figured out that the win32 port of GLUT might be the problem, as it seems not to handle mouse wheel events (source:http://www.realmtech.net/opengl/glut.php) The win32 port of GLUT predates the mouse wheel and has stalled. No hope of an update upstream. My colleague was able to build PyMol with the X11 headers and Libs and then the mouse wheel worked, but the speed was (as expected) not acceptable. What are you thinking, is the win32 version of GLUT really the problem? I did found FreeGlut and as it should be a modern clone of GLUTÂ, I tried to compile it for Cygwin. I got an cygglut-0.dll and some header files, but they never compiled well with PyMol (which uses a rather complicated python script). My colleague found this message from Andrà Bleau http://www.cygwin.com/ml/cygwin/2009-04/msg00264.html, where Mr. Bleau stated he hopes to publish GLUT32 replacement based on FreeGlut around 2010. I tried porting the Win32 version of FreeGLUT to Cygwin, but ran into problems, mainly with the menus. Replacing GLUT by FreeGlut in my package would not be a wise thing to do at this point. I just wonder if this new package will be available any-time soon or if anyone else has a good idea how to proceed with this problem? I am working, very slowly, on improving FreeGLUT. Don't expect anything from me before 2011. The X11 version of FreeGlut might benefit from hardware accelerated OpenGL at some point, but that is something that I will let the X11 maintainers talk about. You can find some previous discussion at http://cygwin.com/ml/cygwin-xfree . For the immediate time, your only option seems to stick with Win32 GLUT and do without mousewheel support. With kind regards, Jan Gebauer PS: Thanks to all the cygwin contributors, it's the first time I used it and it works rather great! -- Dr. Jan Gebauer Phone: +44 20 7594 7915 | Fax: +44 20 7589 0191 Research group: Dr. E. Hohenester Division of Cell Molecular Biology Imperial College London Biophysics Section, Blackett Laboratory London SW7 2AZ Regards, André Bleau, Cygwin's OpenGL package maintainer. Please send any comment or question about the OpenGL package to cygwin at cygwin dot com, not to me. -- 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: Instead of a gripe, a memory-jog.
Andy Koppe wrote: On 22 September 2010 00:29, SJ Wright wrote: Yes. I noticed where I had the territory mis-cased the next time I ran wget. In the line that identified the file and URL for each download, double-quotes and other punctuation became garbage characters, where they hadn't been when I either had *no* LANG variable set or a correctly-written one. So now it's fixed. Thanks again. If LANG (and also LC_ALL and LC_CTYPE) aren't set, Cygwin defaults to UTF-8. It's better to have it set though, because some programs such as emacs default to plain ol' ASCII if the locale isn't set. That's why LANG is set to C.UTF-8 during login shell startup (by /etc/defaults/etc/profile.d/lang.sh). In other words, you shouldn't have to worry about it. Spoke too soon on the wget matter. Since setting a LANG variable in the first place (and evidently the right place, or else this wouldn't be a matter), I've been seeing garbage text -- I prefer to call it drone text -- in place of quotation marks during normal (non-verbose and not set to quiet) downloads. Here's a sample: Saving to: “gae77-7748-244-958stck.jpg†That looks like wget is using UTF-8 yet your terminal is using ISO-8859-1. The Cygwin console as well as all the terminals shipped with Cygwin (except for rxvt) use UTF-8 by default. With other terminals, you might have to select it somewhere in their options. 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 Well, my LANG is C.UTF-8, and the garbage in wget turned back into single- and double-quotes as soon as I added the command to .wgetrc I mentioned. So it turns out, at least in my case, that local_encoding=UTF-8 does something positive with how commands/running task steps are displayed. This was, coincidentally, in rxvt that all of this was happening. I've yet to try it in MinTTY. I don't expect much of a difference: these are 'peripheral' variables set and if a UTF-8 works from two directions in a term that isn't built to like it, then 'how much better should it be in one that does?' is not even a question worth asking, imo. Steve W -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to enable the very convenient copy/paste editing method in Cgywin?
Greetings, SJ Wright! Sorry, I should have been more specific. I meant to ask, are there any plans to make MinTTY multi-tab capable, or is it there already? I presumed if it was the going thing as a substitute to RXVT, it would perform similarly when tasked to run scripts and such. Don't know about mintty, but there's something for PuTTY http://mutty.org/ Check it? -- WBR, Andrey Repin (anrdae...@freemail.ru) 22.09.2010, 19:09 Sorry for my terrible english... -- 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 cannot I see serial devices using ls
On 9/22/2010 8:41 AM, JonMcG wrote: I have decided to port some code to cygwin from linux. It uses serial ports and under linux I can ls -l /dev/tty* If I do this under cygwin I get nothing. If I do ls -l /dev I only get a few device. However if I do ls -l /dev/ttyS0 or ls -l /dev/com1 then I get what I would expect. I have searched cygwin FAQ etc and this forum but didn't find anything. Anybody any ideas what I have to do? Read the User's Guide: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices -- 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
AW: [bulk] - R: /dev/ttys* under cygwin problem
Hi, Von: Marco Atzeri [] Gesendet: Mittwoch, 22. September 2010 15:26 An Betreff: [bulk] - R: /dev/ttys* under cygwin problem --- Mer 22/9/10, DEWI - N. Zacharias ha scritto: Hi all, as mentinoned in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html i have set CGWIN to tty . But there are no tty devices under /dev. $ echo $CYGWIN tty So what is wrong ?? Have a nice time Norbert the TTY is not really needed anymore, see hand of the paragraph It should not be set when using other terminals (i.e., mintty or xterm). About the other question, the /dev directory is a bit unusal, as it is populated by element that are usually not visible with $ls /dev see POSIX name on http://www.cygwin.com/cygwin-ug-net/using-specialnames.htm This link do not work for me. try $ ls -l /dev/tty crw--w--w- 1 xxx 5, 0 2010-09-22 15:21 /dev/tty $ ls -l /dev/tty1 and so on. Ok : ls -al /dev/ttyS4 crw-rw-rw- 1 n-zacharias Kein 117, 4 22. Sep 17:28 /dev/ttyS4 but stty -F /dev/ttyS4 ospeed 115200 stty: /dev/ttyS4: Permission denied Again, whats going wrong Thanks Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this 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: [bulk] - R: /dev/ttys* under cygwin problem
DEWI - N. Zacharias sent the following at Wednesday, September 22, 2010 11:36 AM as mentinoned in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html i have set CGWIN to tty . see POSIX name on http://www.cygwin.com/cygwin-ug-net/using-specialnames.htm This link do not work for me. The final l was left off. http://www.cygwin.com/cygwin-ug-net/using-specialnames.html To go there directly: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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
R: AW: [bulk] - R: /dev/ttys* under cygwin problem
--- Mer 22/9/10, DEWI - N. Zacharias ha scritto: but stty -F /dev/ttyS4 ospeed 115200 stty: /dev/ttyS4: Permission denied Again, whats going wrong Thanks Norbert Are you the administrator ? On my PC it works $ stty -F /dev/ttyS0 ospeed 64000 $ stty -F /dev/ttyS0 speed 115200 baud; line = 0; intr = undef; quit = undef; erase = undef; kill = undef; eof = undef; swtch = undef; susp = undef; rprnt = undef; werase = undef; lnext = undef; flush = undef; min = 0; time = 0; -cread -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke what about http://cygwin.com/problems.html ?? Regards Marco -- 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: [bulk] - R: /dev/ttys* under cygwin problem
Buchbinder, Barry (NIH/NIAID) [E] wrote: ... To go there directly: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Regarding where that page says: These devices cannot be seen with the command ls /dev/ ... I've wondered about that--why aren't those special files listed in a directory listing? (The Cygwin DLL makes those device files appear when they are referred to by full pathname; why doesn't it also make them appear in the containing directory's listing?) Daniel -- 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: [bulk] - R: /dev/ttys* under cygwin problem
On 9/22/2010 1:29 PM, Daniel Barclay wrote: Buchbinder, Barry (NIH/NIAID) [E] wrote: ... To go there directly: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Regarding where that page says: These devices cannot be seen with the command ls /dev/ ... I've wondered about that--why aren't those special files listed in a directory listing? (The Cygwin DLL makes those device files appear when they are referred to by full pathname; why doesn't it also make them appear in the containing directory's listing?) They are implemented in a virtual file system. It is not necessary that there be placeholders in the file system for them to work. But if you prefer that, you can add them. This is why the documentation has a link to the script to create the devices in the file system: http://cygwin.com/ml/cygwin/2004-03/txt00028.txt -- 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: how to enable the very convenient copy/paste editing method in Cgywin?
On 22 September 2010 13:51, Csaba Raduly wrote: On Wed, Sep 22, 2010 at 1:26 PM, Andy Koppe wrote: On 22 September 2010 11:11, Csaba Raduly wrote: I just tried Ctrl+Tab and the mintty window simply disappeared, leaving the shell process (bash or ssh) behind without a window (visible or otherwise). :( Uh oh. Works fine for me of course, so here's a load of questions: Thanks for all the additional information. Unfortunately I can't reproduce the issue on Vista yet either. Could you send me your .minttyrc to take out another variable? - What versions of mintty, Cygwin, and Windows were you using? mintty 0.8.3 Installed via setup.exe, from .zip, or built from source? CYGWIN_NT-6.0 EV0017A4D11749 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin Microsoft Windows [Version 6.0.6001] , that is, Vista SP1 - Are any 3rd party window/taskbar/tray management utilities involved? AutoHotkey? Nothing I can think of, except maybe Rainmeter. Hmm, that replaces the whole desktop, right? Could be relevant. If it's not too much trouble, could you try disabling it briefly to check whether that makes the crash go away? - Did you confirm that the mintty process had died, or could the window just have been hidden? Netcr^H^H^H^H Process explorer confirms it: the process is gone. - How many mintty windows were open at the time? Were any of them minimised? Four, initially; fewer and fewer afterwards :) :) They were all maximized one behind another. - Can you reproduce the problem? Yes, it's still happening. mintty 0.4.4 from Cygwin 1.5 is unaffected. It just flashes and puts 5I on the commandline. Yep, the window switching shortcut was only introduced in 0.7, so in 0.4 you're just getting the keycode. Bash doesn't know it and complains via the bell. Same thing happens with other unmapped keycodes. 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: Instead of a gripe, a memory-jog.
On 22 September 2010 14:29, SJ Wright wrote: Andy Koppe wrote: On 22 September 2010 00:29, SJ Wright wrote: Yes. I noticed where I had the territory mis-cased the next time I ran wget. In the line that identified the file and URL for each download, double-quotes and other punctuation became garbage characters, where they hadn't been when I either had *no* LANG variable set or a correctly-written one. So now it's fixed. Thanks again. If LANG (and also LC_ALL and LC_CTYPE) aren't set, Cygwin defaults to UTF-8. It's better to have it set though, because some programs such as emacs default to plain ol' ASCII if the locale isn't set. That's why LANG is set to C.UTF-8 during login shell startup (by /etc/defaults/etc/profile.d/lang.sh). In other words, you shouldn't have to worry about it. Spoke too soon on the wget matter. Since setting a LANG variable in the first place (and evidently the right place, or else this wouldn't be a matter), I've been seeing garbage text -- I prefer to call it drone text -- in place of quotation marks during normal (non-verbose and not set to quiet) downloads. Here's a sample: Saving to: “gae77-7748-244-958stck.jpg†That looks like wget is using UTF-8 yet your terminal is using ISO-8859-1. The Cygwin console as well as all the terminals shipped with Cygwin (except for rxvt) use UTF-8 by default. With other terminals, you might have to select it somewhere in their options. Well, my LANG is C.UTF-8, and the garbage in wget turned back into single- and double-quotes as soon as I added the command to .wgetrc I mentioned. So it turns out, at least in my case, that local_encoding=UTF-8 does something positive with how commands/running task steps are displayed. The use of fancy Unicode quotes in wget is actually controlled by the locale setting, i.e. LANG and relatives. LANG=C.UTF-8 gives you ASCII quotes, whereas LANG=en_US.UTF-8 results in Unicode quotes. As far as I can see, the local_encoding setting has no bearing on this. This was, coincidentally, in rxvt that all of this was happening. I've yet to try it in MinTTY. I don't expect much of a difference: these are 'peripheral' variables set and if a UTF-8 works from two directions in a term that isn't built to like it, then 'how much better should it be in one that does?' is not even a question worth asking, imo. Well, if you're not using anything beyond ASCII, then no, rxvt's lack of UTF-8 support doesn't matter. But don't come back crying when you do encounter more funny letters. Rxvt actually uses CP1252, which is MS's extended version of ISO-8859-1, hence appropriate locale settings for rxvt use one of those charsets, e.g. LANG=en_US.CP1252. 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: [bulk] - R: /dev/ttys* under cygwin problem
Larry Hall (Cygwin) wrote: On 9/22/2010 1:29 PM, Daniel Barclay wrote: Buchbinder, Barry (NIH/NIAID) [E] wrote: ... To go there directly: http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices Regarding where that page says: These devices cannot be seen with the command ls /dev/ ... I've wondered about that--why aren't those special files listed in a directory listing? (The Cygwin DLL makes those device files appear when they are referred to by full pathname; why doesn't it also make them appear in the containing directory's listing?) They are implemented in a virtual file system. It is not necessary that there be placeholders in the file system for them to work. But if they were emulated/simulated _consistently_, one could see which devices were available by simply listing /dev instead of having to re-find the documentation. Again, why does Cygwin's (virtual) file system _not_ include those devices (when listing /dev)? (Why doesn't it do it more like Linux's /proc, etc., which gives a consistent view and which tells you what's available without your having to look elsewhere?) Actually, is your last sentence above actually true? Looking at the device-creation script you pointed me to, I wonder: How do you (e.g., a script) determine which devices of a given type exist (e.g., sda1, sda2, sda3, ...)? (Do you have to try to open each possible device and check whether there's an error?) But if you prefer that, you can add them. This is why the documentation has a link to the script to create the devices in the file system: http://cygwin.com/ml/cygwin/2004-03/txt00028.txt How do you keep things synchronized? The script you pointed me to appears to be over six years old. I doubt that it matches the code inside Cygwin 1.7. Daniel -- 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: [bulk] - R: /dev/ttys* under cygwin problem
On 09/22/2010 03:02 PM, Daniel Barclay wrote: They are implemented in a virtual file system. It is not necessary that there be placeholders in the file system for them to work. But if they were emulated/simulated _consistently_, one could see which devices were available by simply listing /dev instead of having to re-find the documentation. http://cygwin.com/acronyms/#PTC Again, why does Cygwin's (virtual) file system _not_ include those devices (when listing /dev)? (Why doesn't it do it more like Linux's /proc, etc., which gives a consistent view and which tells you what's available without your having to look elsewhere?) Because no one has taken the time to write the code. Also, unlike Linux, where the kernel knows what devices are present, a cygwin implementation would have to make a lot of syscalls querying whether each potential device is available. One other drawback - cygwin would like things like /dev/stdin to work as a symlink to /proc/self/0, but that is a normal symlink in today's cygwin implementation, and not an entry in the virtual file system. Therefore, part of the implementation battle is figuring out how to merge an existing directory containing user-added symlinks or device names, in parallel with the virtual devices supported by the virtual FS magic compiled into cygwin. Actually, is your last sentence above actually true? Looking at the device-creation script you pointed me to, I wonder: How do you (e.g., a script) determine which devices of a given type exist (e.g., sda1, sda2, sda3, ...)? (Do you have to try to open each possible device and check whether there's an error?) The script creates every known name, whether or not it actually exists as a device at the current moment, which is in itself a bit misleading. But it has to, because of devices which can be added and removed on the fly, whereas the script creating the placeholder files is only run once. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: how to enable the very convenient copy/paste editing method in Cgywin?
Le 22/09/2010 06:56, Andy Koppe a écrit : PS : mintty do paste à la Xwindows (middle button), while putty may do it as you wich (middle or right button), both may copy on select w/ left button. That's optional in mintty too: Options-Mouse-Right Click Action-Paste/Extend/Show Menu not seen !!! %^# so, ok, copy/paste may be defined the way you want in mintty or puttycyg... Regards, Cyrille Lefevre -- mailto:cyrille.lefevre-li...@laposte.net -- 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
Command Line Editing does not work, please help
Hello folks, I am trying to use line editing commands: C-b Move back one character. C-f Move forward one character and they are not working. I also want to start using history features - search or list history file for recent execution lines. I looked through Bash Reference http://www.gnu.org/software/bash/manual/bashref.html#Command-Line-Editing and these commands are described. CAn you help please. -- 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: Command Line Editing does not work, please help
On 9/22/2010 10:38 PM, gene golub wrote: Hello folks, I am trying to use line editing commands: C-b Move back one character. C-f Move forward one character and they are not working. I also want to start using history features - search or list history file for recent execution lines. I looked through Bash Reference http://www.gnu.org/software/bash/manual/bashref.html#Command-Line-Editing and these commands are described. CAn you help please. http://cygwin.com/acronyms/#WJFFM Maybe you should start at the beginning, reading the problem reporting guidelines: Problem reports: http://cygwin.com/problems.html From that, perhaps someone here can pinpoint where your problem is. -- 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
