Re: emacs -nw keypad, tpu-edt.el, and C-h
Christopher Faylor wrote:
>>Now of course if emacs can translate low-level console I/O as it sees
>>fit, then the Cygwin DLL could also be able to translate Backspace into
>>^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a
>>look at fhandler_console.cc. It already uses ReadConsoleInput(), so
>>mapping from VK_BACK to ^? might be fairly straightforward actually.
>
> And a patch would have been appreciated...
Sorry, I didn't think I understood the code enough for that.
> However, I have made the change to Cygwin to translate backspace to ^?.
> It will be in the next snapshot.
Great, thanks! Does this apply both with and without CYGWIN=tty? And I
guess native console applications won't be affected by this?
The relevant termios default setting will need to change accordingly,
either by changing the definition of CERASE in include/sys/termios.h:
-#define CERASE CTRL('H')
+#define CERASE CDEL
Or by changing the initialisation in fhandler_termios.c:
- tc->ti.c_cc[VERASE] = CERASE;
+ tc->ti.c_cc[VERASE] = CDEL;
The cygwin section in /etc/termcap doesn't have a kb entry, so luckily
no change needed there.
terminfo has an entry for backspace though:
$ tput -T cygwin kbs | cat -v
^H
So this has to to change as well:
+++ terminfo.src2009-05-30 07:50:44.893933600 +0100
@@ -5221,7 +5221,7 @@
- kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kbs=^?, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
And then there are rxvt and xterm and their termcap and terminfo
entries as well ...
One more thing: with your change, Alt can be used to override ^? and
get ^H instead. Usually though, Ctrl is used as the modifier for this,
whereas Alt acts as Meta (i.e. it sends a ^[ prefix).
Andy
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] [1.7] Updated: git-1.6.3.1-1, git{k,-gui,-completion,-svn}-1.6.3.1-1
On Sat, May 30, 2009 at 1:43 PM, Eric Blake wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > A new release of git, 1.6.3.1-1, has been uploaded to the cygwin 1.7 > release area. This replaces 1.6.2.4-2 as current. > > NEWS: > = > This is a new upstream major release. I'm attaching the release notes; > see also the package documentation in /usr/share/doc/git/. > > When compiled out of the box, the upstream git maintainers cater to older > cygwin releases, and intentionally disable certain features that have been > reported on their mailing list, even though they work with the latest > cygwin. Therefore, this build turns those features back on. However, it > means that this version does assume that you are not using FAT or FAT32 to > hold your repositories, since they do not store file permissions very > accurately. > > DESCRIPTION: > > Git is popular version control system designed to handle very large > projects with speed and efficiency; it is used mainly for various open > source projects, most notably the Linux kernel. > > Git falls in the category of distributed source code management tools, > similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary > world). Every Git working directory is a full-fledged repository with full > revision tracking capabilities, not dependent on network access or a > central server. > > UPDATE: > === > To update your installation, click on the "Install Cygwin now" link on the > http://cygwin.com/ web page. This downloads setup.exe to your system. > Save it and run setup, answer the questions and pick up 'git', 'gitk', > 'git-gui', and/or 'git-completion' from the 'Devel' category. > > DOWNLOAD: > = > Note that downloads from sources.redhat.com (aka cygwin.com) aren't > allowed due to bandwidth limitations. This means that you will need to > find a mirror which has this update, please choose the one nearest to you: > http://cygwin.com/mirrors.html > > QUESTIONS: > == > If you want to make a point or ask a question the Cygwin mailing list is > the appropriate place. > > - -- > Eric Blake > volunteer cygwin git maintainer > > CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: > = > To unsubscribe to the cygwin-announce mailing list, look at the > "List-Unsubscribe: " tag in the email header of this message. Send email > to the address specified there. It will be in the format: > > cygwin-announce-unsubscribe-you=yourdomain@cygwin.com > > If you need more information on unsubscribing, start reading here: > > http://sourceware.org/lists.html#unsubscribe-simple > > Please read *all* of the information on unsubscribing that is available > starting at this URL. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Public key at home.comcast.net/~ericblake/eblake.gpg > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkogq24ACgkQ84KuGfSFAYDHmwCePH489RWycumRDdvurATFwjO+ > 2AcAoJuwmbQwaH+5eOHASgNEc9zP7Zsh > =Sh8Q > -END PGP SIGNATURE- > > GIT v1.6.3.1 Release Notes > == > > Fixes since v1.6.3 > -- > > * "git checkout -b new-branch" with a staged change in the index > incorrectly primed the in-index cache-tree, resulting a wrong tree > object to be written out of the index. This is a grave regression > since the last 1.6.2.X maintenance release. > > GIT v1.6.3 Release Notes > > > With the next major release, "git push" into a branch that is > currently checked out will be refused by default. You can choose > what should happen upon such a push by setting the configuration > variable receive.denyCurrentBranch in the receiving repository. > > To ease the transition plan, the receiving repository of such a > push running this release will issue a big warning when the > configuration variable is missing. Please refer to: > > http://git.or.cz/gitwiki/GitFaq#non-bare > http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 > > for more details on the reason why this change is needed and the > transition plan. > > For a similar reason, "git push $there :$killed" to delete the branch > $killed in a remote repository $there, if $killed branch is the current > branch pointed at by its HEAD, gets a large warning. You can choose what > should happen upon such a push by setting the configuration variable > receive.denyDeleteCurrent in the receiving repository. > > When the user does not tell "git push" what to push, it has always > pushed matching refs. For some people it is unexpected, and a new > configuration variable push.default has been introduced to allow > changing a different default behaviour. To advertise the new feature, > a big warning is issued if this is not configured and a git push without > arguments is attempted. > > > Updates since v1.6.2 > > > (subsystems) > > * various git-svn updates. > > * git-gui updates, inclu
Re: [ANNOUNCEMENT] [1.7] Updated: git-1.6.3.1-1, git{k,-gui,-completion,-svn}-1.6.3.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [please trim what you reply to; you didn't need to repeat the attachment verbatim] According to Matthew Iselin on 5/30/2009 3:45 AM: > On Sat, May 30, 2009 at 1:43 PM, Eric Blake wrote: > A new release of git, 1.6.3.1-1, has been uploaded to the cygwin 1.7 > release area. This replaces 1.6.2.4-2 as current. > > Hi, > This version of git is still unusable for actions requiring remote > access (for example, pull and clone). Output is, as already reported > multiple times on this list: > remote: Counting objects: 19973, done. > remote: Compressing objects: 100% (7588/7588), done. > fatal: read error on input: Bad address.99 KiB | 103 KiB/s This occurs when cloning via the git: protocol. Can you instead clone with the http: protocol to work around it? I still haven't had time to try and figure out why this fails for some repositories, but not others. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkohK/wACgkQ84KuGfSFAYDMYACeOJjOlgBNvUwPpu2hYT+1hwSO 6CIAn3ykMEJlkiAK4YPoZji2DncjSdLi =8/fT -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: R: [1.7] does LD_PRELOAD support more than 1 dll ?
--- Sab 30/5/09, Christopher ha scritto:
> >> ? Did you export it?? That might make a
> >> difference if the shell is involved.
> >>
> >> ? ? cheers,
> >> ? ? ? DaveK
> >>
> >Hi Dave,
> >also exporting all the 3 variables in the script
> >does make no difference
> >
> >export
> PATH="$builddir/src:$builddir/liboctave:$builddir/libcruft:$PATH"
> >export LD_PRELOAD="$liboctinterp:$liboctave:$libcruft"
> >export
> LD_LIBRARY_PATH="$builddir/src:$builddir/liboctave:$builddir/libcruft:$LD_LIBRARY_PATH"
> >OCTAVE_SITE_INITFILE="$top_srcdir/scripts/startup/main-rcfile"
> \
> > exec $driver "$builddir/src/octave"
> --no-init-path --path="$LOADPATH" --image-path="$IMAGEPATH"
> --doc-cache-file="$DOCFILE" --info-file="$INFOFILE" "$@"
> >
> >
> > 5 [main] sh 3964
> C:\cygwin2\bin\sh.exe: *** fatal error - error while loading
> shared libraries:
> /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll:
> cannot open shared object file: No such process
>
> From the source:
>
> if (!LoadLibraryW
> (lib.get_wide_win32_path (libname)))
> {
> __seterrno ();
> api_fatal ("error while
> loading shared libraries: %s: "
>
> "cannot open shared object file:
> %s", p,
>
> strerror (get_errno ()));
> }
>
> "No such process" == ESRCH == PROC_NOT_FOUND
>
> cgf
Hi Christopher
but the dll file is there:
$ ls -lh /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll
-rwxr-xr-x 1 itq00146 Domain_Users 202M May 27 20:01
/pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll
so how can it fail to load dlls only with LD_PRELOAD defined ?
Ok, I found it.
The order is also relevant
cygoctinterp.dll requires
cygcruft.dll and cygoctave.dll
cygoctave.dll requires
cygcruft.dll
So the working way is :
export LD_PRELOAD="$libcruft:$liboctave:$liboctinterp"
Regards
Marco
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: R: [1.7] does LD_PRELOAD support more than 1 dll ?
On Sat, May 30, 2009 at 12:59:15PM +, Marco Atzeri wrote:
>
>--- Sab 30/5/09, Christopher ha scritto:
>
>> >> ? Did you export it?? That might make a
>> >> difference if the shell is involved.
>> >>
>> >> ? ? cheers,
>> >> ? ? ? DaveK
>> >>
>> >Hi Dave,
>> >also exporting all the 3 variables in the script
>> >does make no difference
>> >
>> >export
>> PATH="$builddir/src:$builddir/liboctave:$builddir/libcruft:$PATH"
>> >export LD_PRELOAD="$liboctinterp:$liboctave:$libcruft"
>> >export
>> LD_LIBRARY_PATH="$builddir/src:$builddir/liboctave:$builddir/libcruft:$LD_LIBRARY_PATH"
>> >OCTAVE_SITE_INITFILE="$top_srcdir/scripts/startup/main-rcfile"
>> \
>> >? exec $driver "$builddir/src/octave"
>> --no-init-path --path="$LOADPATH" --image-path="$IMAGEPATH"
>> --doc-cache-file="$DOCFILE" --info-file="$INFOFILE" "$@"
>> >
>> >
>> >? ? ? 5 [main] sh 3964
>> C:\cygwin2\bin\sh.exe: *** fatal error - error while loading
>> shared libraries:
>> /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll:
>> cannot open shared object file: No such process
>>
>> From the source:
>>
>> ? ? ? if (!LoadLibraryW
>> (lib.get_wide_win32_path (libname)))
>> ? ? ? ? {
>> ? ? ? ? ? __seterrno ();
>> ? ? ? ? ? api_fatal ("error while
>> loading shared libraries: %s: "
>> ? ? ? ? ? ? ? ?
>> ? ???"cannot open shared object file:
>> %s", p,
>> ? ? ? ? ? ? ? ?
>> ? ???strerror (get_errno ()));
>> ? ? ? ? }
>>
>> "No such process" == ESRCH == PROC_NOT_FOUND
>>
>> cgf
>
>Hi Christopher
>but the dll file is there:
>
>$ ls -lh /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll
>-rwxr-xr-x 1 itq00146 Domain_Users 202M May 27 20:01
>/pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll
It doesn't say "File not found".
>so how can it fail to load dlls only with LD_PRELOAD defined ?
>
>Ok, I found it.
>The order is also relevant
>
>cygoctinterp.dll requires
> cygcruft.dll and cygoctave.dll
>
>cygoctave.dll requires
> cygcruft.dll
>
>So the working way is :
>
>export LD_PRELOAD="$libcruft:$liboctave:$liboctinterp"
i.e., dependency order is important. That isn't too surprising is it?
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: emacs -nw keypad, tpu-edt.el, and C-h
> One more thing: with your change, Alt can be used to override ^? and
> get ^H instead. Usually though, Ctrl is used as the modifier for this,
> whereas Alt acts as Meta (i.e. it sends a ^[ prefix).
Actually, we could take this one step further. In MinTTY, if Backspace
is set to send ^?, Ctrl+Backspace sends ^_ (i.e. 0x1F) rather than ^H.
This allows that key combination to also be distinguished from Ctrl+H,
e.g. as a shortcut for erasing a whole word, like in many GUI
applications. As it sends a single control character, it can be used
to replace ^W in the terminal settings, with 'stty werase ^_'. (I'm
not suggesting that werase should be set to ^_ by default.) Anyone who
actually wants a ^H can still get that with Ctrl+H.
The Linux console in Opensuse actually does the same thing, and two's
a standard, right? ;)
Here's a patch to do this:
--- fhandler_console.cc
+++ fhandler_console.cc
@@ -316,10 +316,10 @@
dev_state->nModifiers |= 8;
/* Adopt the linux standard of translating the backspace key to DEL
-except when ALT is pressed. */
+except when CTRL is pressed, in which case it is translated to ^_.
+ */
if (input_rec.Event.KeyEvent.wVirtualScanCode == 14)
- toadd = (control_key_state & (LEFT_ALT_PRESSED | RIGHT_ALT_PRESSED))
- ? "" : "\177";
+ toadd = (control_key_state & CTRL_PRESSED) ? CTRL("_") : CDEL;
else if (wch == 0
/* arrow/function keys */
|| (input_rec.Event.KeyEvent.dwControlKeyState & ENHANCED_KEY))
Andy
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: emacs -nw keypad, tpu-edt.el, and C-h
On Sat, May 30, 2009 at 07:00:46PM +0100, Andy Koppe wrote: >> One more thing: with your change, Alt can be used to override ^? and >> get ^H instead. Usually though, Ctrl is used as the modifier for this, >> whereas Alt acts as Meta (i.e. it sends a ^[ prefix). > >Actually, we could take this one step further. In MinTTY, if Backspace >is set to send ^?, Ctrl+Backspace sends ^_ (i.e. 0x1F) rather than ^H. >This allows that key combination to also be distinguished from Ctrl+H, >e.g. as a shortcut for erasing a whole word, like in many GUI >applications. As it sends a single control character, it can be used >to replace ^W in the terminal settings, with 'stty werase ^_'. (I'm >not suggesting that werase should be set to ^_ by default.) Anyone who >actually wants a ^H can still get that with Ctrl+H. > >The Linux console in Opensuse actually does the same thing, and two's >a standard, right? ;) Actually, no. I emulated the linux console on my system. kterminal and xterm also makes no distinction that I can see between CTRL-Backspace and Backspace. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs -nw keypad, tpu-edt.el, and C-h
>>The Linux console in Opensuse actually does the same thing, and two's >>a standard, right? ;) > > Actually, no. I emulated the linux console on my system. kterminal and > xterm also makes no distinction that I can see between CTRL-Backspace > and Backspace. As I said, I've seen the ^_ in the text console on Suse only. Cygwin's xterm at least does distinguish between Backspace and Ctrl+Backspace though: if Backspace is set to send ^H, Ctrl+Backspacce sends ^?, and vice versa. Andy -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
I'm reposting since I didn't mean to send this privately. On Fri, May 29, 2009 17:22, Alexey Borzenkov wrote: > Here, when I use russian Windows and I don't have LANG set (or when I > have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So > both, russian and european/chinese/japanese filenames will be valid. > Now there are three possibilities: How does the filename get to be a utf-8 multibyte string if you created the filename from an ANSI application? Since it sounds like Russian Windows uses a code page different from UTF-8. > And again, you must have misunderstood me. In my opinion: truncation > is a bug (should use replacement character, or fail exec altogether), > expecting utf-8 is not (if you tried to cat your copyright.txt on a > Linux box that uses utf-8, what would you expect to see on the > screen?) Ok, so where's the bug tracker so I can log a bug? -Edward -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[Fwd: Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line]
Repost for mailing list. On Sat, May 30, 2009 at 6:03 PM, Edward Lam wrote: >> Here, when I use russian Windows and I don't have LANG set (or when I >> have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So >> both, russian and european/chinese/japanese filenames will be valid. >> Now there are three possibilities: > How does the filename get to be a utf-8 multibyte string if you created > the filename from an ANSI application? Since it sounds like Russian > Windows uses a code page different from UTF-8. When you create a file from ansi application, Windows converts filenames to unicode, using your system code page. Cygwin 1.7 uses unicode. Cygwin converts filenames to multibyte when it communicates with Cygwin applications, and converts to unicode when it accepts data from Cygwin applications. When LANG is not set it is currently utf-8 (but could be anything arbitrary, I'm just glad that it's utf-8 because it converts data back and forth without losing characters and there are no problems with SO-UTF8). So cygwin applications work with utf-8 filenames, and console is utf-8, and cygwin communicates with Windows via unicode. But multibyte encoding is overridable via LC_ALL/LANG. When you are executing windows applications it's natural that you either pass filenames or some text. Since without LANG set Cygwin multibyte encoding is utf-8 it's only natural to use utf-8 to convert arguments to unicode when executing windows applications. After all, if you have a utf-8 filename with japanese characters it's only natural that "cmd.exe /c del /y $filename" and "cmd.exe /c echo $sometext" will succeed for any text that uses current cygwin encoding. Think of it like this: since file is being read by cygwin in your first email your copyright.txt had a wrong encoding. So you need to either use iconv to convert it (I hope that `iconv -c -f cp1251 ...` will do the right thing without specifying target encoding here), or specify LANG to what you are working with right now. And if you are using English windows with English regional settings, then your LANG should be en_US.CP1252, not en_US.ISO-8859-1 (CP1252 is what your windows applications are using!). I really don't know how to better explain all this, since in my head it's so clear and obvious. :-/ > Ok, so where's the bug tracker so I can log a bug? Isn't this mailing list serving as bug tracker? I just hope that whoever can fix this is reading our emails and will come up with the right solution. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
>> Ok, so where's the bug tracker so I can log a bug? > > Isn't this mailing list serving as bug tracker? I just hope that > whoever can fix this is reading our emails and will come up with the > right solution. Given the lack of developer acknowledgment (or refutation), I'm not getting my hopes up. -Edward -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] [1.7] Updated: libiconv-1.13-10
The GNU libiconv package provides an iconv() implementation, for use on systems which don't have one, or whose implementation cannot convert from/to Unicode. [[ compiled using gcc-3.4.4-999 ]] This release was compiled specifically for cygwin-1.7. In addition to taking advantage of new facilities provided by cygwin-1.7, it also differs from the simultaneously-released libiconv-1.13-1 for cygwin-1.5 in documentation and directory structure (the README references cygport-0.9.5 and cygwin-1.7.0-48, and the /usr/share/doc/ layout is influenced by the cygport changes between 0.4.4 and 0.9.5). Changes since libiconv-1.12-10 * update to latest upstream release (see upstream release notes, below) -- Charles Wilson volunteer libiconv maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Upstream Release Notes for 1.13 === * The library and the iconv program now understand platform dependent aliases, for better compatibility with the platform's own iconv_open function. Examples: "646" on Solaris, "iso88591" on HP-UX, "IBM-1252" on AIX. * For stateful encodings, when the input ends with a shift sequence followed by invalid input, the iconv function now increments the input pointer past the shift sequence before returning (size_t)(-1) with errno = EILSEQ. This is also like GNU libc's iconv() behaves. * The library exports a new function iconv_open_into() that stores the conversion descriptor in pre-allocated memory, rather than allocating fresh memory for it. * Added CP1131 converter. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[ANNOUNCEMENT] Updated: libiconv-1.13-1
The GNU libiconv package provides an iconv() implementation, for use on systems which don't have one, or whose implementation cannot convert from/to Unicode. [[ compiled using gcc-3.4.4-999 ]] This will most likely be the final libiconv update for the cygwin-1.5 distribution; future development will continue with libiconv-1.13-10 for cygwin-1.7. Changes since libiconv-1.12-1 * update to latest upstream release (see upstream release notes, below) -- Charles Wilson volunteer libiconv maintainer for cygwin To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. Upstream Release Notes for 1.13 === * The library and the iconv program now understand platform dependent aliases, for better compatibility with the platform's own iconv_open function. Examples: "646" on Solaris, "iso88591" on HP-UX, "IBM-1252" on AIX. * For stateful encodings, when the input ends with a shift sequence followed by invalid input, the iconv function now increments the input pointer past the shift sequence before returning (size_t)(-1) with errno = EILSEQ. This is also like GNU libc's iconv() behaves. * The library exports a new function iconv_open_into() that stores the conversion descriptor in pre-allocated memory, rather than allocating fresh memory for it. * Added CP1131 converter. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs -nw keypad, tpu-edt.el, and C-h
On Sat, May 30, 2009 at 2:35 PM, Andy Koppe wrote: >>>The Linux console in Opensuse actually does the same thing, and two's >>>a standard, right? ;) >> >> Actually, no. I emulated the linux console on my system. kterminal and >> xterm also makes no distinction that I can see between CTRL-Backspace >> and Backspace. > > As I said, I've seen the ^_ in the text console on Suse only. Cygwin's > xterm at least does distinguish between Backspace and Ctrl+Backspace > though: if Backspace is set to send ^H, Ctrl+Backspacce sends ^?, and > vice versa. On Debian, at least, the console sends ^H for Ctrl+Backspace and ^? for Backspace; that is a pretty common convention among terminal emulators that I've used. I vote against the ^_ suggestion; I for one would be genuinely surprised by that. ~Matt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 04:23:22PM -0400, Edward Lam wrote: >>> Ok, so where's the bug tracker so I can log a bug? >> >> Isn't this mailing list serving as bug tracker? I just hope that >> whoever can fix this is reading our emails and will come up with the >> right solution. > >Given the lack of developer acknowledgment (or refutation), I'm not >getting my hopes up. My eyes glazed over ten messages or so into this interminable thread. As astonishing as it might seem for an open source project, you could provide a fix yourself. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0-48: [BUG] Passing characters above 128 from bash command line
Edward Lam wrote: >>> Ok, so where's the bug tracker so I can log a bug? >> Isn't this mailing list serving as bug tracker? I just hope that >> whoever can fix this is reading our emails and will come up with the >> right solution. > > Given the lack of developer acknowledgment (or refutation), I'm not > getting my hopes up. Chill. The developer responsible for the unicode support has been on holiday for two weeks. She'll be back next week. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: emacs -nw keypad, tpu-edt.el, and C-h
On 5/30/2009 1:53 AM, Christopher Faylor wrote: However, I have made the change to Cygwin to translate backspace to ^?. It will be in the next snapshot. Thanks! Now C-h and Backspace work as expected when I run emacs in a Cygwin console, provided I do stty erase ^? first. Am I right in assuming that this won't be necessary once the termios default is changed as Andy suggested? I did patch the terminfo database, but that didn't do it. I don't really understand much about how terminals work. $ tput -T cygwin kbs | cat -v ^? $ stty -a | grep erase ... erase = ^H ... Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin postinstall scripts / bash [ ] syntax fails on Win 2003 x64 / Xen
Hello all, First time writing to this list, forgive me if this is redundant but I have spent many hours researching this issue and while it seems to be at least a known issue, I can't find any evidence it has been addressed. The best thing I can do is point you to this post, it is quite telling: http://markmail.org/message/owy3x7pf6oywdx5e#query:+page:1+mid:owy3x7pf6oywdx5e+state:results I am not using "KVM", but I am using Windows 2003 x64 on Xen, and I am having the same issue. Cygwin fails to run the postinstall scripts, and this leaves the environment all but unusable. It comes down to the fact that bash cannot execute the "test" or "[ x ]" syntax without throwing a segmentation fault. Running [ 1 ] at the bash prompt immediately reproduces the bug. The bash prompt can be loaded, but non of the startup scripts are executed and I just get a bash-3.2$ prompt in /usr/bin. The people who posted at the above link wrote a patch that supposedly solved the problem, but there is no way for a normal user to try this without a compiler and it doesn't appear to be in the release Cygwin code yet. I also tried the Cygwin 1.7 beta and have the same problem. I am an experienced Cygwin user of many years and dozens of solid installs. I often setup the sshd server for remote access to remote servers running Windows. This is the first time I have had these kinds of problems. Any help would be appreciated, such as news about the status of this bug, how I can find more information about the issue, or if a fix is planned for a future release. This bug also appears as if it could be viewed as a Xen bug, but I'd like to understand what your position on that actually is. Thank you, Dan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Building against Stripped DLLs
Hi, I am working on a OpenGL project in gcc, cygwin. I keep getting the error -lglu32 not found when I run make. I did a search through google/cygwin archives and found that I need to be using UNIX static library files something like .a or .dll.a instead of the.dll files I currently have. (As a note, I did install cygwin through setup.exe and I have all the devel tools installed and have updated through setup.exe) Since I do not have the source or import library files, I tried Linking against DLLs at described here: cygwin dot com slash cygwin dash ug dash net slash dll (bottom of the page). I recieved the equivalent message of [Note that this will only work if the DLL is not stripped. Otherwise you will get an error message: "No symbols in foo.dll".] for my files. So I get a .def file for the dll, but there is nothing in it, so I cannot make it a .a import library. Is there a way to turn these stripped files into .a files? Or, can I get the source code somewhere? The files I am having trouble with are -lglu32, -lglut32, -lopengl32, -lkernel32. I have the dlls in my system32 folder, but I do not have import library version. Thanks -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building against Stripped DLLs
Christina McQuirk wrote: [snip] > Is there a way to turn these stripped files into .a files? Or, can I > get the source code somewhere? The files I am having trouble with are > -lglu32, -lglut32, -lopengl32, -lkernel32. I have the dlls in my > system32 folder, but I do not have import library version. Just install w32api (using Cygwin's setup.exe or setup-1.7.exe), it has all you need (see: http://cygwin.com/cgi-bin2/package-cat.cgi?file=w32api%2Fw32api-3.13-1) Regards. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building against Stripped DLLs
René Berber wrote: > Christina McQuirk wrote: > > [snip] >> Is there a way to turn these stripped files into .a files? Or, can I >> get the source code somewhere? The files I am having trouble with are >> -lglu32, -lglut32, -lopengl32, -lkernel32. I have the dlls in my >> system32 folder, but I do not have import library version. > > Just install w32api (using Cygwin's setup.exe or setup-1.7.exe), it has > all you need (see: > http://cygwin.com/cgi-bin2/package-cat.cgi?file=w32api%2Fw32api-3.13-1) Opps! I just realized that glut32 disappeared btw. w32api-3.12-1 and w32api-3.13-1; perhaps you also need opengl-1.1.0-10 which has the dll and the static lib but not the symbols (.dll.a) lib, that's weird. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Building against Stripped DLLs
René Berber wrote: > René Berber wrote: >> Christina McQuirk wrote: >> >> [snip] >>> Is there a way to turn these stripped files into .a files? Or, can I >>> get the source code somewhere? The files I am having trouble with are >>> -lglu32, -lglut32, -lopengl32, -lkernel32. I have the dlls in my >>> system32 folder, but I do not have import library version. >> Just install w32api (using Cygwin's setup.exe or setup-1.7.exe), it has >> all you need (see: >> http://cygwin.com/cgi-bin2/package-cat.cgi?file=w32api%2Fw32api-3.13-1) > > Opps! I just realized that glut32 disappeared btw. w32api-3.12-1 and > w32api-3.13-1; perhaps you also need opengl-1.1.0-10 which has the dll > and the static lib but not the symbols (.dll.a) lib, that's weird. There seems to be some kind of problem at the moment with GL stuff specifically; see the thread "dll links or pkgconfig/libtool information is wrong", at http://cygwin.com/ml/cygwin/2009-05/threads.html#00688. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin postinstall scripts / bash [ ] syntax fails on Win 2003 x64 / Xen
On Sat, May 30, 2009 at 06:19:25PM -0500, dsp...@integrasphere.com wrote: >First time writing to this list, forgive me if this is redundant but I >have spent many hours researching this issue and while it seems to be >at least a known issue, I can't find any evidence it has been >addressed. > >The best thing I can do is point you to this post, it is quite telling: >http://markmail.org/message/owy3x7pf6oywdx5e#query:+page:1+mid:owy3x7pf6oywdx5e+state:results > >I am not using "KVM", but I am using Windows 2003 x64 on Xen, and I am >having the same issue. Cygwin fails to run the postinstall scripts, >and this leaves the environment all but unusable. It comes down to the >fact that bash cannot execute the "test" or "[ x ]" syntax without >throwing a segmentation fault. Running [ 1 ] at the bash prompt >immediately reproduces the bug. The bash prompt can be loaded, but non >of the startup scripts are executed and I just get a bash-3.2$ prompt >in /usr/bin. > >The people who posted at the above link wrote a patch that supposedly >solved the problem, but there is no way for a normal user to try this >without a compiler and it doesn't appear to be in the release Cygwin >code yet. I also tried the Cygwin 1.7 beta and have the same problem. I didn't see any Cygwin patch there. AFAICT, someone changed kvm. If there is a Cygwin patch you'll need to be more explicit. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin postinstall scripts / bash [ ] syntax fails on Win 2003 x64 / Xen
dsp...@integrasphere wrote: > The people who posted at the above link wrote a patch that supposedly > solved the problem, but there is no way for a normal user to try this > without a compiler That's ok. Normal users are allowed to have compilers just as much as abnormal ones :) cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Win2k Command Window Can't Execute G++
Hi All, I'm a noob to Cygwin and all things non-Windows. I installed Cygwin on my Win2k system (a couple of hiccups, but nothing major), then installed the GCC. When that completed, I did g++ -v in a bash window, and got the expected response. I am *sure* (99% anyway) that I was also able to do it in a normal CMD window amd get the identical response. I then proceeded to install X-Windows with no problems, and it appears to work (i.e. can bring up calc, etc). However, if I now try to invoke g++ from a CMD window I get the usual message '... not recognized as an internal or external command ...blah blah blah'. It still works in a bash window. Am I dreaming that I was able to use it in a CMD window before installing X Windows, or has something been changed during that installation? If so, what? I have done all the above while logged on as Administrator. After the initial Cygwin installation I had to manually add \Cygwin\bin and \Cygwin\usr\bin to the PATH. That hasn't been altered. It doesn't matter what directory I am in when using the CMD window, g++ isn't recognized. I would sure appreciate some help. Roger -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win2k Command Window Can't Execute G++
Roger Head wrote: Hi All, I'm a noob to Cygwin and all things non-Windows. I installed Cygwin on my Win2k system (a couple of hiccups, but nothing major), then installed the GCC. When that completed, I did g++ -v in a bash window, and got the expected response. I am *sure* (99% anyway) that I was also able to do it in a normal CMD window amd get the identical response. I then proceeded to install X-Windows with no problems, and it appears to work (i.e. can bring up calc, etc). However, if I now try to invoke g++ from a CMD window I get the usual message '... not recognized as an internal or external command ...blah blah blah'. It still works in a bash window. Am I dreaming that I was able to use it in a CMD window before installing X Windows, or has something been changed during that installation? If so, what? I have done all the above while logged on as Administrator. After the initial Cygwin installation I had to manually add \Cygwin\bin and \Cygwin\usr\bin to the PATH. That hasn't been altered. It doesn't matter what directory I am in when using the CMD window, g++ isn't recognized. I would sure appreciate some help. If you want Windows applications to be able to see Cygwin apps without adding explicit paths to the invocation, you'll need to add 'C:\cygwin\bin' or equivalent to your Windows PATH environment variable. You can do so using the "System" applet from the "Control Panel". -- 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? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Win2k Command Window Can't Execute G++
Larry Hall (Cygwin cygwin.com> writes: > > Roger Head wrote: > > Hi All, > > Cygwin installation I had to manually add \Cygwin\bin and \Cygwin\usr\bin to the PATH. That hasn't been altered. > If you want Windows applications to be able to see Cygwin apps without > adding explicit paths to the invocation, you'll need to add 'C:\cygwin\bin' > or equivalent to your Windows PATH environment variable. You can do so > using the "System" applet from the "Control Panel". > Roger Head yahoo.com> writes: Errr, yeah, thanks for the reply Larry, but as you see in my last para. I've already done that right from the start. My system is actually on L:, so my PATH has L:\Cygwin\bin and L:\Cygwin\usr\bin Roger -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
