"df ." run from C: accesses floppy drive

[Bill Priest]

All,
  I googled and didn't see anything relevant.  I'm
a long time cygwin user/fan and have noticed that
"df ." accesses a: when it doesn't need to

df --help
Usage: df [OPTION]... [FILE]...
Show information about the filesystem on which each
FILE resides,
or all filesystems by default.

/home/bpriest > df
Filesystem   1k-blocks  Used Available
Use% Mounted on
C:\cygwin\usr\X11R6\lib\X11\fonts
   9759928   9759928 0
100% /usr/X11R6/lib/X11/fonts
C:\cygwin\bin  9759928   9759928 0
100% /usr/bin
C:\cygwin\lib  9759928   9759928 0
100% /usr/lib
C:\cygwin  9759928   9759928 0
100% /
a:1423  1159   265 
82% /cygdrive/a
c: 9759928   9759928 0
100% /cygdrive/c

This accesses and displays the a: as I would expect it
to.

/home/bpriest > df .
Filesystem   1k-blocks  Used Available
Use% Mounted on
C:\cygwin  9759928   9759928 0
100% /

This accesses a: but doesn't display it; making me
believe that it didn't need to access it.

I'm sure that there is something I'm not understanding
but it isn't often that I have a floppy in my machine
and since I'm often low on disk space I check it using
"df ." and waiting for the floppy is a nuisance (I
know 
PTC) which I'll work on if warranted.

Regards,

Bill
PS.  I've reproduced this on multiple installations so
I don't believe this is an installation problem; but
I'll include the output of cygcheck anyway.

cygcheck -svr

Cygwin Win95/NT Configuration Diagnostics
Current System Time: Thu Nov 06 23:25:08 2003

Windows 2000 Professional Ver 5.0 Build 2195 Service
Pack 4

Path:   C:\cygwin\home\bpriest\usr\local\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\sbin
C:\cygwin\bin
C:\cygwin\usr\sbin
C:\cygwin\usr\X11R6\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 500(Administrator) GID: 513(None)
513(None)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 500(Administrator) GID: 513(None)
544(Administrators) 545(Users)

SysDir: C:\WINNT\system32
WinDir: C:\WINNT

CYGWIN = `binmode;tty;ntsec'
HOME = `C:\cygwin\home\bpriest'
MAKE_MODE = `unix'
PWD = `/home/bpriest'
USER = `Administrator'
path =
`/home/bpriest/usr/local/bin:/usr/local/bin:/usr/bin:/usr/bin:/sbin:/bin:/usr/sbin:/usr/X11R6/bin'

ALLUSERSPROFILE = `C:\Documents and Settings\All
Users.WINNT'
APPDATA = `C:\Documents and
Settings\Administrator.DKT.000\Application Data'
COLORFGBG = `default;default'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DKT'
COMSPEC = `C:\WINNT\system32\cmd.exe'
DISPLAY = `:0'
EDITOR = `emacs'
GROUP = `None'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and
Settings\Administrator.DKT.000'
HOST = `dkt'
HOSTTYPE = `i386'
LOGNAME = `Administrator'
LOGONSERVER = `\\DKT'
MACHTYPE = `i386'
MANPATH = `:/usr/X11R6/man:/usr/ssl/man'
NUMBER_OF_PROCESSORS = `1'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `posix'
P4PORT = `192.168.101.40:1666'
PATHEXT =
`.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PKG_CONFIG_PATH = `:/usr/X11R6/lib/pkgconfig'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping
1, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0801'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `c:\DOCUME~1\ADMINI~1.000\LOCALS~1\Temp'
TERM = `xterm'
TMP = `c:\DOCUME~1\ADMINI~1.000\LOCALS~1\Temp'
TZ = `CST6CDT5,M4.1.0/2,M10.5.0/2'
USERDOMAIN = `DKT'
USERNAME = `Administrator'
USERPROFILE = `C:\Documents and
Settings\Administrator.DKT.000'
VENDOR = `intel'
WINDIR = `C:\WINNT'
WINDOWID = `168046120'

HKEY_CURRENT_USER\Software\Cygnus Solutions
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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\Cygwin\mounts v2\/
  (default) = `C:\cygwin'
  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\mounts v2\/usr/X11R6/lib/X11/fonts
  (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\Cygwin\Program Options

a:  fd  FAT1Mb  82% CPUN   
c:  hd  NTFS9531Mb 100% CP CS UN PA FC 
d:  cd   N/AN/A

C:\cygwin

Re: cygwin patches integrating back into standard gnu

[Charles Wilson]

Charles Wilson wrote:
  1) most (upstream) maintainers want small, easily digestible patches 
-- so mega-patches must be split up into functional units.
See, for instance, this week's libtool-patches mailing list.
http://mail.gnu.org/archive/html/libtool-patches/2003-11/index.html
--
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: cygwin patches integrating back into standard gnu

[Charles Wilson]

Edward S. Peschko wrote:

I was curious - exactly what is the process to submit cygwin patches to the respective
projects that support cygwin as a target?
I've been integrating cygwin into the build for the OSes I support, and I find that there
are hundreds of thousands of lines of patches for cygwin (around 400k). Some are 
trivial, some are fairly substantial (ex: popt's patch is approx 1/3 the size of the 
regular distribution!)
Most "upstream" maintainers will accept modest patches to help support 
the cygwin platform.  By and large, the packages with huge packages are 
simply autoconf-generated stuff.

See, to build a shared lib, you really really need to use libtool-devel, 
which is libtool-1.5, and which requires automake > 1.5.0 and autoconf > 
2.50.  However, those packages are just now -- after 1.5 years -- coming 
into widespread use, because

  1) autoconf 2.5x is in some ways incompatible with autoconf-2.13 -- 
which means that an upstream package maintainer has to decide "Okay, 
everybody who hacks on my package now must install autoconf-2.5x on 
their system."  But then each developer also must make a decision -- 
"Hmm.  I can only install autoconf-2.13 OR 2.5x but not both.  These 5 
packages I like to hack on require 2.13.  Those 2 require 2.5x.  Shall I 
switch to ac-2.5x and stop hacking on the 5 old packages?"

  So that's why many (upstream) maintainers have been loathe to 'make 
the switch' -- and why some of our patches are large.  A two-line change 
to configure.in may lead to many thousands of changes in configure after 
re-autoconfing with 2.5x.

  2) Now, multiply that by automake-1.4p5 vs automake-1.7.5, and 
libtool.m4/ltmain.sh from libtool-1.5 vs. libtool.m4/ltconfig/ltmain.sh 
from libtool-1.4.3.

  3) Things are slowly getting better.  Some platforms are now finally 
providing mechanisms where both autoconf-2.13 and autoconf-2.5x can 
coexist.  (Cygwin has been doing this for years, but Red Hat et al took 
a little longer)   Plus, every week that goes by, another upstream 
maintainer "takes the plunge" -- opening the way for our patches to go 
back.  This trend is now (finally) accelerating.

I'm loathe to have to support these patches, esepcially because some seem
to be cross-platform unfriendly,
Okay.  Most (all?) of mine are cross-platform-friendly, but after all, 
cygwin maintainers are maintaining **cygwin** ports -- so you can hardly 
blame them for not doing *extra* work.

so I was hoping that some sort of concerted effort
is being made or could be made to make the ported cygwin packages 'build clean from the 
box', so that ./configure --prefix=<..>; make; make install would work for 99% of them 
without patching.
AFAIK, every cygwin maintainer has the goal of pushing patches back 
upstream.  However, some upstream maintainers are more resistant than 
others.

To that end, I've put together - attached to this message - a small perl script that 
goes off, fetches all of the latest cygwin project source code, and extracts all the 
patches and README files from the tarred packages..  It saves the source files in 
'./build', and the patches in './patches' It should run as-is under cygwin, but if it
doesn't I wouldn't mind putting together a small PAR file to make it self-contained.

Anyways, I could (or someone could) modify it so that, as an option, the patches 
within are sent to the appropriate mailing list for inclusion. I would think that such a 
matrix would be helpful in general, as well as a centralized user which could be a 
conduit for submitting patches to the right place. (which to me is a lot better idea 
than everyone using the script to send the same patch over and over) But 400k of patches 
seems just a bit high.
Oh god no.  Automated patch-spam to mailing lists?  I can't think of a 
better way to ensure that our patches are rejected.

The Right Way To Do This is for each (cygwin) maintainer to handle it -- 
after all, they are the most informed on the subject.  Plus, in many 
cases you don't WANT to send all 400k of patches:

  1) most (upstream) maintainers want small, easily digestible patches 
-- so mega-patches must be split up into functional units.

  2) the autotool-generated portion of each patch shouldn't go back; 
only the changes to the source files (configure.in, Makefile.am) with 
the note that "This assumes you reautoconf with autoconf-2.5x or higher, 
re-automake with automake-1.7.5 or higher, re-libtoolize with 
libtool-1.5 or higher." etc.

A dumb patch-spammer is NOT the way to go, here.

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

cygwin patches integrating back into standard gnu

[Edward S. Peschko]

I was curious - exactly what is the process to submit cygwin patches to the respective
projects that support cygwin as a target?

I've been integrating cygwin into the build for the OSes I support, and I find that 
there
are hundreds of thousands of lines of patches for cygwin (around 400k). Some are 
trivial, some are fairly substantial (ex: popt's patch is approx 1/3 the size of the 
regular distribution!)

I'm loathe to have to support these patches, esepcially because some seem
to be cross-platform unfriendly, so I was hoping that some sort of concerted effort
is being made or could be made to make the ported cygwin packages 'build clean from 
the 
box', so that ./configure --prefix=<..>; make; make install would work for 99% of them 
without patching.

To that end, I've put together - attached to this message - a small perl script that 
goes off, fetches all of the latest cygwin project source code, and extracts all the 
patches and README files from the tarred packages..  It saves the source files in 
'./build', and the patches in './patches' It should run as-is under cygwin, but if it
doesn't I wouldn't mind putting together a small PAR file to make it self-contained.

Anyways, I could (or someone could) modify it so that, as an option, the patches 
within are sent to the appropriate mailing list for inclusion. I would think that such 
a 
matrix would be helpful in general, as well as a centralized user which could be a 
conduit for submitting patches to the right place. (which to me is a lot better idea 
than everyone using the script to send the same patch over and over) But 400k of 
patches 
seems just a bit high.

Ed

 extract_cygwin_patches.p 
use strict;
use File::Path;
use FileHandle;
use Data::Dumper;

mkdir("build");  
system("rm -rf patches");
mkdir("patches");

chdir("build");

my $cygwin_entries = cache_cygwin();
my $cygwin_projects  = cygwin_projects( $cygwin_entries);

my $project;
foreach $project (@$cygwin_projects)
{
  print STDERR "\n\nGETTING PROJECT :$project:\n\n";
  my $latest_project = get_latest_project($project, $cygwin_entries);

  my ($shortpath) = ($latest_project =~ m"(?:.*)/(.*)"sg);

  system("rm -f $shortpath") if (-e $shortpath);

  ftp("ftp://planetmirror.com/pub/cygwin/$latest_project";) if (!-e $shortpath);
  extract_patch($latest_project, $project );
}

cleanup();

sub cleanup
{
  chdir("../patches");

  my $file;
  foreach $file (glob("*"))
  {
if ( $file !~ m"\.patch$" && $file !~ m"README") #" 
{
  system("rm -f $file") if (-e $file);
}
  }
}

chdir("..");
# -- start subs ---
sub shell
{
  my $fh = new FileHandle($_[0]);
  my $line = <$fh>;
  close($fh);

  return(1) if ($line =~ m"^#!" || $line =~ m"#.*shell");
  return(0);
}

sub cache_cygwin
{
  if (-e "ls-lR.gz") { system("rm ls-lR.gz"); }
  ftp('ftp://planetmirror.com/pub/cygwin/ls-lR.gz');

  my $cygwin = _ls_lr("ls-lR");
  my @return = grep(m"release" && m"-src" && m"\.tar\.gz|\.tar\.bz2", @$cygwin);
  return([EMAIL PROTECTED]);
}

sub cygwin_projects
{
  my ($entries) = @_;
  my %MATCH;

  grep { m"^./release(/[^/]+/)" && $MATCH{$1}++ }  @$entries; 
  my @projects = sort keys(%MATCH);
  return([EMAIL PROTECTED]);
}

sub get_latest_project
{
  my ($project, $cygwin_projects) = @_;

  my @releases = grep(m"$project", @$cygwin_projects);
  @releases = sort { _cygwin_tuple($b, $a) } @releases;

  return($releases[0]);
}

sub extract_patch
{
  my ($latest_project, $project) = @_;

  $project =~ s"/""sg;

  my ($shortpath) = ($latest_project =~ m".*/(.*)");
  my $filenames = tar($shortpath, { list => 1 });
  my @patches_or_hints = grep(m"(?:patch|cygwin)"i, @$filenames); #"
  @patches_or_hints = grep(!m"\.c$", @patches_or_hints); #"

  if (@patches_or_hints)
  {
tar($shortpath, { extract => 1, filenames => [EMAIL PROTECTED], 
  outflat => "../patches/${project}_",
  outfull => 0 });
  }
  else
  {
print STDERR "Package $shortpath does not have any patches!!\n";
  }
}

sub tar
{
  my ($shortpath, $config) = @_;

  if ($config->{list})
  {
my @files = ($shortpath =~ m"\.bz2$")? `/bin/tar tjf $shortpath` :  #"
($shortpath =~ m"\.tar.gz$")? `/bin/tar tzf $shortpath` :  #"
  ($shortpath =~ m"\.tar$")? `/bin/tar tf $shortpath` :
  `/bin/tar tf $shortpath`; #"
chomp(@files);
return([EMAIL PROTECTED]);
  }
  elsif ($config->{extract})
  {
my $flags = 
  ($shortpath =~ m"\.bz2$")? "xjf" :  #"
  ($shortpath =~ m"\.tar.gz$")? "tzf" : #"
  ($shortpath =~ m"\.tar$")? "tf" : "tf"; #"

my @filenames = ($config->{filenames})? @{$config->{filenames}} : ();

if ($config->{filenames} && [EMAIL PROTECTED]>{filenames}})
{
  print STDERR "you asked not to extract any files from $shortpath!Skipping.\n";
}

if ($config->{outflat})
{
  mkdir("tmpdir.$$");
  chdir("tmpdir.$$");

  system("/bin/tar $flags ../$shortpath @filenames");
  @filenames = grep( -

setup cannot proceed to do the installation...

[Jason Fu]

Dear gurus,

I normally separate the normal user a/c and the admin a/c in my Server 2k3. I 
use the normal user a/c doing the downloading of various CYGWIN packages and 
then I use the admin a/c (here the admin is called root like UNIX) to do the 
installation. Recently I find the installation cannot proceed after MD5 
checking. I tried several times to remove /var/log/setup.log* and it continued 
to finish the installation. But this morning, the installation could not 
continue again and I removed the /var/log/setup.log* but this time it didn't 
work anymore.

Anybody has any idea of what's going on?

Thanks!


Jason

http://www.hkucs.org:8080/~tsfu/


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

[Lucifer]

- Original Message - 
From: "Paul-Kenji Cahier" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 07, 2003 1:38 AM
Subject: terms


> Hello all,
> 
> I've been trying to make other terminals than rxvt work without the X
> server but without success yet... The problem of the rxvt that comes
> with cygwin is that as the original rxvt it doesnt support special
> charsets, and hence cant display correctly japanese characters, or
> chinese characters, or russian, etc. The alternative under linux would
> be to use either mlterm or rxvt-beta, mlterm being particularly useful
> as it allows multiple encoding in a same term.

I am using Simplified Chinese version of win2k and I put the following lines in my 
~/.Xdefaults:
[code]
rxvt*font: fixedsys
rxvt*boldFont: fixedsys
rxvt*mfont: fixedsys
rxvt*multibyte_cursor:True
rxvt*multichar_encoding:big5
[/code]
then the rxvt windows shipped with cygwin can display Chinese characters correctly 
(just as notepad.exe).

However, if I change the rxvt*multichar_encoding line to gb, it cannot display correct 
gb2312 characters.  It is confusing...



[snip]

Re: Multiple Cygwins/ Distributing Cygwin apps

[John Moore]

I now have a procedure that works on my system for allowing more than 
one cygwin to exist on the same Windows instance at the same time (but 
not to execute at the same time). I thank several on this list and who 
replied privately for help. For my needs, this solves the problem that 
started the thread. Perhaps it can help others.

I have put the full discussion here at 
http://www.tinyvital.com/techblog/archives/000330.html#more.

Also, part of it follows below (minus the nice HTML formatting):

--

NOTE: This will not allow both Cygwin environments to operate at the 
same time, but it will allow one to switch back and forth without 
rebooting the Windows OS. I am running this on Windows2000, but it 
should work on any modern Windows OS.

If you follow this procedure and have problems, please DO NOT BOTHER the 
Cygwin maintainers, as they will NOT answer your questions. Multiple 
Cygwins are outside of their current charter.

The approach is based on the following known or suspected cygwin 
characteristics:

...cygwin conflicts occur if cygwin discovers that there are more than 
one cygwin1.dll's on your machine

...Cygwin keeps its file system mount point information in the registry.

...It appears to discover duplicate cygwins if the "wrong" dll is in the 
Windows DLL path, if the "wrong" one is pointed to by a mount point, or 
if there is a cygwin shared memory segment (always present when a cygwin 
app is running). I am not sure this is exactly right, but it is 
consistent with my observations. In any case, the following procedure 
does work for me.

.

First, perform the following steps [Standard warning. I am not 
responsible if this screws up your system, and if you are going to mess 
with the registry, you should know what you are doing. Read the whole 
procedure before starting.]:

...Remove the current cygwin installation if there is one (you may want 
to copy all or parts of the installation to another area).

...Make sure no keys exist in the registry named "cygwin" by deleting 
them and the appropriate parent if necessary - ("Cygnus Solutions."). It 
may not be necessary to mess with the registry, but I did. If it make 
you nervious, try without it. One alternative that may be sufficient is 
issuing the cygwin command "umount -A" - obviously before you delete 
your cygwin!

...Install cygwin in the normal fashion. In my case, against Cygwin 
recommendations, I install it in "C:/".

...Choose a directory for the switch scripts. Mine is c:/localbin - 
which is used for the rest of the example.

...Start a cygwin shell and issue the following command:"

 mount -m >c:/localbin/mount-std
This will save the mount information from the registry into a 
script.

...Edit the script so that each mount command is an absolute windows 
style path to the mount binary for the non-standard cygwin mount.exe 
that will be installed in a later step. The absolute path is necessary 
or some mount commands will fail once the root mount path is changed. 
See the example scripts below.

...Exit ALL cygwin applications (and terminate the cygipc service or 
other daemon if they are running). This will make the shared memory 
segment go away.

...Issue the following command to hide the current cygwin installation 
from the new one to be installed:

 umount -A

...Install the new cygwin, but NOT with the same cygwin root directory 
as the "standard" one. I installed mine on H:/cygwin. This may or may 
not be an option on the distributed software.

...Start a shell from the new cygwin (to make the other script):

...mount -m >c:/localbin/mount-ven

...Edit the script so that each mount command is an absolute windows 
style path to the mount binary for the standard cygwin mount.exe.

--

Now, if you are running in the non-standard cygwin environment, to 
switch to the standard environment:

...Stop all cygwin programs (including daemons) except one shell.

...In that shell, execute the mount-std script as follows (at least for 
my system):

  . c:/localbin/mount.std

...Exit from that shell

At this point you can run applications from the standard cygwn. BE 
CAREFUL not to run any applications from the other cygwin or things will 
get and stay screwed up until you end all running cygwin applications!

If you are running the the standard cygwin environment, and want to 
switch to the non-standard environment, do everything like the previous 
procedure, except invoke mount-ven. At that point, you can run anything 
from the non-standard environment ONLY (see caution above).





My mount-std script:

mount -f -s -b "M:" "/mnt/cdrom"
mount -f -s -t "c:" "/cygdrive/c"
mount -f -s -t "d:" "/cygdrive/d"
mount -f -s -t "e:" "/cygdrive/e"
mount -f -s -t "f:" "/cy

Re: advice needed: how to use mingw part of cygwin

[Christopher Faylor]

On Thu, Nov 06, 2003 at 04:39:29PM -0500, [EMAIL PROTECTED] wrote:
>I just had to do the same thing.  The way I did it is as follows:
>
>1.  in your compile line, use the flag -mno-cygwin

Yes.

>2.  include the mingw headers (/usr/include/mingw)

No. -mno-cygwin implies this.

--
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: advice needed: how to use mingw part of cygwin

[y2bismil]

Hi,

I just had to do the same thing.  The way I did it is as follows:

1.  in your compile line, use the flag -mno-cygwin
2.  include the mingw headers (/usr/include/mingw)

Then it should be okay.

Yamin

Quoting ahnkle <[EMAIL PROTECTED]>:

> 
> hi
> 
> i have been using cygwin for a far while, and have recently started 
> using gcc. i need to use _beginthread() which i can only find in the 
> mingw header process.h.
> 
> i have not used mingw at all. there doesn't seem to be anything in the 
> cygwin site docs. is it a separate compiler? do i just include the mingw 
> headers?
> 
> regards,
> ahnkle
> 
> 
> 
> --
> 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/
> 





This mail sent through www.mywaterloo.ca

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

advice needed: how to use mingw part of cygwin

[ahnkle]

hi

i have been using cygwin for a far while, and have recently started 
using gcc. i need to use _beginthread() which i can only find in the 
mingw header process.h.

i have not used mingw at all. there doesn't seem to be anything in the 
cygwin site docs. is it a separate compiler? do i just include the mingw 
headers?

regards,
ahnkle


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

ctrl-c handling problem with win32 native apps.

[Rob Getter]

I am on a team developing a windows console application, and when I run it
under a cygwin shell, the ctrl-c handling does not work properly, but it does
when run under cmd or 4nt.

What happens is that the application exits almost immediately after ctrl-c is
pressed, and the ctrl-c handler does not have time to complete, so the
application does not shutdown properly.

I have created the following program which demonstrates on my system that a
program compiled with cygwin works properly, but the same program compiled
with gcc -mno-cygwin exhibits the same behavior I described above, but works
correctly in a windows native shell.


#include 
#include 

#ifdef CYGWIN
#include 
#else
#include 
#endif

int flag = 0;

#ifndef CYGWIN
void sleep(int sec)
{
Sleep(sec*1000);
}
#endif

static void siggy(int signo)
{
if (signo == SIGINT)
{
flag = 1;
signal(SIGINT, SIG_DFL);
}
}


int main()
{
if (signal(SIGINT, siggy) == SIG_ERR)
{
printf("could not set SIGINT\n");
}

printf("polling for SIGINT...\n");
while (!flag)
{
sleep(1);
printf("waiting for SIGINT\n");
}

printf("SIGINT received\n");
printf("sleeping...\n");
sleep(5);
printf("exiting\n");
}


The #ifdef'd code is to sleep() will work the same in both executables.

Compile the program like so:

gcc testprog.c -o cygtestprog.exe
gcc -mno-cygwin testprog.c -o wintestprog.exe

cygtestprog and wintestprog behave the same under a windows shell (cmd or 4nt)
but wintestprog exits immediately under bash and zsh while cygtestprog behaves
properly.

The application actually uses SetConsoleCtrlHandler() instead of signal, but
the observed behavior is the same, so the test app demonstrates the problem
more simply.

Is this a known problem? or perhaps a problem with my setup?

Thank you for any help you can offer.


rob



--
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[2]: terms

[Brian Ford]

Please keep replies on the list.

On Thu, 6 Nov 2003, Paul-Kenji Cahier wrote:

> Okay.
> What are the needed source package i should install?
>
Well, I guess try rxvt.

> (btw mlterm supports non X i think, it has an option in configure
> to disable X, that i used)
>
Most X packages have this configure option yet few actually support it.
It is a side effect of a standard autoconf macro check for X.

Again:
> BF> Sorry, that is the extent of my knowledge on this subject.
>

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

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

[Brian Ford]

On Thu, 6 Nov 2003, Paul-Kenji Cahier wrote:

> I've been trying to make other terminals than rxvt work without the X
> server but without success yet...
>
I'm not real knowledgeable here, but that sounds pretty difficult.

> I compiled mlterm but here is the error i get when trying to start it:
> <18:28:10> [EMAIL PROTECTED]:~$ mlterm.exe
>  display  couldn't be opened.
> Unable to start - open_screen_intern() failed.
>
Can mlterm support non-X displays somehow?  If not, see below, but...

> Rxvt-beta wont even compile, it looks like it needs X to compile even
> if i force to disable it in ./configure(--disable-x):
>
I believe this is true.  Cygwin's rxvt was compiled using a severely hacked
X stub library in order to do this.  See the bottom of:

/usr/doc/Cygwin/rxvt-2.7.10.README

for details.

Sorry, that is the extent of my knowledge on this subject.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

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

terms

[Paul-Kenji Cahier]

Hello all,

I've been trying to make other terminals than rxvt work without the X
server but without success yet... The problem of the rxvt that comes
with cygwin is that as the original rxvt it doesnt support special
charsets, and hence cant display correctly japanese characters, or
chinese characters, or russian, etc. The alternative under linux would
be to use either mlterm or rxvt-beta, mlterm being particularly useful
as it allows multiple encoding in a same term.

I compiled mlterm but here is the error i get when trying to start it:
<18:28:10> [EMAIL PROTECTED]:~$ mlterm.exe
 display  couldn't be opened.
Unable to start - open_screen_intern() failed.

Rxvt-beta wont even compile, it looks like it needs X to compile even
if i force to disable it in ./configure(--disable-x):
gcc -DHAVE_CONFIG_H -g -O2 -DDEBUG_STRICT -I/usr/X11R6/include -I.. -I. -I. -c 
xdefaults.c -o xdefaults.o
xdefaults.c:281: error: `Rs_scrollBar_align' undeclared here (not in a function)
xdefaults.c:281: error: initializer element is not constant
xdefaults.c:281: error: (near initialization for `optList[61].doff')
xdefaults.c:281: error: initializer element is not constant
xdefaults.c:281: error: (near initialization for `optList[61]')
xdefaults.c:283: error: initializer element is not constant
xdefaults.c:283: error: (near initialization for `optList[62]')
xdefaults.c:290: error: initializer element is not constant
xdefaults.c:290: error: (near initialization for `optList[63]')
xdefaults.c:291: error: initializer element is not constant
xdefaults.c:291: error: (near initialization for `optList[64]')
xdefaults.c:293: error: initializer element is not constant
xdefaults.c:293: error: (near initialization for `optList[65]')
xdefaults.c:295: error: initializer element is not constant
xdefaults.c:295: error: (near initialization for `optList[66]')
xdefaults.c:296: error: initializer element is not constant
xdefaults.c:296: error: (near initialization for `optList[67]')
make[1]: *** [xdefaults.lo] Error 1



So basicaly i havent been able to make any of the two work, and i was
wondering if anyone either did it already, or could give me some
help.

 Thank you a lot,
 
 Paul-Kenji  mailto:[EMAIL PROTECTED]


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

Fltk install hangs

[Aaron Humphrey]

I am also experiencing a hang installing fltk.  (I would reply to 
http://cygwin.com/ml/cygwin/2003-11/msg00187.html,
but at work I'm only subscribed to the digest list, and it hasn't shown up yet.)

I was just doing a routine update of all packages, using the ftp.plig.net 
mirror(selected more or less at random).  It
downloaded them all fine, then started to install them.  It got as far as fltk and 
then hung on the one file,
/usr/share/doc/fltk-1.1.4/fl_color_chooser.jpg.  I waited for a few seconds, then I 
clicked Cancel.  I went back into
setup, installed the rest of the other packages(which went fine), then went back in 
and tried fltk again.  It still
didn't work.  I checked the mailing list archive on the web site, found the above 
message, then tried again and found
he was correct--the file it was hanging on grew continually while I refreshed my 
Explorer window.  It went from about
10 megabytes to 24 megabytes in less than a minute, which is an unusual size for a JPG 
in any event.

Trying to decompress the fltk-1.1.4-2.tar.bz2 file using bunzip2 produces the 
following message:


bunzip2: Compressed file ends unexpectedly;
perhaps it is corrupted?  *Possible* reason follows.
bunzip2: No error
Input file = fltk-1.1.4-2.tar.bz2, output file = fltk-1.1.4-2.tar

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

bunzip2: Deleting output file fltk-1.1.4-2.tar, if it exists.


Running bunzip2 -tvv on the file produces:


  fltk-1.1.4-2.tar.bz2: 
[1: huff+mtf rt+rld]
[2: huff+mtf rt+rld]
[3: huff+mtf rt+rld]
[4: huff+mtf rt+rld]
[5: huff+mtf rt+rld]
[6: huff+mtf file ends unexpectedly

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.


Cygcheck output attached, though I don't know if it's revelant.  Setup.log.full seemed 
to be too large to
attach, and also not that informative.


--Aaron V. Humphrey
Kakari Systems Ltd.




cygcheck.out
Description: Binary data
--
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/

Installation of fltk hung

[Jason Fu]

Please be informed that: setup hung when I tried to install fltk 1.1.4-2 after 
downloading upon flxx_chooser.jpg and the space is shrinking too.

Regards,

Jason

http://www.hkucs.org:8080/~tsfu/


--
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: Please Help: Connection closed after successful ssh connection

[Donovan, Michael]

Yes, this worked. I had to un-install everything..no big deal. 

Thanks. Very impressive!

Michael

-Original Message-
From: Brian Dessent [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2003 2:49 PM
To: Cygwin mailing list
Subject: Re: Please Help: Connection closed after successful ssh
connection


"Donovan, Michael" wrote:

> I've been scouring the internet for a resolution to this problem and 
> have yet to find how this was solved. I've been working on this for a 
> week, and I'm not any closer to solving it. Thanks in advance for 
> taking your time to help solve my problem.
> 
> I have setup a password less  ssh connection to a Windows 2003 Server 
> using the SYSTEM account with privilege separation.
> 
> Here is an output from ssh -v localhost:

I think under Windows 2003 you need to create a special account under
which to run sshd, not SYSTEM.  Try Corinna's ssh-host-config script
that she has been asking people to try out and test, it should take care
of creating this user, giving it the proper tokens, and removing its
ability to log on (for security), etc.  See also: 


Brian


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


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