Re: [RFU] ppl-0.11.2-1
On Tue, 2011-08-02 at 15:36 +1000, David.Billinghurst wrote: ppl-0.11.2-1 is available for upload. This is a new upstream release built against gmp-4.3.2-1 It is backward compatible with ppl-0.10.2-1. That's not possible. Comparing the import libraries shows ABIs were removed/renamed between 0.10.2 and 0.11.2. Please rebuild ppl with the upstream ABI numbers; libppl will need to be named libppl9 now, with dependencies adjusted accordingly. Yaakov
Re: [RFU] cloog-ppl-0.15.11-1
On Tue, 2011-08-02 at 15:45 +1000, David.Billinghurst wrote: cloog-ppl-0.15.11-1 is available for upload. It is a new upstream release built against gmp-4.3.2-1 and ppl-0.11.2-1. It is backward compatible with the previous release Per my last message, please hold off uploading this. Yaakov
Re: [RFU] ppl-0.11.2-1
On 2/08/2011 5:10 PM, Yaakov (Cygwin/X) wrote: On Tue, 2011-08-02 at 15:36 +1000, David.Billinghurst wrote: ppl-0.11.2-1 is available for upload. This is a new upstream release built against gmp-4.3.2-1 It is backward compatible with ppl-0.10.2-1. That's not possible. Comparing the import libraries shows ABIs were removed/renamed between 0.10.2 and 0.11.2. Please rebuild ppl with the upstream ABI numbers; libppl will need to be named libppl9 now, with dependencies adjusted accordingly. Yaakov OK. No problem. It was compatible enough to run cloog and gcc-4.3, but I didn't check the import libraries.
Re: [RFU] ppl-0.11.2-1
On Tue, 2011-08-02 at 18:14 +1000, David Billinghurst wrote: On 2/08/2011 5:10 PM, Yaakov (Cygwin/X) wrote: On Tue, 2011-08-02 at 15:36 +1000, David.Billinghurst wrote: ppl-0.11.2-1 is available for upload. This is a new upstream release built against gmp-4.3.2-1 It is backward compatible with ppl-0.10.2-1. That's not possible. Comparing the import libraries shows ABIs were removed/renamed between 0.10.2 and 0.11.2. Please rebuild ppl with the upstream ABI numbers; libppl will need to be named libppl9 now, with dependencies adjusted accordingly. Yaakov OK. No problem. It was compatible enough to run cloog and gcc-4.3, but I didn't check the import libraries. Sometimes upstreams don't change ABI versions when they should, but when they are changed there is usually a good reason. Note that mpfr will definitely change ABI versions (1-4), and you might as well take this opportunity to revert to mpc's upstream version as well. Thanks, Yaakov
Re: 256x256 px icons
On 1 August 2011 21:05, Andy Koppe wrote: On 1 August 2011 09:07, Corinna Vinschen wrote: On Jul 31 21:21, Andy Koppe wrote: On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. Thanks. But, hmm. The longer I play with it, the less I like the green glow. It adds an eerie touch to the C Now what's wrong with that? Cygwin - mean and a bit eerie. ;) and it still doesn't set the C really apart on dark backgrounds. I disagree, looking at a desktop with a darkish picture and dark grey taskbar and window borders. I think we should go with a grey outline. I did eventually work out how to turn the outline of fatbuttlarry's icon grey. See attachments. Having used both variants for a while, I agree that a grey outline does look better. Andy
Re: 256x256 px icons
On Aug 2 15:49, Andy Koppe wrote: On 1 August 2011 21:05, Andy Koppe wrote: On 1 August 2011 09:07, Corinna Vinschen wrote: On Jul 31 21:21, Andy Koppe wrote: On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. Thanks. But, hmm. The longer I play with it, the less I like the green glow. It adds an eerie touch to the C Now what's wrong with that? Cygwin - mean and a bit eerie. ;) and it still doesn't set the C really apart on dark backgrounds. I disagree, looking at a desktop with a darkish picture and dark grey taskbar and window borders. I think we should go with a grey outline. I did eventually work out how to turn the outline of fatbuttlarry's icon grey. See attachments. Having used both variants for a while, I agree that a grey outline does look better. I tried your icons on my desktop and the standalone icon looks good. In the terminal icons the beveled C looks better than the fatbuttlarry C, cleaner, crisper. It's also easier to distinguish from the dark background, but that's probably just because you used a darker shade of grey for the frame. In the terminal window, a lighter grey really doesn't hurt. Generally it looks like your C's are a pixel or two smaller, except in the smallest sizes. Gimp shows that you're always leaving a transparent frame of at least one pixel. Any reason for that? I guess we're getting close to the end result now. The question is just, should we use fatbuttlarry's bubbly C, or Warrens beveled C? I like both. The beveled C exists in 256x256, too. I like the beveled C better in the terminal frame, but I like the bubbly C better standalone. Maybe we can just use both in this combination? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 8/2/2011 11:24 AM, Corinna Vinschen wrote: I guess we're getting close to the end result now. So, how are you (Andy, Corinna) planning to handle the .ico file(s) themselves? Are you 1. (Andy) planning to put it/them into the mintty executable as resource(s), 2. ship the .ico file(s) in '/' as part of the main cygwin package, as we have long done with cygwin.ico 3. Incorporate it/them into cygicon*.dll as part of the cygutils package or some combination? I'm open to #3, but I'll need provenance and licensing info (see the end of /usr/share/doc/cygutils/cygicons/README ) P.S. I've been quiet on the artistic aspects of this discussion 'cause, well, I'm a no-talent hack, and I figured ya'll could do all the bike-shedding without my $0.37 (adjusted for inflation). -- Chuck
Re: 256x256 px icons
On Aug 2 11:45, Charles Wilson wrote: On 8/2/2011 11:24 AM, Corinna Vinschen wrote: I guess we're getting close to the end result now. So, how are you (Andy, Corinna) planning to handle the .ico file(s) themselves? Are you 1. (Andy) planning to put it/them into the mintty executable as resource(s), 2. ship the .ico file(s) in '/' as part of the main cygwin package, as we have long done with cygwin.ico 3. Incorporate it/them into cygicon*.dll as part of the cygutils package or some combination? I'm open to #3, but I'll need provenance and licensing info (see the end of /usr/share/doc/cygutils/cygicons/README ) I would stick to the standard terminal icon for mintty(*), except in the case of the Cygwin Terminal desktop and start menu icons. Both files will be installed into / just as today. They can (and maybe should) also become part of cygicon DLL. Corinna (*) Well, unless Andy wants to take over the terminal icon with the C in it, but that's entirely his own call. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: 256x256 px icons
On 2 August 2011 17:06, Corinna Vinschen wrote: On Aug 2 11:45, Charles Wilson wrote: On 8/2/2011 11:24 AM, Corinna Vinschen wrote: I guess we're getting close to the end result now. So, how are you (Andy, Corinna) planning to handle the .ico file(s) themselves? Are you 1. (Andy) planning to put it/them into the mintty executable as resource(s), 2. ship the .ico file(s) in '/' as part of the main cygwin package, as we have long done with cygwin.ico 3. Incorporate it/them into cygicon*.dll as part of the cygutils package or some combination? I'm open to #3, but I'll need provenance and licensing info (see the end of /usr/share/doc/cygutils/cygicons/README ) I would stick to the standard terminal icon for mintty(*), except in the case of the Cygwin Terminal desktop and start menu icons. Sounds good to me. Both files will be installed into / just as today. I thought the desktop and start menu icons would be the same. (Setup.exe's icon might be different.) Andy
Re: [PATCH] clock_nanosleep(2)
On Aug 1 23:09, Yaakov (Cygwin/X) wrote:
On Sun, 2011-07-31 at 10:24 +0200, Corinna Vinschen wrote:
anything new from the clock_nanosleep frontier?
Sorry, I've been having elusive problems with CVS HEAD that have been
making it hard to test my patch.
Here's what I have so far, FWIW. So far I've found two problems with
it: the remaining time returned is incorrect, based on testing of
nanosleep(),
Does that mean the return value from NtQueryTimer is unreliable? In
what way is it wrong? Does nanosleep wait too long or not long enough?
If NtQueryTimer is unusable, maybe we should just skip the idea to return
the remaining time from cancelabel_wait and simply use the return
value from hires_ms::timeGetTime_ns() to return the remaining time
from {clock_}nanosleep, kind of like
LONGLONG remaining = hires_ms::timeGetTime_ns ();
cancelable_wait();
LONGLONG remaining = hires_ms::timeGetTime_ns () - start;
rem-tv_sec = remaining / NSPERSEC;
rem-tv_nsec = remaining - (rem-tv_sec * NSPERSEC);
and the pthread_spin chunk doesn't look right (previously
the timeout would repeat in the while loop, but that won't happen the
way the waitable timer is set up).
It doesn't look wrong to me, but then again, I didn't test it...
I'll try to get back to this as soon as I am able to test this properly.
In the meantime, is there anything obvious I'm missing?
Nothing I can think of. This looks good.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: bash-4.2 and symlink to folder that turns to be not executable
On Tue, Aug 02, 2011 at 07:53:44AM +0159, Denis Excoffier wrote: On Mon, Aug 01, 2011 at 07:02:48PM +0200, Corinna Vinschen wrote: Ouch. I made a mistake in a bracket term in faccessat. Fixed in CVS. Thanks for following up with more testing. I tried to compile the cygwin sources and it failed because bfd.h is not found (in dumper.cc). Since asection is used everywhere in this file, it seems needed. I use the last binutils-2.21.53-1 which does not contain usr/include/bfd.h while the previous binutils-2.20.51-2 had it. I am currently trying with the last binutils and the additional bfd.h (and ansidecl.h, symcat.h, dis-asm.h, bfdlink.h) poked in my /usr/include. Seems strange that bfd.h is missing since /usr/share/info/bfd.info.gz documents it. Denis Excoffier. The compilation worked well (with GCC 4.3.4), last access times shows that bfdlink.h and dis-asm.h were not used. Also, the original problem has disappeared. Thank you. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: gmp-4.3.2-1
I have released a new version of the gmp library for arbitrary precision arithmetic. The new release is the final release in the 4.3 series. Homepage: http://gmplib.org/ Upstream fixes for issues in 4.3.1 http://gmplib.org/oldrel/ * The function mpf_eq has several bugs. * For extremely large operands, there are overflow issues in input conversion affecting mpz_set_str, mpz_inp_str, mpf_set_str, and mpf_get_str. * Multiplication of an operand of up to a few thousand digits by a huge operand triggers a too large stack allocation, leading to segfaults. * A hard-to-trigger bug in FFT multiplication exists. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: gdb-7.3.50-1
On Sun, 2011-07-31 at 13:59 -0400, Christopher Faylor wrote: As usual, I forgot an item of news that I wanted to impart a second after hitting 'y'. For those who follow this type of thing, gdb now has a python scripting interface. That is not turned on in this Cygwin release, primarily because the release was so overdue that I didn't want to waste time figuring out what I needed to pull into my cross-build environment. If I may, based on looking at configure, you'll need libpython2.6.dll.a in $sysroot/usr/lib and the Python headers in $sysroot/usr/include/python2.6, and add -I$sysroot/usr/include/python2.6 to CPPFLAGS. (I wouldn't advise moving them straight into $sysroot/usr/include/, their names are too generic.) FWIW, I just added a cygwin-python package to the Fedora Cygwin repo which should do the trick. HTH, Yaakov -- 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: perl 5.14.1 update?
2011/8/1 Philip Kime philk...@kime.org.uk: Any update on likely release of perl 5.14.1? not ready yet. still having rebase troubles -- 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
sshd failes allocating /dev/tty[0-9]
Cygwin Configuration Diagnostics atteched. Maybe crank up the debugging flags to maximum? I assume sshd is still stopped from your last run of sshd -d. If that doesn't sound right to you, you may want to investigate why it's not running now. sshd was stopped while that run because it did not login anyway. and still don't. The messages debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/tty2 chown(/dev/tty2, 11135, 10513) failed: Bad file descriptor debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/tty2 were got running sshd -d in console. I've started sshd and run the cygcheck again. The output is attached. However, there is no actual difference. I've stopped using mintty and tried the same in a windows' cmd-console window. The problem persists. The only difference is ownership of /dev/tty2. I've tried chown on /dev/tty2. It reports missing file, however it exists $ ls -l /dev/tty2 crw--- 1 SYSTEM Administrators 136, 2 Aug 2 14:26 /dev/tty2. $ chown user /dev/tty2 chown: changing ownership of `/dev/tty2': No such file or directory Additional information that could be helpful: $ mount C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) $ groups Domain Users Administrators Remote Desktop Users Users I have no clue. It look like the /dev is virtual fs for chown and real for ls. But both are from cygwin: $ which chown ls /usr/bin/chown /usr/bin/ls -- Regards, Alexey. Cygwin Configuration Diagnostics Current System Time: Tue Aug 02 14:21:31 2011 Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: c:\cygwin\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ c:\usr\bin Output from c:\cygwin\bin\id.exe UID: 11135(user) GID: 10513(Domain Users) 10513(Domain Users) 555(Remote Desktop Users) 545(Users) 11108(ANK.SUPPORT) SysDir: C:\Windows\system32 WinDir: C:\Windows CYGWIN = 'notty' Path = 'c:\cygwin\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\usr\bin' ALLUSERSPROFILE = 'C:\ProgramData' APPDATA = 'C:\Users\user\AppData\Roaming' CommonProgramFiles = 'C:\Program Files (x86)\Common Files' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' CommonProgramW6432 = 'C:\Program Files\Common Files' COMPUTERNAME = 'SOULNE4NY' ComSpec = 'C:\Windows\system32\cmd.exe' FARHOME = 'C:\Program Files (x86)\Far' FARLANG = 'English' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Users\user' LOCALAPPDATA = 'C:\Users\user\AppData\Local' LOGONSERVER = '\\ANKSRV' NUMBER_OF_PROCESSORS = '4' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_ARCHITEW6432 = 'AMD64' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = '6' PROCESSOR_REVISION = '2a07' ProgramData = 'C:\ProgramData' ProgramFiles = 'C:\Program Files (x86)' ProgramFiles(x86) = 'C:\Program Files (x86)' ProgramW6432 = 'C:\Program Files' PROMPT = '$P$G' PSI_ENABLE_VIDEO = '1' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' PUBLIC = 'C:\Users\Public' SESSIONNAME = 'Console' SystemDrive = 'C:' SystemRoot = 'C:\Windows' TEMP = 'C:\Users\user\AppData\Local\Temp' TMP = 'C:\Users\user\AppData\Local\Temp' USERDNSDOMAIN = 'ANK-SIA.COM' USERDOMAIN = 'ANK' USERNAME = 'user' USERPROFILE = 'C:\Users\user' VCToolkitInstallDir = 'C:\usr\ms\vc7\' windir = 'C:\Windows' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' HKEY_CURRENT_USER\Console\C:_cygwin_bin_bash.exe (default) = 0x1e610066 WindowSize = 0x00290066 WindowPosition = 0x00790194 FontSize = 0x0012000a FontFamily = 0x0030 FontWeight = 0x0190 FaceName = 'Terminal' QuickEdit = 0x0001 HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\c:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: c:\cygwin c: hd NTFS 65538Mb 48% CP CS UN PA FC win7 root z: hd NTFS131069Mb 3% CP CS UN PA FC win7 var c:\cygwin/ system binary,auto c:\cygwin\bin/usr/bin system binary,auto c:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: c:\cygwin\bin\awk -
Re: Portable shell code between Cygwin and Linux
Hi Csaba,
Csaba Raduly wrote:
On Mon, Aug 1, 2011 at 8:49 AM, Sebastien Vauban wrote:
Andrey Repin wrote:
Moreover, the very first line is wrong.
Must be
alias vpnup='exec sudo openvpn --config $HOME/config/client.vpn --writepid
/tmp/openvpn.pid '
that's where his problem began, IMO.
That's interesting. I thought this was completely equivalent (~ or $HOME),
and preferred the shorter version.
But you say it's not. Can you comment on this? Thanks in advance...
bash.info Tilde expansion:
If a word begins with an unquoted tilde character (`~'), all of the
characters up to the first unquoted slash (or all characters, if there
is no unquoted slash) are considered a TILDE-PREFIX.
Note word begins. I've been bitten by this in a makefile:
OPENSSL_DIR := ~/lib/openssl
CPPFLAGS := -I$(OPENSSL_DIR)
The gcc command line then contained -I~/lib/openssl, and the ~ was not
expanded by the shell. ${HOME}/lib/openssl would have worked.
Excellent explanation. I was totally unaware of this.
If you want the same alias to work on Cygwin and Linux, you should set
up your $HOME on Cygwin to contain config/client.vpn
You can set your home in /etc/passwd and point it to /cygdrive/c/home
(this may have been mentioned already).
The idea is to always refer to the VPN config as
${HOME}/config/client.vpn and ensure that Cygwin can access it that
way.
I, maybe, have done it the completely wrong way(TM). As it currently is, I've
defined an environment variable in Windows itself:
HOME=c:/home/sva
I did not touch so far /etc/passwd. The only visible effect of this is that
when firing up a bash terminal, the default directory is set to:
c:/Documents and Settings/Sebastien
OK, I will update my HOME directory in /etc/passwd. Thanks for the reminder.
Do I have, though, to define HOME in Windows, in Cygwin (.bashrc or such), or
nowhere?
Best regards,
Seb
--
Sebastien Vauban
--
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: Portable shell code between Cygwin and Linux
Hi Corinna, Corinna Vinschen wrote: On Aug 1 08:46, Sebastien Vauban wrote: Corinna Vinschen wrote: alias vpnup='exec sudo openvpn --config ~/config/client.vpn --writepid /tmp/openvpn.pid ' While this worked perfectly under Ubuntu, I've had to make up a customized version for Windows: alias vpnupwin='cd c:/home/sva/config; openvpn --config client.vpn --writepid c:/cygwin/tmp/openvpn.pid ' Don't use Win32 paths. Use POSIX paths: alias vpnupwin='cd /cygdrive/c/home/sva/config; openvpn --config client.vpn --writepid /cygdrive/c/cygwin/tmp/openvpn.pid ' But, if I write it like that, this never will work under Ubuntu, does it? Or is it possible with some mount magic to void the prefix /cydgrive/c? How is that different from using a drive letter like C:? It's not. Simply, both did not work in a portable way. The best you can do is to create a mount point(*) under Cygwin which has the same path as under Ubuntu. Then, just use the same POSIX paths on both systems. My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu, having the files located in the same place (relative to my home dir). I also tried you suggestion for another command, which was: perl C:/home/sva/src/csv2ledger/CSV2Ledger.pl -f $FileMatches -i $tmpfile.clean This works fine under Cygwin right now. Rewritten with POSIX paths: perl /cygdrive/c/home/sva/src/csv2ledger/CSV2Ledger.pl -f $FileMatches -i $tmpfile.clean It does not work anymore... So you're not using Cygwin perl, or you changed your cygdrive prefix(**). I'm not. I don't know why but, when I installed Perl (months ago), I did not think at looking in Cygwin packages. Seems I'm bad! Best regards, Seb -- Sebastien Vauban -- 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: Portable shell code between Cygwin and Linux
Hi Corinna Vinschen, Corinna Vinschen wrote: How is that different from using a drive letter like C:? The best you can do is to create a mount point(*) under Cygwin which has the same path as under Ubuntu. Then, just use the same POSIX paths on both systems. As I put all my files starting at c:/home/sva, I'd then to mount C: = / right? So that my home directory under Ubuntu (/home/sva) is the same under Cygwin (/home/sva = C:/home/sva). Though, the following did not succeed: #+begin_src sh $ mount C: / -o binary mount: warning: couldn't determine mount type. mount: /: Operation not permitted #+end_src Is this operation really not permitted? Best regards, Seb -- Sebastien Vauban -- 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: Portable shell code between Cygwin and Linux
Hi Thorsten, Thorsten Kampe wrote: * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200) My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu Why don't have simply put your alias definitions in if [[ $OSTYPE = cygwin ]]; then else? Because I really want one single definition which could work on every system I'm using. I don't like copy/pasting things, and just changing bits of the code, if I can avoid it. And this is not only for aliases. I'd like my shell scripts in general to be able to run in whichever PC I'm on, be it Ubuntu or Windows. Best regards, Seb -- Sebastien Vauban -- 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: Portable shell code between Cygwin and Linux
Hi Csaba,
Sebastien Vauban wrote:
Csaba Raduly wrote:
On Mon, Aug 1, 2011 at 8:49 AM, Sebastien Vauban wrote:
Andrey Repin wrote:
Moreover, the very first line is wrong.
Must be
alias vpnup='exec sudo openvpn --config $HOME/config/client.vpn --writepid
/tmp/openvpn.pid '
that's where his problem began, IMO.
If you want the same alias to work on Cygwin and Linux, you should set
up your $HOME on Cygwin to contain config/client.vpn
You can set your home in /etc/passwd and point it to /cygdrive/c/home
(this may have been mentioned already).
The idea is to always refer to the VPN config as
${HOME}/config/client.vpn and ensure that Cygwin can access it that
way.
I, maybe, have done it the completely wrong way(TM). As it currently is, I've
defined an environment variable in Windows itself:
HOME=c:/home/sva
I did not touch so far /etc/passwd. The only visible effect of this is that
when firing up a bash terminal, the default directory is set to:
c:/Documents and Settings/Sebastien
OK, I will update my HOME directory in /etc/passwd. Thanks for the reminder.
Just wanted to do the above. Though, I just realized I had already done it --
months ago, then:
Sebastien:unused:1007:513:Fabrice,U-MEDIACENTER\Fabrice,S-1-5-21-57802372-1363436062-342225281-1007:/cygdrive/c/home/sva:/bin/bash
So, the fact the default directory is set to the Windows one is not due to it.
Do I have, though, to define HOME in Windows, in Cygwin (.bashrc or such), or
nowhere?
Best regards,
Seb
--
Sebastien Vauban
--
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: bzr completely broken?
My host got reimaged, and I reinstalled Cygwin. Now bzr is broken again: $ bzr st 11 [main] python 4024 C:\cygwin\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\time.dll to same address as parent: 0xDC != 0xFD 12 [main] python 5280 fork: child 4024 - died waiting for dll loading, errno 11 bzr: ERROR: [Errno 11] Resource temporarily unavailable But this time, rebaseall fails too: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. -- 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: bzr completely broken?
On Tue, Aug 02, 2011 at 09:23:48AM -0400, Andrew Schulman wrote: My host got reimaged, and I reinstalled Cygwin. Now bzr is broken again: $ bzr st 11 [main] python 4024 C:\cygwin\bin\python.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\python2.6\lib-dynload\time.dll to same address as parent: 0xDC != 0xFD 12 [main] python 5280 fork: child 4024 - died waiting for dll loading, errno 11 bzr: ERROR: [Errno 11] Resource temporarily unavailable But this time, rebaseall fails too: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. Does /usr/bin/cygcrypt-0.dll exist? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl 5.14.1 update?
2011/8/2 Francois Isabelle: Hi I don't have too much experience with building perl on CYGWIN, but I'd probably be able to help if you can take a minute to explain your problems and what needs to be done to fix them Sorry Francois, I don't think so. 2011/8/1 Philip Kime: Any update on likely release of perl 5.14.1? not ready yet. still having rebase troubles -- 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: bzr completely broken?
$ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. Does /usr/bin/cygcrypt-0.dll exist? Yes: $ ll /usr/bin/cygcrypt-0.dll -r-xr-xr-x 1 ASchulma Administrators 6656 Oct 19 2003 /usr/bin/cygcrypt-0.dll* -- 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: bzr completely broken?
On Tue, Aug 02, 2011 at 10:07:42AM -0400, Andrew Schulman wrote: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. Does /usr/bin/cygcrypt-0.dll exist? Yes: $ ll /usr/bin/cygcrypt-0.dll -r-xr-xr-x 1 ASchulma Administrators 6656 Oct 19 2003 /usr/bin/cygcrypt-0.dll* Does something like this help: cd /usr/bin mv cygcrypt-0.dll cygcrypt-0.dll.saf cp -a cygcrypt-0.dll.saf cygcrypt-0.dll ? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Portable shell code between Cygwin and Linux
On Aug 2 14:22, Sebastien Vauban wrote: Hi Corinna Vinschen, Corinna Vinschen wrote: How is that different from using a drive letter like C:? The best you can do is to create a mount point(*) under Cygwin which has the same path as under Ubuntu. Then, just use the same POSIX paths on both systems. As I put all my files starting at c:/home/sva, I'd then to mount C: = / right? Wrong. Don't change the root mount point. So that my home directory under Ubuntu (/home/sva) is the same under Cygwin (/home/sva = C:/home/sva). Though, the following did not succeed: #+begin_src sh $ mount C: / -o binary mount: warning: couldn't determine mount type. mount: /: Operation not permitted #+end_src Is this operation really not permitted? Don't do this. Add a mount point to /home to your fstab. Did you *read* the User's Guide? In my previous mail I pasted two links for your convenience. For good measure I add another one: http://cygwin.com/cygwin-ug-net/using.html#mount-table http://cygwin.com/cygwin-ug-net/using.html#cygdrive http://cygwin.com/cygwin-ug-net/using-utils.html#mount Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: bzr completely broken?
On Aug 2 10:07, Andrew Schulman wrote: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. Does /usr/bin/cygcrypt-0.dll exist? Yes: $ ll /usr/bin/cygcrypt-0.dll -r-xr-xr-x 1 ASchulma Administrators 6656 Oct 19 2003 /usr/bin/cygcrypt-0.dll* chmod u+w /usr/bin/cygcrypt-0.dll ? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Portable shell code between Cygwin and Linux
On 8/2/2011 8:24 AM, Sebastien Vauban wrote: Hi Thorsten, Thorsten Kampe wrote: * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200) My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu Why don't have simply put your alias definitions in if [[ $OSTYPE = cygwin ]]; then else? Because I really want one single definition which could work on every system I'm using. I don't like copy/pasting things, and just changing bits of the code, if I can avoid it. And this is not only for aliases. I'd like my shell scripts in general to be able to run in whichever PC I'm on, be it Ubuntu or Windows. I get that -- I really do. The suggestion to use a few conditionals that look at the which OS you're on does not involve continued tweaking. Once you have the right file, it works everywhere (for which you have provided suitable cases) using the exact same file. It's just that different parts get executed on different platforms. It's not as elegant as achieving an arrangement with no conditionals, but it's practical and flexible. I've done it for years myself! Regards -- Eliot Moss -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin permissions problem on a network drive
On Jul 6 11:43, Bill Metzenthen wrote: Corinna Vinschen wrote: If I now try to use cygwin to create anything then it fails (despite it reporting that I have rwx permissions for the directory): For now, set the mount point for this drive to noacl. If you're accessing the share via /cygdrive, create a distinct mount point for it. I'm not sure that I'm doing this the right way. No. I meant a distinct mount point, *different* from your cygdrive prefix. See http://cygwin.com/cygwin-ug-net/using.html#cygdrive This works: H: /h xyz binary,noacl 0 0 none /mnt cygdrive binary,posix=0,user 0 0 Or this: H: /myhome xyz binary,noacl 0 0 none / cygdrive binary,posix=0,user 0 0 Corinna I'm having the same problems with my $HOME folder, which is on a network share. I was able to create an extra mount point for the location, unfortunately that didn't help with the original $HOME. Could you please describe what I have to do circumvent the permission problem for $HOME? Thanks a lot, Spam Bouncer -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- 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
git-svn hang starting with 20110721 snapshot.
I use git-svn extensively in my day-to-day work, and I noticed with
recent snapshots that some of the git-svn commands are hanging. I
narrowed it down to the 20110721 snapshot. 20110713 is the last one
that works fine.
I realize this isn't exactly a STC, but I don't have the time right
now to narrow it down further (or the skills, really). I've attached
a script which reproduces the problem. It requires svn and
git-svn. In the script, the first git svn init command hangs with
20110721, but the entire script succeeds with 20110713.
I hope this is enough information to track down the problem, because
I was absolutely LOVING the speed increase in 20110801.
--
David Rothenberger daver...@acm.org
Captain Penny's Law:
You can fool all of the people some of the time, and
some of the people all of the time, but you Can't Fool Mom.
#!/bin/bash
D=/tmp/git-svn-problem.$$
mkdir $D
echo Created $D
#trap { x=$?; rm -fr $D; exit $x; } SIGINT SIGHUP EXIT
#D=$PWD
#rm -fr repos
#rm -fr work
R=${D}/repos
RURL=file://$R
echo Creating an SVN repository and workspace.
# Create the SVN repository
svnadmin create $R
# Create a work space
W=${D}/work
svn co $RURL $W
cd $W
svn mkdir tags trunk branches
date trunk/file1
svn add trunk/file1
svn ci -m 'Initial version'
# Initialize using git-svn
echo
echo Initializing with git svn.
echo This hangs with recent snapshots.
cd trunk
git svn init -s $RURL
rm file1
git svn fetch --all
echo
echo Making a change in svn, then doing git svn rebase --all.
echo git svn rebase --all also hangs.
# Make a change in svn
date file1
svn ci -m 'Updated file1'
# git svn rebase --all
git reset --hard
git svn rebase --all
rm -fr $D
--
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: bzr completely broken?
On Aug 2 10:07, Andrew Schulman wrote: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 Something still using cygcrypt-0.dll? Good thought, but no. I stopped all Cygwin processes, since rebaseall wouldn't run with them running. Also TaskInfo confirms that no Cygwin processes are running, and no process has any cyg*.dll loaded. Does /usr/bin/cygcrypt-0.dll exist? Yes: $ ll /usr/bin/cygcrypt-0.dll -r-xr-xr-x 1 ASchulma Administrators 6656 Oct 19 2003 /usr/bin/cygcrypt-0.dll* chmod u+w /usr/bin/cygcrypt-0.dll ? Uh... yes. Thanks. It works now. Although I had to get more aggressive and run find /usr -iname \*.dll -o -iname \*.so | xargs chmod u+w After that, rebaseall completed successfully, and bzr now works again. Who maintains the rebase package? I wonder if it should automatically try to chmod u+w all of the files it wants to operate on-- maybe just temporarily. A. -- 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: Portable shell code between Cygwin and Linux
* Eliot Moss (Tue, 02 Aug 2011 11:40:44 -0400) On 8/2/2011 8:24 AM, Sebastien Vauban wrote: Thorsten Kampe wrote: * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200) My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu Why don't have simply put your alias definitions in if [[ $OSTYPE = cygwin ]]; then else? Because I really want one single definition which could work on every system I'm using. [...] The suggestion to use a few conditionals that look at the which OS you're on does not involve continued tweaking. Once you have the right file, it works everywhere (for which you have provided suitable cases) using the exact same file. It's just that different parts get executed on different platforms. It's not as elegant as achieving an arrangement with no conditionals, but it's practical and flexible. Couldn't have said it better. Cygwin is not Linux and you just can't ignore the differences. For example I have different aliases for netstat and ps on Linux and on Windows. They just don't have the same options. Thorsten -- 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: Portable shell code between Cygwin and Linux
On Tue, Aug 02, 2011 at 10:04:43PM +0200, Thorsten Kampe wrote: * Eliot Moss (Tue, 02 Aug 2011 11:40:44 -0400) On 8/2/2011 8:24 AM, Sebastien Vauban wrote: Thorsten Kampe wrote: * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200) My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu Why don't have simply put your alias definitions in if [[ $OSTYPE = cygwin ]]; then else? Because I really want one single definition which could work on every system I'm using. [...] The suggestion to use a few conditionals that look at the which OS you're on does not involve continued tweaking. Once you have the right file, it works everywhere (for which you have provided suitable cases) using the exact same file. It's just that different parts get executed on different platforms. It's not as elegant as achieving an arrangement with no conditionals, but it's practical and flexible. Couldn't have said it better. Cygwin is not Linux and you just can't ignore the differences. For example I have different aliases for netstat and ps on Linux and on Windows. They just don't have the same options. ps does, if you alias ps=procps. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sshd failes allocating /dev/tty[0-9]
On 8/2/2011 7:32 AM, Alexey Luchko wrote: Cygwin Configuration Diagnostics atteched. Maybe crank up the debugging flags to maximum? I assume sshd is still stopped from your last run of sshd -d. If that doesn't sound right to you, you may want to investigate why it's not running now. sshd was stopped while that run because it did not login anyway. and still don't. sshd will run even if you're having problems connecting to it. I'm just making sure that you are testing with a running server. If not, then you want to make sure the server is running first. The messages debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/tty2 chown(/dev/tty2, 11135, 10513) failed: Bad file descriptor debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/tty2 were got running sshd -d in console. I was suggesting that you run sshd with all the debug flags (i.e. -d -d -d) to see if you'd get more useful information about your problem. snip I have no clue. It look like the /dev is virtual fs for chown and real for ls. But both are from cygwin: $ which chown ls /usr/bin/chown /usr/bin/ls /dev is a virtual. See: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices -- Larry _ 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: cygwin permissions problem on a network drive
On 8/2/2011 12:10 PM, spamboun...@gmx.de wrote: On Jul 6 11:43, Bill Metzenthen wrote: Corinna Vinschen wrote: If I now try to use cygwin to create anything then it fails (despite it reporting that I have rwx permissions for the directory): For now, set the mount point for this drive to noacl. If you're accessing the share via /cygdrive, create a distinct mount point for it. I'm not sure that I'm doing this the right way. No. I meant a distinct mount point, *different* from your cygdrive prefix. See http://cygwin.com/cygwin-ug-net/using.html#cygdrive This works: H: /h xyz binary,noacl 0 0 none /mnt cygdrive binary,posix=0,user 0 0 Or this: H: /myhome xyz binary,noacl 0 0 none / cygdrive binary,posix=0,user 0 0 Corinna I'm having the same problems with my $HOME folder, which is on a network share. I was able to create an extra mount point for the location, unfortunately that didn't help with the original $HOME. Could you please describe what I have to do circumvent the permission problem for $HOME? Access you $HOME folder through the new mount point (i.e. /h or /myhome) and you should be all set. -- Larry _ 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: bzr completely broken?
On 6/6/2011 9:01 AM, Andrew Schulman wrote: Am I right that bzr is just completely broken in Cygwin? If so, is there an ETA to get it fixed? My bzr is 2.3.1-1, in Cygwin 1.7.9. No matter what bzr command I run, I always get the same result: As a quick workaround, you can delete all the dll files in /usr/lib/python2.6/site-packages/bzrlib. bzr will complain that it can't find the native modules, but it'll fall back to pure-Python code and work just fine. You can eliminate the warning by putting ignore_missing_extensions=True in ~/.bazaar/bazaar.conf. signature.asc Description: OpenPGP digital signature
Show GNU screen captions inside of mintty
When using mintty with GNU screen, all status messages (captions) are shown in the title bar instead of the interior of the terminal. I originally found this feature quite nifty, but now that I use an always-on caption for screen, it means that I end up losing visibility of the window title and hardstatus. What needs to be modified in order to make captions show up in the interior of mintty? Eric -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Show GNU screen captions inside of mintty
On 8/2/2011 9:30 PM, Eric Pruitt wrote:
When using mintty with GNU screen, all status messages (captions) are shown
in
the title bar instead of the interior of the terminal. I originally found
this
feature quite nifty, but now that I use an always-on caption for screen, it
means that I end up losing visibility of the window title and hardstatus.
What needs to be modified in order to make captions show up in the interior
of mintty?
Here's what I use:
hardstatus string screen %n (%t)%? [%h]%?
caption always '%{yb} %H %{k}|%L=%= %{w}%?%-Lw%45L%?%{=b bR}[%{W}%n%f
%t%?(%u)%?%{=b bR}]%{= bw}%?%+Lw%?%?%=%-30= %{k}|%{Y}%l%{k}|%{=b C}
%m/%d %c %{W}'
The hardstatus line sets mintty's title bar; the caption line sets the
bottom row of the terminal. (I[m thinking of removing the load info (the
|%{Y}%l%{k}| bit) from the cygwin version, but I use the same .screenrc
on linux.
--
Chuck
--
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: Show GNU screen captions inside of mintty
On Tue, Aug 02, 2011 at 10:58:41PM -0400, Charles Wilson wrote:
On 8/2/2011 9:30 PM, Eric Pruitt wrote:
When using mintty with GNU screen, all status messages (captions) are shown
in
the title bar instead of the interior of the terminal. I originally found
this
feature quite nifty, but now that I use an always-on caption for screen, it
means that I end up losing visibility of the window title and hardstatus.
What needs to be modified in order to make captions show up in the interior
of mintty?
Here's what I use:
hardstatus string screen %n (%t)%? [%h]%?
caption always '%{yb} %H %{k}|%L=%= %{w}%?%-Lw%45L%?%{=b bR}[%{W}%n%f
%t%?(%u)%?%{=b bR}]%{= bw}%?%+Lw%?%?%=%-30= %{k}|%{Y}%l%{k}|%{=b C}
%m/%d %c %{W}'
That does what I want, albeit not with the formatting options I'll. Could you
explain how and why that works? I like that the status messages remain in the
title bar, too. Now I just need to figure out how to do the same thing on
xterm -- keep the caption as the last line but status messages in the title
bar. Any help you could offer on that would be great as well.
Thanks,
Eric
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Show GNU screen captions inside of mintty
On 8/2/2011 11:10 PM, Eric Pruitt wrote: I want, albeit not with the formatting options I'll. Could you explain how and why that works? Nope, I flushed that Domain Specific Language from my short term memory after getting it to work as I wanted. I'd just be regurgitating the Fine Manual for you...GIYF. -- Chuck -- 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: Show GNU screen captions inside of mintty
On Wed, Aug 03, 2011 at 12:35:10AM -0400, Charles Wilson wrote: On 8/2/2011 11:10 PM, Eric Pruitt wrote: I want, albeit not with the formatting options I'll. Could you explain how and why that works? Nope, I flushed that Domain Specific Language from my short term memory after getting it to work as I wanted. I'd just be regurgitating the Fine Manual for you...GIYF. Alright, thanks anyway. I just tweaked my screenrc and learned that mintty will always display caption as the last line of the terminal while keeping status messages in the title bar. I didn't realize screen made a distinction between the two. I'm still curious what termcap settings it's using to put the status notification in the title, though and how to toggle it. Eric -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Show GNU screen captions inside of mintty
On 3 August 2011 05:50, Eric Pruitt wrote: On Wed, Aug 03, 2011 at 12:35:10AM -0400, Charles Wilson wrote: On 8/2/2011 11:10 PM, Eric Pruitt wrote: I want, albeit not with the formatting options I'll. Could you explain how and why that works? Nope, I flushed that Domain Specific Language from my short term memory after getting it to work as I wanted. I'd just be regurgitating the Fine Manual for you...GIYF. Alright, thanks anyway. I just tweaked my screenrc and learned that mintty will always display caption as the last line of the terminal while keeping status messages in the title bar. This has nothing to do with mintty and everything to do with screen and its configuration, unless you can show that mintty displays identical output differently from xterm, in which case you'd have found a compatibility issue. I didn't realize screen made a distinction between the two. I'd be quite surprised if it did, assuming identical configuration. Please provide instructions to show the difference, including TERM setting at the point screen is invoked and your .screenrc if necessary. (Keep in mind that I don't know an awful lot about 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
Updated: gmp-4.3.2-1
I have released a new version of the gmp library for arbitrary precision arithmetic. The new release is the final release in the 4.3 series. Homepage: http://gmplib.org/ Upstream fixes for issues in 4.3.1 http://gmplib.org/oldrel/ * The function mpf_eq has several bugs. * For extremely large operands, there are overflow issues in input conversion affecting mpz_set_str, mpz_inp_str, mpf_set_str, and mpf_get_str. * Multiplication of an operand of up to a few thousand digits by a huge operand triggers a too large stack allocation, leading to segfaults. * A hard-to-trigger bug in FFT multiplication exists.
