Re: Updated: guile-1.8.7

[Mark Harig]

On Tue, Nov 23, 2010 at 09:06:44PM -0500, Mark Harig wrote:

On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote:
> I've updated the version of Guile to 1.8.7.  This also includes the
> guile-devel packages.
>
> This is a new upstream release.  For a full update of changes, see
> the file usr/share/doc/guile/NEWS in the guile-doc package.
>
> Cygwin-specific changes
>
>   * New upstream release.
>   * Add int scm_i_terminating export, thanks Yaakov.
>   * Move to gub3: http://lilypond.org/gub .
>
>
> ==
>

I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7,
along with cygwin 1.7.7:

$ cygcheck -c cygwin guile guile-doc libguile17
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.7-1OK
guile1.8.7-1OK
guile-doc1.8.7-1OK
libguile17   1.8.7-1OK

I have previously been able to install and start guile 1.8.2 without
error, but when I attempt to start guile 1.8.7, it fails immediately
with a Stack overflow error:



1. Here is a check of the other packages that guile requires at 
run-time:


$ cygcheck -c crypt gmp libltdl3
Cygwin Package Information
Package  VersionStatus
crypt1.1-1  OK
gmp  4.3.1-3OK
libltdl3 1.5.27a-1  OK

$ cygcheck -c libintl2 libintl3 libintl8
Cygwin Package Information
Package  VersionStatus
libintl2 0.12.1-3   OK
libintl3 0.14.5-1   OK
libintl8 0.17-11OK


2. Another problem is that guile-doc 1.8.7, unlike guile-doc 1.8.2,
does not include the 'info' documentation files:

$ cygcheck -l guile-doc
/usr/share/doc/guile/GUILE-VERSION
/usr/share/doc/guile/LIBGUILEREADLINE-VERSION
/usr/share/doc/guile/PROGRAM
/usr/share/doc/guile/ChangeLog-2008
/usr/share/doc/guile/NEWS
/usr/share/doc/guile/LICENSE
/usr/share/doc/guile/ChangeLog
/usr/share/doc/guile/ChangeLog-gh
/usr/share/doc/guile/COPYING.LESSER
/usr/share/doc/guile/THANKS
/usr/share/doc/guile/ChangeLog-2000
/usr/share/doc/guile/README
/usr/share/doc/guile/AUTHORS
/usr/share/doc/guile/HACKING
/usr/share/doc/guile/ChangeLog-scm
/usr/share/doc/guile/INSTALL
/usr/share/doc/guile/ABOUT-NLS
/usr/share/doc/guile/ChangeLog-1996-1999
/usr/share/doc/guile/ChangeLog-threads

--
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: Updated: guile-1.8.7

[Mark Harig]

On Mon, Nov 22, 2010 at 11:10:39AM +0100, Jan Nieuwenhuizen wrote:
> I've updated the version of Guile to 1.8.7.  This also includes the
> guile-devel packages.
>
> This is a new upstream release.  For a full update of changes, see
> the file usr/share/doc/guile/NEWS in the guile-doc package.
>
> Cygwin-specific changes
>
>   * New upstream release.
>   * Add int scm_i_terminating export, thanks Yaakov.
>   * Move to gub3: http://lilypond.org/gub .
>
>
> ==
>

I have installed guile 1.8.7, guile-doc 1.8.7, and libguile17 1.8.7,
along with cygwin 1.7.7:

$ cygcheck -c cygwin guile guile-doc libguile17
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.7-1OK
guile1.8.7-1OK
guile-doc1.8.7-1OK
libguile17   1.8.7-1OK

I have previously been able to install and start guile 1.8.2 without
error, but when I attempt to start guile 1.8.7, it fails immediately
with a Stack overflow error:

$ guile -q --debug --
Backtrace:
In unknown file:
   ?: 129* [#]
   ?: 130* (let* ((file #)) (cond (# => #) (# => #)))
   ?: 131  [#
   "/usr/share/guile/1.8/ice-9/debug.scm"]
   ?: 132  [with-fluid* # #f #]
   ?: 133* [#]
   ?: 134* [load-file # ...]
   ?: 135* [save-module-excursion #]
   ?: 136  (let (# #) (dynamic-wind # thunk #))
   ?: 137  [dynamic-wind # #
   #]
   ?: 138* [#]
   ?: 139* [primitive-load "/usr/share/guile/1.8/ice-9/debug.scm"]
In /usr/share/guile/1.8/ice-9/debug.scm:
  22: 140* (define-module (ice-9 debug) :export ...)
In unknown file:
   ?: 141* [copy-tree ...
   ?: 142* [apply # (# :export #)]
   ?: 143  [# (ice-9 debug) :export ...]
   ?: 144  (quasiquote (eval-case (# #) (else #)))
   ?: 145* [compile-define-module-args (# :export #)]
   ?: 146  ((letrec ((loop #)) loop) (quasiquote ((quote #))) (cdr
   args))
   ?: 147* (letrec ((loop (lambda # #))) loop)
   ?: 148* (lambda (compiled-args args) (cond (# #) (# #) (# #) ...))

: In expression (lambda (compiled-args args) (cond # #
...)):
: Stack overflow

--- End of stack dump ---

This error is repeatable (the same error messages with the same line
numbers).  The same error occurs if guile is provided no command-line
options.

I can un-install version 1.8.7, install version 1.8.2, and start guile
without error.

Please let me know if there is some information that I can provide
that would help to diagnose the source of this problem.

Here are sha1sums of the files that I have downloaded and installed:

$ sha1sum.exe guile-1.8.7-1.tar.bz2
ee5cdc729998bfd7c8aa93c9e53467d28c77153b *guile-1.8.7-1.tar.bz2
$ sha1sum.exe libguile17-1.8.7-1.tar.bz2
cb35fa72ad8fe46a27abfc2bd3d38f731cb127e5 *libguile17-1.8.7-1.tar.bz2
$ sha1sum.exe guile-doc-1.8.7-1.tar.bz2
2e42accc2103f7ee83808b91319bf43611004a36 *guile-doc-1.8.7-1.tar.bz2
$ sha1sum cygwin-1.7.7-1.tar.bz2
61d32c981e6aa1d19b8586d1f9f6c19d87b06bf2 *cygwin-1.7.7-1.tar.bz2

--
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

cygwin-1.7/clisp-2.48-1: Cannot initialize clisp with full linking set

[Mark Harig]

Thank you for providing clisp version 2.48.

I am unable to start clisp if I specify the full linking set:

$ clisp -Kfull
/usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: 
svm.dll: cannot open shared object file: No such file or directory


$ cygcheck -l clisp | grep svm.dll
/usr/lib/clisp-2.48/full/svm.dll

$ file /usr/lib/clisp-2.48/full/svm.dll
/usr/lib/clisp-2.48/full/svm.dll: PE32 executable for MS Windows (DLL) 
(console) Intel 80386 32-bit


$ md5sum /usr/lib/clisp-2.48/full/svm.dll
3f0dfd94d955bfb567581c853ed32587 */usr/lib/clisp-2.48/full/svm.dll

$ cygcheck -c clisp
Cygwin Package Information
Package  VersionStatus
clisp2.48-1 OK


/usr/lib/clisp-2.48/full/svm.dll was installed with the executable 
permission turned off.  Turning on the executable permission had no effect:


$ chmod +x /usr/lib/clisp-2.48/full/svm.dll

$ ls -l /usr/lib/clisp-2.48/full/svm.dll
-rwxr-xr-x 1 username root 99K Aug  1 16:02 
/usr/lib/clisp-2.48/full/svm.dll*


$ clisp -Kfull
/usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: 
svm.dll: cannot open shared object file: No such file or directory


Also, the following (possibly related?) problem exists:

$ cd /usr/lib/clisp-2.48/full
$ clisp -Kfull
/usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries: 
cygdb-4.6.dll: cannot open shared object file: No such file or directory



There is no version cygdb-4.6.dll installed, and, as far as I can tell, 
there is no version cygdb-4.6.dll available yet.



If the base linking set is specified, then clisp starts and exits 
without error:


$ clisp -Kbase -q
[1]> (exit)
$


Can anyone suggest any troubleshooting steps to take to resolve this 
problem,
or are these problems above caused by errors in the Cygwin packaging of 
clisp?



--
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: Questions about setting the CYGWIN env. variable's 'error_start'

[Mark Harig]

Thanks for the reminder.  Here is the documentation for the 
'error_start' option:


  http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

or,

  http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html

|error_start:Win32filepath| - if set, runs |Win32filepath| when 
cygwin encounters a fatal error, which is useful for debugging. 
|Win32filepath| is usually set to the path to *gdb* or *dumper*, for 
example |C:\cygwin\bin\gdb.exe|. There is no default set. 


Is there a canonical or recommended, robust method that should be used
for setting 'error_start'?  It appears that your method assumes the value
of PATH is set appropriately.  Is it recommended that users define the
environment variable 'Win32filepath' to have the value of the Windows
location of the desired debugger and, if so, can this be changed 
dynamically?
(That is, if a user changes 'Win32filepath' at, say, a shell prompt, 
would this

be picked up by 'error_start'?)  And has the new 'insight' GUI included
with 'gdb' been tested to work as a value for 'error_start'?




To follow up, the behavior of Cygwin (bash?) is different depending on 
whether
cygwin 1.5 or cygwin 1.7 is used.  The environment variable 
'Win32filepath' is
null for some reason in Cygwin 1.5 (the value has been set via the 
Environment

Variables applet in the Control Panel's System applet).

1. Cygwin 1.5:
   bash --norc --noprofile

   bash-3.2$ echo $CYGWIN
   tty error_start:Win32filepath

   bash-3.2$ echo $Win32filepath
   [no value printed]

   bash-3.2$ /bin/cygcheck -c bash cygwin
   Cygwin Package Information
   Package  Version   Status
   bash3.2.49-22OK
   cygwin1.5.25-15   OK


2. Cygwin 1.7:
   bash --norc --noprofile

   bash-3.2$ echo $CYGWIN
   tty error_start:Win32filepath

   bash-3.2$ echo $Win32filepath
   c:\cygwin-1.7\bin\gdb.exe

   bash-3.2$ /bin/cygcheck -c bash cygwin
   Cygwin Package Information
   Package  Version   Status
   bash3.2.49-23OK
   cygwin1.7.0-50  OK



--
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

Questions about setting the CYGWIN env. variable's 'error_start'

[Mark Harig]

Mon, 6 Jul 2009 11:21:14 -0400 ,  Christopher Faylor wrote:

For the curious, I debugged it by doing this:

set CYWGIN=error_start:gdb

When gdb popped up, the stack trace led me straight to the problem.
  



Thanks for the reminder.  Here is the documentation for the 
'error_start' option:


  http://cygwin.com/cygwin-ug-net/using-cygwinenv.html

or,

  http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html

|error_start:Win32filepath| - if set, runs |Win32filepath| when cygwin 
encounters a fatal error, which is useful for debugging. 
|Win32filepath| is usually set to the path to *gdb* or *dumper*, for 
example |C:\cygwin\bin\gdb.exe|. There is no default set. 


Is there a canonical or recommended, robust method that should be used
for setting 'error_start'?  It appears that your method assumes the value
of PATH is set appropriately.  Is it recommended that users define the
environment variable 'Win32filepath' to have the value of the Windows
location of the desired debugger and, if so, can this be changed 
dynamically?
(That is, if a user changes 'Win32filepath' at, say, a shell prompt, 
would this

be picked up by 'error_start'?)  And has the new 'insight' GUI included
with 'gdb' been tested to work as a value for 'error_start'?


--
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: Stuck trying to reinstall Emacs 23.0.92 and setup dying each time

[Mark Harig]

Wed, 1 Jul 2009 15:37:09 -0700 David Karr wrote:

Ok, so that shows that emacs-el.lst.gz was corrupted.  I deleted it,
then reran setup. I clicked "Exp", then "View", then scrolled down to
the three "emacs*" lines and set them all to "Reinstall" (the "Current"
column says "23.0.92-2") and clicked "Next".  It chugged for a bit, last
displaying "Uninstalling emacs-el", then reported "setup.exe has
encountered ...".  After dismissing the dialog, I looked at /etc/setup
again, and the corrupted "emacs-el.lst.gz" was there again.  I also
checked to see whether any other "*.lst.gz" files were corrupted, and
there were none.
  


This message might be of some help to you:

http://sourceware.org/ml/cygwin/2008-06/msg00563.html

In particular, you could try downloading:

http://rapidshare.com/files/98717404/setup.exe

Perhaps one of the setup.exe experts could remark on
the advisability of trying this.  I used it with success
once in the past when my cygwin 1.5 installation became
corrupted.


--
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: Stuck trying to reinstall Emacs 23.0.92 and setup dying each time

[Mark Harig]

KARR, DAVID wrote:


I had set up Cygwin yesterday with the experimental Emacs 23.0.92.  I
had done other updates after that, forgetting the fact that since I'm
using an experimental package, I have to set the Emacs-related pages to
"Keep".  I'm now in a state where I have the 23.0.92 executable, but
with /usr/share/emacs/21.2.  So, now I'm trying to run setup again to
reinstall 23.0.92, or uninstall it, or anything.  No matter what I do,
setup dies hard, requiring a forced kill from task manager.

What can I do to clean up from this situation?
  

Have you inspected the 'setup.log' and 'setup.log.full' files in /var/log/?
They might provide some clues about where setup is having problems.  If 
those

files do not make it clear what you need to do, then the experts on 'setup'
might be able to help with the information those files provide.

Also, which version of emacs does cygwin think is installed?

  $ cygcheck -c emacs emacs-el


--
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: Problem with displaying ASCII table in mintty

[Mark Harig]

Fri, 26 Jun 2009 10:50:45 -0400 Mark J. Reed wrote:


> Is is possible to display the upper 128 entries in the ASCII
> table in mintty using the 'cygutils' application 'ascii'?

The ASCII table doesn't have an upper 128 entries.  Only codes 0
through 127 decimal are defined by ASCII.  Once you hit 128 you're not
in ASCII anymore, and what you *are* in depends entirely on what code
page you're using.

128 through 159 are control characters in Unicode and Latin-1, but
printable characters in Windows 1252.  160 through 255 are the same in
Windows 1252, Latin-1, and Unicode, but defined differently in the
other ISO-8859 and ISO-2022 character sets and Windows code pages.

If you're using UTF-8 (a particular way of representing Unicode
characters, which are defined as numbers, as concrete bits and bytes),
then only characters 0 through 127 can be expressed in one byte.
Characters from 128 to 2047 take two bytes; the rest of the BMP (2048
through 65536)  three bytes per character, and the rest of Unicode
four bytes per character.

So if you just send the byte with decimal value 128, not preceded by
the start of a UTF-8 sequence, to a UTF-8 terminal, the terminal will
reject it as invalid, or display gobbledygook, depending on its error
handling design.


Thank you for the explanation.  I see from the manual page for 'ascii'
provided at http://www.kernel.org/pub/linux/docs/manpages/ that the
ASCII table is as you described (that is, 128 entries only).  Do you have
any recommendations about what the utility program /usr/bin/ascii
(in the package 'cygutils') should do?  Should it not provide a display
of the values above 128 because they are not part of the ASCII table?
Does it make sense to provide options that handle the values above 128
under the various conditions described above?


--
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: Problem with displaying ASCII table in mintty

[Mark Harig]

>
> With this configuration, the upper 128 entries to the ASCII
> table are displayed as follows (the #'s are replacements for
> the gray box character that is displayed):

That's because because bytes from 0x80 to 0xFF by themselves are
invalid in UTF-8. Those codepoints need to be encoded as two-byte
sequences. I'd suspect /bin/ascii isn't designed for that.


OK.  From what you have written, it appears that the defect
is in /usr/bin/ascii (cygutils) in that it does not support UTF-8.
Either that will need to be fixed or the documentation for
the tool could list/describe the problem so that other users
are told that it is known.


> In addition,
> many entries are displayed in the wrong location (some rows are out
> of order).

That's because some of the C1 control characters are interpreted
specially, in particular CSI and OSC. It's the same if you try it in
xterm.

You can get most of the printable characters in the C1 range by
switching to Windows codepage 1252. (Well, you could anyway if it
wasn't for a rather bad bug in mintty-0.4.0 and 0.4.1 that means that
ISO-8859-1 is used no matter your codepage setting. That's fixed on
the 0.4 SVN branch.)


OK.  Users can display the upper 128 entries in 'rxvt' so there is
a work-around in a Cygwin environment.  (In 'rxvt', LC_CTYPE
should not be set to UTF-8.  AFAIK, UTF-8 is not supported
in cygwin's rxvt.)



--
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

Problem with displaying ASCII table in mintty

[Mark Harig]

Is is possible to display the upper 128 entries in the ASCII
table in mintty using the 'cygutils' application 'ascii'?

Package versions:

bash-3.2$ /usr/bin/cygcheck -c bash cygutils cygwin mintty
Cygwin Package Information
Package  VersionStatus
bash 3.2.49-22  OK
cygutils 1.4.0-1OK
cygwin   1.7.0-50   OK
mintty   0.4.1-1OK

bash-3.2$ /usr/bin/ascii --version
/usr/bin/ascii is part of cygutils version 1.4.0
 Prints nicely formatted table of the ascii character set


I have attempted to use two configurations, but neither one
displays the table without problems in mintty:

Configuration 1:

   - mintty: Using the font's codepage set to UTF-8

 bash-3.2$ /usr/bin/grep Codepage ~/.minttyrc
 Codepage=UTF-8

   - bash:
 bash-3.2$ echo $TERM
 xterm

bash-3.2$ echo \"$LANG\" ":" \"$LC_ALL\" ":" \"$LC_CTYPE\"
 "en_US.UTF-8" : "en_US.UTF-8" : "en_US.UTF-8"

  With this configuration, the upper 128 entries to the ASCII
  table are displayed as follows (the #'s are replacements for
  the gray box character that is displayed):

  bash-3.2$ /usr/bin/ascii
  128  0x80  #160  0xa0  #192  0xc0  #224  0xe0  #
  ...
  159  0x9f  #191  0xbf  #223  0xdf  # 255  0xff  #

Configuration 2:

   - mintty: Using the font's codepage set to ISO-8859-1

 bash-3.2$ /usr/bin/grep -i codepage ~/.minttyrc
 Codepage=ISO-8859-1:1998 (Latin-1, West Europe)

  - bash:

bash-3.2$ echo \"$LANG\" ":" \"$LC_ALL\" ":" \"$LC_CTYPE\"
"en_US.ISO-8859-1" : "en_US.ISO-8859-1" : "en_US.ISO-8859-1"

  With this second configuration, most of the upper 128 entries
  of the ASCII table are displayed, but many are missing.  In addition,
  many entries are displayed in the wrong location (some rows are out
  of order).

Note: I had mintty start bash with the '--norc' and '--noprofile' options.


--
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: Problem with mintty-0.4.1-1 and orpie

[Mark Harig]

Thu, 25 Jun 2009 20:25:09 +0100 Andy Kope wrote:


>
> There is no documented way in mintty to change the TERM environment before
> the shell is started.

There's a bit in the TIPS section of the manual on how to set any
environment variable using the shell's -c option, e.g.:

mintty sh -c "TERM=xterm-256color emacs"
  


OK.  When I wrote my comments, I had been thinking about
the shell (which ever one the user chooses) itself and had
not thought of using 'sh -c' on it.  The following works:

   mintty sh -c "FOO=baz  /bin/bash --norc --noprofile"


bash-3.2$ echo $FOO
baz

However, with this approach there is this side effect
that users should probably be aware of:

bash-3.2$ echo $SHLVL
2


From the 0.4.0 release announcement:

- MinTTY now has its own identity, instead of pretending to be an old
xterm. The ^E answerback string is "mintty", the ^[[c primary device
attribute command reports a vt100, and the ^[[>c secondary DA command
reports terminal type 77 (ASCII 'M') and version 400. The TERM
variable remains set to "xterm" though, to avoid termcap/terminfo trouble
  


I could not find this description in the manual page for mintty
or in /usr/share/doc/Cygwin/mintty-0.4.1.README.  I assume
that you will add this information to the documentation when
you want users to be able to make use of it.


--
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: Problem with mintty-0.4.1-1 and orpie

[Mark Harig]

> (TERM=xterm by default for me. I have no idea where that comes from.)

This is documented in the manual page for 'mintty':


TERM variable
The TERM variable for the child process is set to "xterm", so that pro‐
grams that pay attention to it expect xterm keycodes and output xterm‐
compatible control sequences.



There is no documented way in mintty to change the TERM environment before
the shell is started. It may turn out to be necessary (some day?) for 
mintty to

provide some method for the shell to know whether it is running in a mintty
terminal or an xterm terminal.



--
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

Cygwin 1.7 setup-1.7.exe minor display error

[Mark Harig]

Steps to reproduce the error:

1. Start setup-1.7.exe.  Click on 'Next >' button until the
   'Select Packages' dialog window is displayed.

2. By default, setup displays the Select Packages window
   maximized.  Click on the 'Restore Down' button in the
   right-hand corner to reduce the size of the window.

3. Note that to the right of the 'Search' box, the 'Clear' button
   is not displayed (or, displayed only partially), as follows:

  Search |_|[ o Keep  o Prev  o Curr o Exp [View] Category

   It should be displayed as follows:

  Search |_|[Clear] o Keep  o Prev  o Curr o Exp [View] 
Category




Maximizing and restoring the window does not fix the display problem.
I have restarted setup-1.7.exe several times (more than three) to confirm
that the problem can be reproduced.


--
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: Some questions about mintty

[Mark Harig]

> At the bash shell prompt while editing commands is one example, but
> it is also the case for me in text editors, vim or emacs, for example.
> From the Options menu, I set the cursor type to block and set the
> cursor color to a light color, say, yellow, and then moved the block
> cursor back over the text of a command at the shell prompt.
> Because the cursor-text color remained white, when it combined
> with the light block color, the text inside the cursor block
> "disappeared."

Could you attach your .minttyrc? Have you got any commands in your
bash startup files that might be relevant here? And what's you PS1
setting?


To simplify the problem, I eliminated the ~/.bashrc & ~/.bash_profile
initialization files:

  $ mintty -e /bin/bash --norc --noprofile

Please find attached a simplified ~/.minttyrc file.  I renamed my "old" 
file,

started mintty, set the color options for foreground, background, and
cursor, set the cursor type to 'block' and then accepted these
changes to generate a new ~/.minttyrc file.

PS1 is:

[~]$ echo $PS1
[\W]\$

The behavior with the block cursor's text remains: The text is light inside
the light block, making the character difficult to read.  Using the solution
that you provided (echoing an escape sequence to set the cursor text
color) fixes the problem.

Columns=80
Rows=36
Transparency=0
OpaqueWhenFocused=1
Scrollbar=1
ScrollbackLines=1
ConfirmExit=1
WindowShortcuts=1
EditShortcuts=1
ZoomShortcuts=1
BoldAsBright=0
AllowBlinking=0
CursorType=0
CursorBlinks=0
FontIsBold=0
FontHeight=14
FontCharset=0
FontQuality=1
BackspaceSendsDEL=1
EscapeSendsFS=0
AltSendsESC=0
ScrollMod=1
RightClickAction=0
CopyOnSelect=1
ClicksPlaceCursor=0
ClicksTargetApp=1
ClickTargetMod=1
BellType=1
BellIndication=2
Font=Lucida Sans Typewriter
Codepage=UTF-8
Printer=
ForegroundColour=0,0,0
BackgroundColour=255,255,255
CursorColour=255,255,0

--
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: Some questions about mintty

[Mark Harig]

> 3. When the color of the cursor is changed to a block, the text
> � can be read through the block, but it appears that the text is
> � always white.

The background colour is used for text beneath the cursor, so if the
cursor is visible infront of the background, the text beneath the
cursor should be visible too. With the default white-on-black colours,
you get black text inside a white cursor block.

Is it a particular mode or program where you're seeing this problem?


At the bash shell prompt while editing commands is one example, but
it is also the case for me in text editors, vim or emacs, for example.
From the Options menu, I set the cursor type to block and set the
cursor color to a light color, say, yellow, and then moved the block
cursor back over the text of a command at the shell prompt.
Because the cursor-text color remained white, when it combined
with the light block color, the text inside the cursor block
"disappeared."



> �Can the cursor's (reverse) text color be changed?

Yes, through the xterm sequence for setting colours, where in a small
extension the default colours are represented as colours 256 through
261:

256 - normal foreground
257 - bold foreground
258 - normal background
259 - bold background
260 - cursor background
261 - cursor foreground

For example, this sets the cursor background colour (which is used for
the text beneath it) to black:

echo -e "\e]4;260;#00\a"


Thank you. That works. I have added the following to ~/.bashrc:

case "$TERM" in
...
xterm)
if [ "$OS" = Windows_NT ]; then
# Set mintty's (block) cursor text color to black
echo -e "\e]4;260;#00\a"
...
else
...
fi
...
esac


--
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

Some questions about mintty

[Mark Harig]

My installed packages:

$ cygcheck -c cygwin mintty
Cygwin Package Information
Package  VersionStatus
cygwin   1.7.0-50   OK
mintty   0.4.1-1OK

1. There is no description of the '-e' switch in mintty's manual page.
   Is it an "execute-this-command" option?  Or, should the user be
   aware that it is specific to "execute this shell"?

2. There is a '-p / --position' option described in the manual page.
   Is there a corresponding option for the ~/.minttyrc initialization
   file?  (If so, I could not find a description of it in the manual
   page for mintty or /usr/share/doc/Cygwin/mintty-0.4.1.README.)

3. When the color of the cursor is changed to a block, the text
   can be read through the block, but it appears that the text is
   always white.  Can the cursor's (reverse) text color be changed?
   If a light color is chosen for the cursor block, then the white
   text within the block is difficult to read.  The behavior of xterm
   in X is that the cursor text is inverted, that is, it is dark if the
   cursor block is light, and light if the cursor block is dark.

4. Is is possible to view italic fonts (in italicized form) in mintty?
   I selected  Italic and Bold Italic entries from the 'Font Style'
   list, but could not get mintty to accept/acknowledge those
   selections.

Thanks to the author(s) of mintty for providing it.


--
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 1.7: Possible error in /etc/postinstall/base-files-profile.sh

[Mark Harig]

Dave Korn wrote:

  However, now you've got rid of that, a quick re-run through setup.exe and
set everything to reinstall on the chooser page should fix it.

  


setup-1.7.exe is running pretty reliably now that I have stopped (but not
removed) these two services via the Services app:

  LVCOMSer (Logitech Video COM Service)
  LVSvrLauncher (Launcher for Logitech Video Components)


But I continue to see the following type of error (cut from a
terminal session that occurred moments ago) when running
various cygwin programs:

$ man emacs
 5 [main] sh 7444 C:\cygwin-1.7\bin\sh.exe: *** fatal error - 
couldn't allocate heap, Win32 error 487, base 0x6D, top 0x73, 
reserve_size 389120, allocsize 393216, page_const 4096
 5 [main] sh 8212 C:\cygwin-1.7\bin\sh.exe: *** fatal error - 
couldn't allocate heap, Win32 error 487, base 0x6D, top 0x73, 
reserve_size 389120, allocsize 393216, page_const 4096
 3 [main] sh 9104 child_info::sync: wait failed, pid 7444, Win32 
error 0
   136 [main] sh 9104 fork: child -1 - died waiting for longjmp before 
initialization, retry 0, exit code 0x100, errno 11
40 [main] sh 9036 child_info::sync: wait failed, pid 8212, Win32 
error 0
   179 [main] sh 9036 fork: child -1 - died waiting for longjmp before 
initialization, retry 0, exit code 0x100, errno 11


(FWIW, the 'max_memory.exe' program reports that over 1500 Mbytes are 
available.)


Is there a general troubleshooting approach that can be
recommended to cygwin users that can isolate defects
in cygwin applications from defects that are caused by
interaction with other ms-windows applications?  For
example, if windows is booted to "Safe Mode" or
"Safe Mode with Networking", can errors be reliably
attributed to cygwin defects, and not to inter-application
problems?


--
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

Cygwin 1.7: Dependency errors in Emacs installation

[Mark Harig]

During the post-installation of emacs 23.0.92-10, the following error
messages are written to /var/log/setup.log.full:


Visited: 68 nodes out of 1460 while creating dependency order.

Dependency order of packages: base-cygwin base-passwd cygwin libiconv2 
libintl8 alternatives alternatives libgmp3 libintl3 texinfo 
_update-info-dir gawk tzcode coreutils terminfo0 libncurses8 
libreadline6 bash ash libaspell15 aspell aspell-doc aspell-en findutils 
sed base-files libbz2_1 bzip2 libpopt0 cygutils groff gzip terminfo 
libncurses9 less man cygwin-doc libintl2 diffutils editrights 
xemacs-emacs-common emacs emacs-el libexpat1 libexpat1-devel expat 
gcc4-runtime libgcc1 libpcre0 grep ipc-utils libdb4.2 libgdbm4 libproj0 
login openssl tcltk zlib0 zlib-devel zlib python Numeric rebase run rxvt 
tar termcap which


2009/06/21 11:19:21 running: C:\cygwin-1.7\bin\bash.exe --norc 
--noprofile -c /etc/postinstall/emacs.sh
/etc/postinstall/emacs.sh: line 9: /usr/bin/update-desktop-database: No 
such file or directory
/etc/postinstall/emacs.sh: line 10: /usr/bin/update-mime-database: No 
such file or directory




--
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 1.7: Possible error in /etc/postinstall/base-files-profile.sh

[Mark Harig]

Dave Korn wrote:

> 
> Is this problem with the Logitech Process Monitor service

> described in the Cygwin documentation?

  http://cygwin.com/faq/faq.using.html#faq.using.bloda
  



Thanks again for the additional information.  I will be working
my way through the entire FAQ at that link.



  http://cygwin.com/acronyms#BLODA
  


From that link:

FYI For Your Information. Also "Fix Yourself It" (for all the Star 
Wars fans out there)


Perhaps, DIY (Do It Yourself) could be added.  My
guess is that it is more commonly used and
understood than "fix yourself it."



I am not yet using cygwin 1.7.  I am trying to install it (and
un-install it) as I think a naive user might.  I read the following
two links that were provided with the announcement for
cygwin-1.7.0-50:


We have a new User's Guide for 1.7, which is currently located at
http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html

  


and


And we have a new FAQ, though very likely not quite complete since
we still don't know what exactly *is* a FAQ related to Cygwin 1.7.
http://cygwin.com/1.7/faq/faq.html

  


I see that at http://cygwin.com/1.7/faq/faq.setup.html, item 8 references
the link that you provided under the heading "My computer hangs when
I run Cygwin Setup!"   My computer is not "hanging" -- it is just issuing
error messages during install/un-install using setup-1.7.exe.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh

[Mark Harig]

That having been said...rxvt is stealing a march by assuming
/etc/X11/app-defaults/ exists.  It's not clear -- if all the other
packages did it the "rxvt way" -- WHO exactly should be responsible for
creating the directory.

  



1. 'rxvt' is advertised as being available without X, so
it cannot depend on X installation actions, can it?

2. What are packages' responsibilities are with respect
   to 'setup.exe'?  Naive users should be able to install
   the base set of packages without any errors appearing
   in /var/log/setup.log*, correct?  And they should be
   able immediately upon successfully installing the base
   set of packages, be able to un-install that set of packages
   without any errors appearing in /var/log/setup.log, I
   would expect.

3. If each of the packages was during installation to adopt the
   responsibility of:

- Checking for every directory it needs
- If the directory (tree) does not exist, create it
- Populating the directories with the files it uses

   and then during un-installation, un-do what it did
   during installation:

   - Remove any (non-modified configuration) files
   - Remove any directory (trees) that it created
 during installation (using
 'rmdir --ignore-fail-on-non-empty')

then 'setup.exe' ought to be able to install/uninstall
reproducibly without errors.


I'll enhance the rxvt postinstall script to handle that in a future release.
  


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

Re: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh

[Mark Harig]

> Potential app conflicts:
> 
> Logitech Process Monitor service

> Detected: HKLM Registry Key, Named process.

  You definitely need to stop and disable that service.  It borks cygwin
something rotten.
  

Thank you.  I will try that (anything to give my cygwin
processes better behavior than they have now).

Is this problem with the Logitech Process Monitor service
described in the Cygwin documentation?


--
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

Cygwin 1.7: Possible error in /etc/postinstall/rxvt.sh

[Mark Harig]

After running setup-1.7.exe to install the package 'rxvt',
I found the following error in /var/log/setup.log.full:

2009/06/20 16:00:17 running: C:\cygwin-1.7\bin\bash.exe --norc 
--noprofile -c /etc/postinstall/rxvt.sh
Using the default version of /etc/X11/app-defaults/Rxvt 
(/etc/defaults/etc/X11/app-defaults/Rxvt)
/bin/touch: cannot touch `/etc/X11/app-defaults/Rxvt': No such file or 
directory
/bin/cp: cannot create regular file `/etc/X11/app-defaults/Rxvt': No 
such file or directory

The directory tree needed by the configuration file 'Rxvt' is missing.

$ ls -l /etc/X11/app-defaults
ls: cannot access /etc/X11/app-defaults: No such file or directory

$ ls -l /etc/X11
ls: cannot access /etc/X11: No such file or directory

Is the 'rxvt' package responsible for creating these
missing directories?


--
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

Cygwin 1.7: Uninstalling all (base) packages using setup-1.7.exe

[Mark Harig]

After installing all default, base packages in Cygwin,
I attempted to uninstall this base set by clicking on the
"cycle" button/icon of the 'All' category (while the setup
view for packages was set to 'Category') until 'Uninstall'
was displayed for 'All' and for all sub-categories.

When I clicked the 'Next' button, setup displays a window
with the following text:


Warning! Unmet Dependencies Found
   The following packages are required but have not been selected.



Package: bash
Required by: _update-info-dir

Package: cygwin
Required by: gcc4-runtime, libproj0, Numeric, _update-info-dir

Package: python
Required by: Numeric

Package: texinfo
Required by: _update-info-dir


Should not 'setup' be uninstalling '_update-info-dir' and the other
packages listed?

When I removed the check from the check-box labeled:



"Install these packages to meet dependencies (RECOMMENDED)"



and click the 'Next' button, the following warning message is displayed:


WARNING - Required Packages Not Selected

If you continue without correcting the listed conflicts, your Cygwin
installation will not function properly.  We strongly recommend
that you let Setup install the listed packages.

Are you sure you want to proceed?


After clicking on 'Yes', setup runs to completion and includes the
text "Installation Status: Uninstalls complete."



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin 1.7: Possible error in /etc/postinstall/base-files-profile.sh

[Mark Harig]

'dirname' is /usr/bin/dirname.  Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'?  If not,
then this would account for the error.

It is possible to rewrite the command without using
'dirname':

/bin/mkdir -p ${fDest%/*}

$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3

$ cygcheck -c base-files-3.8
Cygwin Package Information
Package  VersionStatus
base-files   3.8-3  OK


It does set the path.  This is one of those cases where we really do
need to see the cygcheck output:


Included below (as an attachment) is the file generated by:

  $ cygcheck -s -v -r > cygcheck.out



Cygwin Configuration Diagnostics
Current System Time: Sat Jun 20 13:01:52 2009

Windows XP Media Center Edition Ver 5.1 Build 2600 Service Pack 3

Path:   C:\cygwin-1.7\usr\local\bin
C:\cygwin-1.7\bin
C:\cygwin-1.7\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem

Output from C:\cygwin-1.7\bin\id.exe (nontsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users)  513(None)

Output from C:\cygwin-1.7\bin\id.exe (ntsec)
UID: 1007(a_user) GID: 513(None)
0(root) 544(Administrators) 545(Users)  513(None)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

PWD = '/etc/postinstall'
CYGWIN = 'tty'
HOME = '/home/a_user'

HOMEPATH = '\Documents and Settings\a_user'
APPDATA = 'C:\Documents and Settings\a_user\Application Data'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
WINDIR = 'C:\WINDOWS'
WINDOWID = '8096040'
OLDPWD = '/etc'
USERDOMAIN = 'AHOSTNAME'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\Documents and Settings\All Users'
!:: = '::\'
TEMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
LIB = 'C:\Program Files\Common Files\GTK\2.0\bin'
QTJAVA = 'C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
USERNAME = 'a_user'
PROCESSOR_LEVEL = '6'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
__COMPAT_LAYER = 'EnableNXShowUI '
USERPROFILE = 'C:\Documents and Settings\a_user'
LOGONSERVER = '\\AHOSTNAME'
PROCESSOR_ARCHITECTURE = 'x86'
SHLVL = '1'
COLORFGBG = '0;default;15'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\WINDOWS\system32\cmd.exe'
TMP = '/c/DOCUME~1/a_user/LOCALS~1/Temp'
SYSTEMROOT = 'C:\WINDOWS'
PROCESSOR_REVISION = '0f06'
CLASSPATH = '.;C:\Program Files\Java\jre1.5.0_02\lib\ext\QTJava.zip'
PROGRAMFILES = 'C:\Program Files'
DISPLAY = ':0'
NUMBER_OF_PROCESSORS = '2'
SESSIONNAME = 'Console'
COMPUTERNAME = 'AHOSTNAME'
COLORTERM = 'rxvt-xpm'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygwin\setup
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start
 Menu2\Programs\Cygwin
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/'
  cygdrive flags = 0x002a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'C:\cygwin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/desktop
  (default) = 'c:\Documents and Settings\a_user\Desktop'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'C:\cygwin/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'C:\cygwin/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin-1.7'

obcaseinsensitive set to 1

c:  hd  NTFS 55623Mb  72% CP CS UN PA FC 
d:  hd  FAT32 6991Mb  49% CPUN   RECOVERY
e:  cd N/AN/A

C:\cygwin-1.7   / system  binary,auto
c:\Documents and Settings\a_user\Desktop  /desktop  system  binary
C:\cygwin-1.7\bin   /usr/bin  system  binary,auto
C:\cygwin-1.7\lib   /usr/lib  system  binary,auto
cygdrive prefix / user
binary,posix=0,auto

Found: C:\cygwin-1.7\bin\awk.exe
Found: C:\cygwin-1.7\bin\awk.exe
 -> C:\cygwin-1.7\bin\gawk.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cp.exe
Found: C:\cygwin-1.7\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\WINDOWS\system32\find.exe

Cygwin 1.7: Possible file permission errors in 'base-files'

[Mark Harig]

The two files 'base-files-mketc.sh' and 'base-files-profiles.sh' included
in the 'base-files' package have their permissions set to 644 while all
other scripts in /etc/postinstall/ have their permissions set to 755.

Is this a side-effect of 'base-files-profiles.sh' not completing without
errors, or is this set in the packaging?

(Technically, the files with the permission problems are
/etc/postinstall/base-files-mketc.sh.done and
/etc/postinstall/base-files-profiles.sh.done.)


--
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 1.7: Possible error in /etc/postinstall/base-files-profile.sh

[Mark Harig]

When I ran setup-1.7.exe with the default set of packages
selected, the following error message was displayed:

running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c 
/etc/postinstall/base-files-profile.sh

abnormal exit: exit code=-1073741819

'base-files-profile.sh' contains the following line:

/bin/mkdir -p `dirname ${fDest}`

'dirname' is /usr/bin/dirname.  Does setup-1.7.exe set
PATH before running 'base-files-profile.sh'?  If not,
then this would account for the error.

It is possible to rewrite the command without using
'dirname':

/bin/mkdir -p ${fDest%/*}

$ cygcheck -f /etc/postinstall/base-files-profile.sh
base-files-3.8-3

$ cygcheck -c base-files-3.8
Cygwin Package Information
Package  VersionStatus
base-files   3.8-3  OK



--
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/

Some files are missing from cygwin-doc version 1.5-1

[Mark Harig]

setup-1.7.exe installs the package 'cygwin-doc', version 1.5-1.

This package includes /usr/share/info/cygwin.info.  cygwin.info
references two files, 'cygwin-ug-net.info' and 'cygwin-api.info',
which are not included in 'cygwin-doc':

$ cygcheck -c cygwin-doc
Cygwin Package Information
Package Version  Status
cygwin-doc1.5-1  OK

$ cygcheck -l cygwin-doc | grep /usr/share/info/cygwin
/usr/share/info/cygwin.info




--
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: cygwin-1.7.0-50

[Mark Harig]

While running setup-1.7.exe (with no arguments) from a cygwin 1.5 bash
shell prompt, the following (error?) messages were displayed:

io_stream_cygfile: fopen(/etc/setup/installed.db) failed 2 No such file 
or directory
io_stream_cygfile: fopen(/etc/setup/last-cache) failed 2 No such file or 
directory
io_stream_cygfile: fopen(/etc/setup/timestamp) failed 2 No such file or 
directory
io_stream_cygfile: fopen(/etc/setup/mirrors-lst) failed 2 No such file 
or directory


Are these messages expected?  Can they be safely ignored?
Are they documented somewhere for cygwin users?

I was not able to find a mention of them at
http://cygwin.com/1.7/faq/faq.setup.html or
http://cygwin.com/1.7/cygwin-ug-net/setup-net.html

Also, during the installation of the (default set of) packages, the 
following

error message was displayed:

running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c 
/etc/postinstall/base-files-profile.sh

abnormal exit: exit code=-1073741819

I confirmed that all directories and files that 
/etc/postinstall/base-files-profiles.sh

creates or installs exist.

I re-ran setup-1.7.exe a second time (with no additional packages selected)
and found that none of the above messages were displayed.


--
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: Using emacs in a terminal window

[Mark Harig]

> I'd say it's a bug that the rxvt max_colors entry is 8, since rxvt
> does support 256 colours in its default setting. (And I notice it's
> the same with xterm.) Don't know whether there are compatibility
> concerns that require that.

Just to be clear, the default terminfo capability for Cygwin rxvt
is rxvt-cygwin-native, and that is what I used for comparison.
There is no corresponding 'rxvt-cygwin-256color'.

> However, the correct way to address this is to set TERM to
> rxvt-256color (or xterm-256color, as appropriate) rather than
> Eterm-256color.

That sounds reasonable and appears to be a really good
suggestion (even if there is no 'rxvt-cygwin-256color').

I tried it and found that it appears to give a
color/font/underlining capability identical to Eterm-256color,
but it fixes a defect in Eterm-256color, namely, the mode
line was not being shaded appropriately depending on which
window in the frame was active.  Using TERM=rxvt-256color,
the mode-line highlighting now follows the active window,
as expected.  This appears to be the best default TERM
setting for terminal-mode Emacs running in Cygwin (native)
rxvt.

  env TERM=rxvt-256color emacs -nw ...

Thank you for the suggestion!

I will leave it to regular mintty+Emacs users to suggest
the best default TERM setting for that terminal emulator.

---


--
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: Using emacs in a terminal window

[Mark Harig]

> Yes, but nevertheless the TERM setting needs to fit the terminal that
> Emacs is actually running in, so "rxvt" (or some variation thereof)
> for rxvt and "xterm" for xterm or mintty. As Ken said, the "Eterm"
> setting is intended for programs that run inside emacs' builtin
> terminal. Using "Eterm*" outside that might appear to work because
> many of its capabilities will be the same as with other terminals, but
> there will also be things that don't fit.


Let's consider the case of the Cygwin Bash Shell (which runs the batch
file 'cygwin.bat').  In this case, we do not want to set TERM (which
defaults to 'cygwin') to 'Eterm-256color'.  If we do, then terminal-mode
emacs will attempt to use capabilities that Cygwin bash running inside
cmd.exe does not support.  So, the general principal of not exceeding
the capabilities of the terminal that the application is running in is
correct.

Similarly, if we were running Emacs in a physical terminal, then we
would need to be careful to tell Emacs about the correct set of
control strings to send to the terminal.  Of course, we are not
generally, with Cygwin, running Emacs on a physical terminal
so we do not have the restrictions of, say, a VT100.

Leaving aside the very limited Cygwin Bash Shell and physical
terminals, do the Cygwin terminal emulators have some capabilities
that 'Eterm-256color' restricts, or, conversely, does 'Eterm-256color'
attempt to use some capability that the terminal emulators do
not support?  If so, then I would like to know what they are.

Here are some differences between the terminfo capabilities
'rxvt-cygwin-native' and 'Eterm-256color':

1. max_colors:
rxvt- max_colors: 8
Eterm - max_colors: 256

We do not want to limit Emacs to 8 colors, and having
Eterm-256color set the value to 256 does not cause
any problem for rxvt.

2. auto_left_margin:
rxvt-  False
Eterm - True

So, when you reach the left margin in rxvt, it will not
automatically wrap back to the previous line.  In Eterm,
you will.  Does it matter for Emacs?  No.

3. key_f0 / key_help:
rxvt-  key_f0: \E[21~,  key_help: NULL
Eterm -  key_f0: NULL, key_help: \E28~

So, rxvt defines a Function key 0, which most modern
keyboards do not have, correct?  And Eterm defines
the "Help" key, which modern keyboards do not have
(this is not the F1 key).  Neither key matters for Emacs.

4. key_a1, key_a3, key_c1, key_c3:
   These are the Home/PgUp/PgDn/End keys

rxvt - \E0w, \E0y, \E0q, \E0s
Eterm  - \E[7~, \E[5~, \E[8~, \E[6~

Does this difference in key definitions matter in
Cygwin's terminal-mode Emacs running in rxvt?

No.  A test reveals that Emacs translates the
keycodes to the same control-char sequence
regardless of whether Emacs is started with
TERM set to 'rxvt-cygwin-native' or 'Eterm-256color':

Home: ^[[7~
PgUp:  ^[[5~
PgDn:  ^[[6~
End: ^[[8~

I am attaching to this message a complete listing of
the differences between the 'rxvt-cygwin-native' and
the 'Eterm-256color' terminfo capability files.  Please
let me know if there is some critical capability that
'rxvt-cygwin-native' provides that 'Eterm-256color'
lacks, or, conversely, if 'Eterm-256color' exceeds
some capability of 'rxvt-cygwin-native' which results
in defective behavior by Emacs.  I would really like
to know.

Here are three reasons for using 'env TERM=Eterm-256color emacs...':

1. More distinct visual elements can be seen in Emacs's display.
   (I described what some of these were in a previous message.)
   The developers of Emacs have written it to make these
   elements available to provide information that would not
   be available otherwise.  In general, we want to provide
   to Emacs the maximum number of terminal capabilities
   that we can so that the code can make use of those
   capabilities instead of using a lowest-common-denominator
   capability.

2. The appearance of terminal-mode Emacs more closely matches
the default display of "native-mode, windowing" Emacs (either
MS-Windows or X-Windows).

3. There is the possibility of a more consistent display across
different terminal emulators (assuming that the terminal
   emulators will support the Eterm-256color capabilities).

We now come back to the "judgement" question: In terminal-
mode Emacs under Cygwin, would it be a better default for
it to be started with TERM set to 'Eterm-256color'?  If not,
then -- specifically -- why not?  What defects appear, that
outweigh the benefits listed above?  I would like to know
what those are.  And it would be helpful if replies were
confined to those users who actually use terminal-mode
Emacs, and who use it with the suggested TERM setting,
preferably in 'rxvt', 'mintty', or 'screen' running in one of
those terminal emulators.

---

comparing rxvt-cygwin-native to Eterm-256color.
comparing booleans.
auto_left_margin: F:T.
backspaces_with_bs: T:F.
can_change: F:T.
prtr_silent: F:T.
comparing numbers.
buttons: NULL, 5.
lines_of_memory: NULL, 0.
ma

Re: Using emacs in a terminal window

[Mark Harig]

First, note that this is not a Cygwin-specific issue. It is an
Emacs-in-a-terminal issue, so perhaps it should not be
mentioned at all in Cygwin-specific documents.  It's similar
to the "backspace" issue (or default fonts or default
colors) in rxvt -- it leads to a better default user
experience.  But that is a judgement call for an
experienced package maintainer, or a vote of
the user community.

> I tried your suggestion and couldn't see that it improved anything.

Whether you see any changes in font (bold versus non-bold),
colors, underlining, and other screen capabilities will depend
on what your terminal emulator's default TERM value is and
on what type of file you are viewing.  If terminal's default
capabilities match the capabilities in the Emacs's terminal
capability that you have selected for the types of files that
you are editing, then you may not see any difference.

One item that can be changed from what I wrote
previously is the contingency of the 'terminfo'
package.  Because that package is included in
the Base category, we should be able to assume
that it is always installed.

So, it should be possible to tell all users that
they can start Emacs as follows:

 $ env TERM=Eterm-256color emacs -nw ...

You will likely see differences if you compare
that invocation of Emacs with this one:

 $ env TERM=rxvt-cygwin-native emacs -nw ...

Some differences that I can see (in rxvt):

 1. In Info mode, the Info menu (Next, Prev, Up, etc.)
is highlighted for 'Eterm-256color', but
not for 'rxvt-cygwin-native'.

 2. The mode line is displayed highlighted
similarly to the Info menu (regardless of whether
in Info mode).

 3. The font of keywords in assorted languages
(shell-script, Emacs Lisp, C) is non-bold (easier
for me to read) in 'Eterm-256color', but is
'bold' in 'rxvt-cygwin-native'.


> My reading of the documentation is that eterm-color
> is intended to be used by emacs when it does terminal
> emulation via 'M-x term'.

No, when Emacs is run in terminal (text-only, non-X-windows)
mode, it will use whatever terminal capability is in effect,
not only in `term-mode'.  See, for example,

M-: (info "(emacs) Remote Host")


---


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Bug in $PATH initialization?

[Mark Harig]

From the bash manual (in emacs: M-: (info "(bash) Bash Startup Files")):

"When Bash is invoked as an interactive login shell, or as a
non-interactive shell with the `--login' option, it first reads and
executes commands from the file `/etc/profile', if that file exists.
After reading that file, it looks for `~/.bash_profile',
`~/.bash_login', and `~/.profile', in that order, and reads and
executes commands from the first one that exists and is readable.  The
`--noprofile' option may be used when the shell is started to inhibit
this behavior."

and

"When an interactive shell that is not a login shell is started, Bash
reads and executes commands from `~/.bashrc', if that file exists.
This may be inhibited by using the `--norc' option."

So, in the typical case, when you start bash with '-i', it sources the
following files:
 /etc/profile   # which typically contains PATH initialization
 ~/.bash_profile  # or some other "login" file, such as ~/.profile
 ~/.bash_profile will usually source ~/.bashrc (the non-login code)

To avoid having these files read, start bash with '--noprofile' (if you wish
to avoid reading /etc/profile and ~/.bash_profile) and '--norc' (if you wish
to avoid reading ~/.bashrc.  Or, simply edit /etc/profile and ~/.bashrc,
where PATH is typically set to get PATH to have the ordering that you
want.


--
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: Using emacs in a terminal window

[Mark Harig]

> I've answered several questions in recent weeks about
> how to use emacs in a terminal window.  To try to clarify
> this, I plan to put some suggestions in
> /usr/share/doc/Cygwin/emacs.README the next time I
> update the emacs packages. The current draft is appended
> below. Please let me know if you see any inaccuracies or if
> anything could be stated more clearly.

Here is an additional item related to terminal-mode Emacs that
might be worth mentioning:

   A better display of colors, underlining, etc. can be obtained
   in the terminal mode Emacs by making use of the terminfo file
   that is included in the Emacs distribution:

   /usr/share/emacs/23.0.92/etc/e/eterm-color

   This file (eterm-color) can be accessed by copying it to the
directory /usr/share/terminfo/e/ (which the user may need to
create).  The terminal capabilities are then available if
terminal-mode Emacs is invoked with some variation of:

  env TERM=Eterm-color emacs ...

If the user has the Cygwin version of the 'terminfo' package
installed, then even more terminal capabilities are available.
This package provides the files 'Eterm', 'Eterm-88color', and
'Eterm-256color' in the directory /usr/share/terminfo/45/.  To
make use of the 'Eterm-256color' terminal capabilities, for
example, issue some variation of the following commands:

$ cd /usr/share/terminfo/45/
$ ln -fs Eterm-256color Eterm-color
$ cd
$ env TERM=Eterm-color emacs ...

An alias can also be defined to help:

 $ alias edit="env TERM=Eterm-color /usr/bin/emacs-nox --no-splash"



--
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: Using emacs in a terminal window

[Mark Harig]

An alternative to providing instructions for a workaround would be to
modify the default initialization files that are provided with the terminal
emulators.

For example, rxvt comes with the following file:

 $ cygcheck -l rxvt | grep app-defaults
 /etc/defaults/etc/X11/app-defaults/Rxvt

The post-installation script of rxvt could be changed to install the 
default, system
initialization file 'Rxvt' into the directory /etc/X11/app-defaults/.  
That file could

be modified to include the following lines:

  Rxvt.backspacekey:  ^?
  Rxvt.ttyModes: erase ^?

With those changes (modifying the file and copying it into 
/etc/X11/app-defaults),
rxvt should give the behavior that is expected for the backspace key and 
the Control-H

key combination, both at the shell prompt and in terminal-mode Emacs.

Similar solutions can likely be devised for xterm and mintty, but I do not
have those packages installed.  These solutions would need to be 
incorporated
into new versions of the terminal emulator packages, which would require 
the

agreement of those package maintainers.


--
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: Updated: clisp-2.44-1 for cygwin

[Mark Harig]

Reini Urban wrote:
I've released the new upstream clisp-2.44 plus subpackages -clx, -gtk2 
and -gdi for cygwin.


Release focus:
7 - Major bugfixes

./configure --fsstnd=redhat --with-dynamic-ffi  \
  --with-module=rawsock --with-module=dirkey  \
  --with-module=bindings/win32 --with-module=berkeley-db \
  --with-module=pcre --with-module=postgresql \
  --with-module=fastcgi --with-module=zlib  \
  --with-module=gdbm --with-module=libsvm \
  --prefix=/usr --build build
(no changes)

http://clisp.cvs.sourceforge.net/*checkout*/clisp/clisp/src/NEWS

2.44 (2008-02-02)
=
User visible changes


* CLISP does not come with GNU libffcall anymore.
  This is now a separate package and should be installed separately.
  Pass --with-libffcall-prefix to the top-level configure if it is not
  installed in a standard place.
  Option --with-dynamic-ffi is now replaced with --with-ffcall.


There appears to be a contradiction between the Cygwin announcement
and the upstream clisp announcement.  The upstream announcement states
that the configuration option '--with-dynamic-ffi' has been replaced by
the option '--with-ffcall', but the Cygwin announcement states that the
no-longer-supported '--with-dynamic-ffi' configuration option was used.

Does the Cygwin announcement merely contain a typo (i.e., the new
option was, in fact, used, but not described correctly), or was the
Cygwin clisp package configured incorrectly, using the old option?
If it is the latter, then this might explain the fact that 'cygcheck' 
reports
that it cannot find 'cygfcgi-0.dll' for 
/lib/clisp-[version]/full/lisp.exe (where

[version] is either 2.43 or 2.44).



--
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: Updated: clisp-2.44-1 for cygwin

[Mark Harig]

Eric Blake wrote:


$ cygcheck /lib/clisp-2.44/full/lisp
c:\cygwin\lib/clisp-2.44/full/lisp.exe
...
Error: could not find cygpq5.dll



Was cygpq5.dll the only missing file reported?  I repeated
your command and found that cygfcgi-0.dll is also needed/missing.
(See below for the full listing of cygcheck.)

> So, what is cygpq5.dll, and has it ever been in the distribution?

It might be a typo (in the procedures that compile/link clisp).  
Possibly, 'cygpq.dll' is
needed.  It is a library included in the Cygwin package named 'libpq4'.  
Is there a

newer version 'libpq5' that has not been created for Cygwin yet?

$ cygcheck -f /usr/bin/cygpq.dll
libpq4-8.0.7-1

The Clisp documentation specifies that the full set of modules will include
a postgresql and a fastCGI module.  The DLLs that provide this support
appear to be missing.



Full listing for cygcheck of the full and base lisps.

$ cygcheck /lib/clisp-2.44/full/lisp.exe
C:\cygwin\lib/clisp-2.44/full/lisp.exe
 C:\cygwin\bin\cygcrypt-0.dll
   C:\cygwin\bin\cygwin1.dll
 C:\WINDOWS\system32\ADVAPI32.DLL
   C:\WINDOWS\system32\ntdll.dll
   C:\WINDOWS\system32\KERNEL32.dll
   C:\WINDOWS\system32\RPCRT4.dll
 C:\WINDOWS\system32\Secur32.dll
 C:\cygwin\bin\cygdb-4.3.dll
Error: could not find cygfcgi-0.dll
 C:\cygwin\bin\cyggdbm-4.dll
 C:\cygwin\bin\cygiconv-2.dll
 C:\cygwin\bin\cygintl-8.dll
 C:\cygwin\bin\cygncurses-8.dll
 C:\cygwin\bin\cygpcre-0.dll
Error: could not find cygpq5.dll
 C:\cygwin\bin\cygreadline6.dll
   C:\WINDOWS\system32\USER32.dll
 C:\WINDOWS\system32\GDI32.dll
 C:\cygwin\bin\cygz.dll
 C:\WINDOWS\system32\OLE32.dll
   C:\WINDOWS\system32\msvcrt.dll
 C:\WINDOWS\system32\OLEAUT32.DLL
Error: could not find cygfcgi-0.dll
Error: could not find cygfcgi-0.dll
Error: could not find cygfcgi-0.dll
Error: could not find cygfcgi-0.dll
Error: could not find cygfcgi-0.dll

By contrast, /lib/clisp-2.44/base/lisp.exe is not missing
any libraries:

$ cygcheck /lib/clisp-2.44/base/lisp.exe
C:\cygwin\lib/clisp-2.44/base/lisp.exe
 C:\cygwin\bin\cygcrypt-0.dll
   C:\cygwin\bin\cygwin1.dll
 C:\WINDOWS\system32\ADVAPI32.DLL
   C:\WINDOWS\system32\ntdll.dll
   C:\WINDOWS\system32\KERNEL32.dll
   C:\WINDOWS\system32\RPCRT4.dll
 C:\WINDOWS\system32\Secur32.dll
 C:\cygwin\bin\cygiconv-2.dll
 C:\cygwin\bin\cygintl-8.dll
 C:\cygwin\bin\cygncurses-8.dll
 C:\cygwin\bin\cygreadline6.dll
   C:\WINDOWS\system32\USER32.dll
 C:\WINDOWS\system32\GDI32.dll
 C:\WINDOWS\system32\OLE32.dll
   C:\WINDOWS\system32\msvcrt.dll
 C:\WINDOWS\system32\OLEAUT32.DLL


--
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: Updated: clisp-2.44-1 for cygwin

[Mark Harig]

Larry Hall wrote:


Sounds like it could be a missing dependency problem.  Does 'cygcheck clisp'
report any missing DLLs?



No, it doesn't report any missing DLLs.  Both versions 2.43-2 and 2.44-1 
have the following report

from cygcheck:

$ cygcheck clisp
Found: C:\cygwin\bin\clisp.exe
C:\cygwin\bin\clisp.exe
 C:\cygwin\bin\cygwin1.dll
   C:\WINDOWS\system32\ADVAPI32.DLL
 C:\WINDOWS\system32\ntdll.dll
 C:\WINDOWS\system32\KERNEL32.dll
 C:\WINDOWS\system32\RPCRT4.dll
   C:\WINDOWS\system32\Secur32.dll


--
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: Updated: clisp-2.44-1 for cygwin

[Mark Harig]

Reini Urban wrote:
I've released the new upstream clisp-2.44 plus subpackages -clx, -gtk2 
and -gdi for cygwin.


Thank you for updating clisp to the latest version.  I am seeing a 
reproducible
error when I attempt to use it.  Error code 53 is returned when the '-K 
full'

option is supplied to clisp:

 $ /usr/bin/clisp -norc -q -K full || echo $?
 53

 $ cygcheck -c cygwin clisp ffcall
 Cygwin Package Information
 Package  VersionStatus
 clisp2.44-1 OK
 cygwin   1.5.25-7   OK
 ffcall   1.10-1 OK


I attempted to eliminate this problem by reverting to the previous
version of clisp, 2.43-2, but the same error number was returned.

No such error is returned for the base set of modules for either version
2.43-2 or 2.44-1:

 $ /usr/bin/clisp -q -norc -K base || echo $?
 [1]>_

Please let me know if there is some more environmental information that
I can provide to help resolve this problem.


--
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: Updated: xemacs-21.4.21-1/xemacs-tags-21.4.21-1/xemacs-emacs-common-21.4.21-1

[Mark Harig]

Dr. Volker Zell wrote:

Hi

A new version of `xemacs' has been uploaded to a server near you.

  
xemacs-emacs-common appears to have had xemacs added as a pre-requisite 
package.
This dependency should be removed so that emacs users can continue to 
install the
shared package without requiring xemacs (and the requisite X windows 
packages).


I would also like to suggest that the xemacs-emacs prefix be renamed to the
commonly-used plural for emacs, that is, emacsen.


--
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] New package: scsh-0.6.7-2

[Mark Harig]

Christopher Faylor wrote:


1. This package is classified in 'setup' as a 'Misc' package.  Should
  this package be classified as a 'Shell' package instead?


It is in the category "Interpreters" under Debian so I've put it there
for Cygwin as well.


Note that some packages are in multiple categories.  clisp, for example,
is in the Interpreters and Shells categories.  And the editors Emacs and
Xemacs are in the Interpreters and Editors categories.  scsh likely belongs
in both the Interpreters and Shells categories.  Many people will look for
the "Scheme shell" in the Shells category.



--
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] New package: scsh-0.6.7-2

[Mark Harig]

Reini Urban writes:

> scsh - the "scheme shell" - has been added to the cygwin distribution.

Thank you for providing this package.

1. This package is classified in 'setup' as a 'Misc' package.  Should
  this package be classified as a 'Shell' package instead?

2. The manual page 'scsh.1.gz' in /usr/share/man/man1 has only 27 bytes
  in it.  The manual page, 'scsh.man', included in the source for
  'scsh' has 1982 bytes.  Is there a defect in the scsh cygwin package
  (i.e., did the manual page get package incorrectly), or is this
  a problem with my cygwin installation?




--
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] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3

[Mark Harig]

Angelo Graziosi wrote:


(As I discussed some time on this list and others, I use GCC-4.0.4 to
build Emacs: with 3.4.4 the result is highly unstable (at least for me),
but this does not seem the case of 21-3)


OK.  It does not appear that gcc 4.x will be available for Cygwin soon,
according to the discussion that started with this message in May 2007:

   http://cygwin.com/ml/cygwin/2007-05/msg00184.html

If you discover a repeatable set of steps that you can follow that will
cause Emacs to crash, would you please post those to this list?  They
could be used as a test to tell whether Emacs has been built correctly.
In addition, your steps might be tested with Emacs on another platform
(most commonly, a UNIX-like system) to determine whether the problem is
specific to the Cygwin implementation of Emacs.

My guess is that the problem that you are seeing cannot be resolved
easily.  Here are three approaches that might be taken, none of which
is trivial:

1. Identify the C code in the Emacs 22 source that needs to be
  "back-ported" to gcc 3.4.4 so that the problem you are seeing
  does not occur.  A patch could then be applied to Emacs 22 so
  that it could run error free on Cygwin.

2. Make gcc 4.0.4 available for Cygwin.  Get it tested and past
  the experimental stage.

3. Wait until gcc 4.2.x (or a later gcc 4.4, etc.) has been ported
  to Cygwin.

---



--
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 takes 100% CPU

[Mark Harig]

> I switched to the emacs 22.1 available through cygwin, and it seems 
fine. I also started cygserver (adding the environment variable).

>
> Is the xemacs-emacs-common package required for emacs 22.1 ?
>

It can be, depending on whether you need to use the 'b2m' or 
'rcs-checkin' programs
that are normally included in emacs distributions.  Because xemacs also 
includes these
two programs, there was a conflict if someone attempted to install both 
the emacs
and xemacs packages.  (In many other distributions, conflicts like this 
have been
resolved by creating packages with names such as 'emacsen-common'.)  In 
addition,
if you write programs in Emacs Lisp and want to use Emacs's tag feature, 
then
you will need to install the 'ctags' package also because Emacs's 
'etags' program

is not being included in the Cygwin Emacs package.

These requirements were listed in the announcement and in the Cygwin README
for Emacs.

---


--
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] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3

[Mark Harig]

Angelo Graziosi wrote:


Provide a detailed list of the steps that you took
to create your emacs binaries.


They are very simple and standard (from the build script):


   LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \
   ../configure --prefix=${prefix_dir} || return 1

   make LD='$(CC)' || return 1


These are (essentially) the same steps that are used in
the .cygport for creating the Cygwin version of Emacs.

Would you please do the following?

$ make distclean
$ LDFLAGS='-Wl,--enable-auto-import -Wl,--enable-auto-image-base' \
 ../configure --prefix=${prefix_dir} > configure.log 2>&1
$ bzip2 configure.log

and then include configure.log.bz2 as an attachment to an email
message to this mailing list.  This might provide enough information
to find out what is missing from the environment that is used to
build Emacs via cygport.

---




--
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] [test-version] emacs-22.1-3/emacs-el-22.1-3/emacs-X11-22.1-3

[Mark Harig]

Angelo Graziosi:


Ken Brown wrote:


Emacs-22.1-3 aborts with a core dump when I try to compile a large latex
document


I observe a similar behaviour with a document of about 43 page.

The same thing happens using 'M-x compile' with a my application that
gives about 2000 line of link errors: emacs simply dies!


The problem doesn't occur with my cited build of emacs 22.1.


The following information might be helpful in investigating
this problem:

1. Provide a detailed list of the steps (Emacs commands)
   that you are running to reproduce the problem.  This
   should include a document file that is input into 
   Emacs, preferably included as an attachment to your

   message, and compressed using bzip2 or gzip.

2. Provide a detailed list of the steps that you took
   to create your emacs binaries.  This should include
   a copy of the output of 'configure' (again, included
   as a compressed text file attached to your message).
   Unfortunately, the Emacs documentation is opaque
   about what environment must be available during the
   configuration stage.

I, for one, will look at this information if you provide
it to help investigate what is causing the problem.  Others
might find it useful, too.  Once a solution has been found
it should be possible to include the proper steps in the
cygport for Emacs so that it can be used going forward with
later releases of Emacs.

---



--
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: After Cygwin and XEmacs upgrade, read-only files aren't detected

[Mark Harig]

On Sun, 2002-11-03 at 03:16, David M. Karr wrote:
> >>>>> "Mark" == Mark Harig <[EMAIL PROTECTED]> writes:
> 
> Mark> With the most recent version of Cygwin, 1.3.14, CYGWIN has been set to 
> Mark> 'ntsec' by default.  Unfortunately, this doesn't show up in the output 
> Mark> of 'cygcheck -s -r -v'.  
> 
> Ok, I guess that's the change that has created this symptom.
> 
> Mark> You might want to consider running the Microsoft 'convert' utility on 
> Mark> your disk to convert your filesystem from FAT32 to NTFS. 
> 
> The filesystem on my disk is already NTFS.  Is there something in the cygcheck
> output that indicates it's fat32?
> 

Nothing in cygcheck (that I know of).

If you're using NTFS, and changing CYGWIN=ntsec (the default) to
CYGWIN=nontsec solves a problem with file permissions, then there
is something else going on. Normally, if the filesystem on your disk(s)
is NTFS then you want CYGWIN=ntsec in order to get the UNIX-like
file permissions.

> -- 
> ===
> David M. Karr  ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: After Cygwin and XEmacs upgrade, read-only files aren't detected

[Mark Harig]

With the most recent version of Cygwin, 1.3.14, CYGWIN has been set to 
'ntsec' by default.  Unfortunately, this doesn't show up in the output 
of 'cygcheck -s -r -v'.  

You might want to consider running the Microsoft 'convert' utility on 
your disk to convert your filesystem from FAT32 to NTFS. 

On Sat, 2002-11-02 at 23:16, David M. Karr wrote:
> > "David" == David M Karr <[EMAIL PROTECTED]> writes:
> 
> David> Last night I upgraded my Cygwin and Cygwin/XEmacs installations to the 
>latest.
> David> Today, I noticed that XEmacs can no longer notice that read-only files are
> David> read-only.  Normally, it detects that, and sets the buffer to be 
>read-only.
> 
> David> I did report this to the XEmacs group, but they're not aware of any recent
> David> changes that could be related to this.
> 
> David> Is there some recent Cygwin feature change that could be causing this?
> 
> I discovered that if I change my CYGWIN variable from "tty" to "tty nontsec"
> this now behaves as I would expect, showing a read-only buffer for a read-only
> file.
> 
> Before discovering this, I also noticed that if a file only had the "read" bits
> on, then XEmacs would see it was read-only.  However, if the file had both the
> read AND execute bits on (still not having any write bits), then XEmacs would
> think it was writable.
> 
> Testing the same situation with "vi" showed a read-only buffer, both before and
> after changing the CYGWIN variable.
> 
> -- 
> ===
> David M. Karr  ; Java/J2EE/XML/Unix/C++
> [EMAIL PROTECTED]
> 
> 
> --
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting: http://cygwin.com/bugs.html
> Documentation: http://cygwin.com/docs.html
> FAQ:   http://cygwin.com/faq/
> 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: After Cygwin and XEmacs upgrade, read-only files aren't detected

[Mark Harig]

Please provide that output of 'cygcheck -s -r -v' *as an attachment*,
as described in .  If it is is not included
as an attachment, then these mailing-list archives are made much less
useful because many more false matches are listed during a search.

On Sat, 2002-11-02 at 02:46, David M. Karr wrote:
> Last night I upgraded my Cygwin and Cygwin/XEmacs installations to the latest.
> Today, I noticed that XEmacs can no longer notice that read-only files are
> read-only.  Normally, it detects that, and sets the buffer to be read-only.
> 
> I did report this to the XEmacs group, but they're not aware of any recent
> changes that could be related to this.
> 
> Is there some recent Cygwin feature change that could be causing this?
> 



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/