Re: Downloading problems - either won't D/L at all or truncates over 1MB

[soren_andersen]

On 10 Jan 2002 at 10:06, Robert Collins wrote:

> Ah, magic word.. firewall. 

> > I've had problems like this before that I got around by D/L'ing to a faster
> > site (my ISP on the backbone) and then D/L'ing from there to my
> > dialup PC.
> > The amount of data that I need to do this with this time would make it a
> > hassle to do for this situation, but I will if I can't resolve it any other way.

> If you've had problems like this before, take a clue: Your environment
> is broken. Before I got ADSL I routinely downloaded 20-30Mb files on a
> 33.6 modem.

I am not behind a firewall but have also had various problems similar to some of 
those reported by $Bill: servers that hung, file downloads that were reported by 
setup.exe during the install phase as "incomplete," and so on. Not the specific file 
size 
limit problem $Bill is reporting, I need to add to be precise.

How I have handled the obstacles I have experienced --since I believed that they 
were apparently "endemic" to the Cygwin setup system as it is currently designed -- 
was just to perservere -- sometimes losing hours of time in the process -- until I 
could 
finally get a good setup run.

The most recent setup.exe is a major improvement in terms of clarity, I gave a huge 
sigh of relief and wanted to stand up and cheer when I saw the totally new 
heirarchical 
display style. That part of what's been accomplished is just great. I believe that 
problems may exist on the server network side or with the programming involved in 
that.

 Bearer of bad news? Shoot the messenger?
Soren Andersen


--
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: Scrolling Console?

[Pavel Tsekov]

1) Try using rxvt.
2) Don't forget to check the mailing list arcvhive

Rob wrote:

> Hi all!
> 
> Is there a console app out there that will allow for scrolling with an
> unlimited buffer? Win 2k's DOS prompt has this and I want it very badly on
> my WinME machine running cygwin..



--
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: Copy and Paste into Console

[Dr. Volker Zell]

> "Rob" == relaxedrob   writes:

Rob> OK.. I used your .inputrc - thank you very much. Here is what I found:
Rob> right-click copies
Rob> insert pastes
Rob> end prints out ~
Rob> home prints out ~
Rob> middle mouse button doesn't seem to do anything!

Rob> Did I miss something to do with the end, home and middle mouse buttons?

Try this:

# Make Home work
"\e[1~": beginning-of-line

It works for me. End seems to work OOTB here.

Rob> Rob

Ciao
  Volker


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

GCC 2.95.3-5 Internal Compiler Error for template, friend

[Humitaka Tamura]

Hello.

GCC 2.95.3-5 reports internal compiler error for the following source
code. Maybe it's only the cygwin special version's case, since other
versions of gcc (2.96, egcs-2.91.66) for Linux can compile it well.

--

class A
{
  public:
void f() {}
};

template  class C
{
friend void A::f();
};

int main()
{
C a;
return 0;
}

--
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: Downloading problems - either won't D/L at all or truncates over 1MB

[Robert Collins]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "$Bill Luebkert" <[EMAIL PROTECTED]>
Sent: Wednesday, January 09, 2002 7:10 PM
Subject: Re: Downloading problems - either won't D/L at all or truncates
over 1MB


> On 10 Jan 2002 at 10:06, Robert Collins wrote:
>
> I am not behind a firewall but have also had various problems similar
to some of
> those reported by $Bill: servers that hung, file downloads that were
reported by
> setup.exe during the install phase as "incomplete," and so on. Not the
specific file size
> limit problem $Bill is reporting, I need to add to be precise.

Ok. If you can provide specifics - what mirror site server, does it
support passive/active FTP (if FTP), or what HTTP software (if HTTP),
are you using a proxy, if so what proxy (and version) and did it require
authentication, and are you using the IE settings, or direct, or manual
proxy - then we can start to look for patterns. All the above are
needed, because (for instance) you may be using private mirror sites.

> How I have handled the obstacles I have experienced --since I believed
that they
> were apparently "endemic" to the Cygwin setup system as it is
currently designed --
> was just to perservere -- sometimes losing hours of time in the
process -- until I could > finally get a good setup run.

Try the latest setup.exe snapshots. They support multiple mirrors to
address this issue.

> The most recent setup.exe is a major improvement in terms of clarity,
I gave a huge
> sigh of relief and wanted to stand up and cheer when I saw the totally
new heirarchical
> display style. That part of what's been accomplished is just great. I
believe that
> problems may exist on the server network side or with the programming
involved in
> that.

The problems *may* be in the setup code. However, setup will attempt to
use the MS inet helper library, which results in the same code as MSIE
uses being used to do the download. I hope thats not too buggy :}.

Rob


--
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: Compiling apps to Mingw32 with cygwin

[Bernard Dautrevaux]

> -Original Message-
> From: Earnie Boyd [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 09, 2002 8:42 PM
> To: CU List
> Subject: Re: Compiling apps to Mingw32 with cygwin
> 
> 
> > Subject: Re: Compiling apps to Mingw32 with cygwin
> > Date: Wed, 9 Jan 2002 18:11:16 +0100
> > From: "J. Henning Schwentner" <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > 
> > Am Montag, 7. Januar 2002 17:49 schrieben Sie:
> > > Jon Leichter wrote:
> > > > - Using CC="gcc -mno-cygwin" is good for compiling, but 
> it's bad for GNU
> > > > Libtool, as I have mentioned. I use a wrapper script: 
> CC=mgcc. What do
> > > > you think of this Earnie?
> > >
> > > Your wrapper script is a good idea but has the wrong name 
> as has been
> > > pointed out already.  It needs to be named 
> i386-pc-mingw32-gcc and a
> > > copy as mingw32-gcc so that when specifying the --host=mingw32 or
> > > --host=i386-pc-mingw32 the configure script will find it 
> appropriately.
> > > Of course to do this you also need to do the same for the binutils
> > > binaries.
> > 
> > Do the binutils also support the -mno-cygwin switch? 
> 
> I'll leave that as an exercise for you to figure out.
> 
> > Or can the
> > 386-pc-mingw32- files be simple links to the 
> cygwin versions?
> > 
> 
> Yes, simply symlink will do.

So the simlink is not needed at all: if autotools don't find, say
"i386-pc-mingw32-ar", they'll look for plain "ar" and use it. So no need to
mind with these symlinks. Just creating the script/exec i386-pc-mingw32-gcc
will be enough (and a i386-pc-mingw32-g++ link to it when we get a mingw32
libstdc++ of course :)).

Regards


Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[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/

building dll's under cygwin

[Jean le Roux]

Hi all

Seems I've been on the receiving end of all the advice so far.. hope
this will change in the future :)

Until then.. here is the next piece of pain ;)
I use the autotools(all of them) to build my project. I've read the
whole of chapter 25 of the Autobook-1.3, and all I could find on
dll's in the faq and in this list's archives.. and I'm still stumped :(

Here is what my compiler tells me:

cd . \
  && CONFIG_FILES= CONFIG_HEADERS=config.h \
 /bin/sh ./config.status
creating config.h
config.h is unchanged
make  all-recursive
make[1]: Entering directory `/cygdrive/e/projects/myproject'
Making all in libsrc
make[2]: Entering directory `/cygdrive/e/projects/myproject/libsrc'
/bin/sh ../libtool --mode=link c++  -g -O2  -o libpmfp.la -rpath /usr/local/lib 
--no-undefined  --version-info 0:0:0 common.lo pmfp.lo pmfp_log.lo crypto.lo mckey.lo  
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared 
libraries
rm -fr .libs/libpmfp.la .libs/libpmfp.* .libs/libpmfp.*
ar cru .libs/libpmfp.a  common.o pmfp.o pmfp_log.o crypto.o mckey.o 
ranlib .libs/libpmfp.a
creating libpmfp.la
(cd .libs && rm -f libpmfp.la && ln -s ../libpmfp.la libpmfp.la)
make[2]: Leaving directory `/cygdrive/e/projects/myproject/libsrc'
make[2]: Entering directory `/cygdrive/e/projects/myproject'
cd . \
  && CONFIG_FILES= CONFIG_HEADERS=config.h \
 /bin/sh ./config.status
creating config.h
config.h is unchanged
make[2]: Leaving directory `/cygdrive/e/projects/myproject'
make[1]: Leaving directory `/cygdrive/e/projects/myproject'


Now, from  what I understand, the --no-undefined switch should
pre-empt any " warning: undefined symbols ..." warnings.
I suspect if this is solved, then the dll will be created.

In my configure.in i do have AC_LIBTOOL_WIN32_DLL, which seems to be
the only major thing to look out for.

Anyone else had this problem before ?


thanx
-- 
Jean le Roux
Binary Entropy Catalyst

Cellular:   083 505 6443

I owe the public nothing.
-- J.P. Morgan

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

Problem with winsup/cinstall compilation

[Ralf Habacker]

Hi,

I've tried to compile a recent setup.exe from the cvs and got an error while compiling
mklink2.c about "function declaration isn't a prototype"
I've found that in cinstall/Makefile.in the -Werror option is set, so warnings causes
compiling failures.

What about this ? As I see there are two solutions for this.

1. remove the -Werror in Makefile.in
CFLAGS  := @CFLAGS@ -Werror -Winline -Wall -Wpointer-arith -Wcast-align\
  
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
-Wmissing-declarations -Wcomments

2. fix the bad header.
   This seems to me the better solution, so a patch for the w32api header is appended.


Any comments to this ?

Regards
Ralf


habacker@BRAMSCHE ~/src/cvs.cygwin.com/build/winsup/cinstall
$ make
gcc -c -g -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict-pr
ototypes -Wmissing-prototypes -Wmissi
ng-declarations -Wcomments ... mklink2.c
cc1.exe: warnings being treated as errors
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/windef.h:203: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/windef.h:204: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/windef.h:205: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/rpcdce.h:363: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/rpcdcep.h:112: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/rpcdcep.h:113: warning: 
function
declaration isn't a prototype
/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include/rpc.h:49: warning: function
declaration isn't a prototype




w32api_20010110.dif
Description: Binary data

--
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: Problem with winsup/cinstall compilation

[Robert Collins]

===
- Original Message -
From: "Ralf Habacker" <[EMAIL PROTECTED]>
To: "Cygwin" <[EMAIL PROTECTED]>
Sent: Thursday, January 10, 2002 8:45 PM
Subject: Problem with winsup/cinstall compilation


> Hi,
>
> I've tried to compile a recent setup.exe from the cvs and got an error
while compiling
> mklink2.c about "function declaration isn't a prototype"
> I've found that in cinstall/Makefile.in the -Werror option is set, so
warnings causes
> compiling failures.
>
> What about this ? As I see there are two solutions for this.
>
> 1. remove the -Werror in Makefile.in
> CFLAGS :=
@CFLAGS@ -Werror -Winline -Wall -Wpointer-arith -Wcast-align\
>   
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
> -Wmissing-declarations -Wcomments
>
> 2. fix the bad header.
>This seems to me the better solution, so a patch for the w32api
header is appended.

2. is correct. The -Werror is there deliberately.

I don't see these errors however. What version of gcc are you building
with?
Also, why are you building against your system includes, not the winsup
includes? (see my compile line below. The patch looks ok though, you
should make a ChangeLog etc and send it to cygwin-patches.

Rob

$ make
gcc -L/usr/src/cygwin/build/i686-pc-cygwin/winsup -L/usr/src/cygwin/buil
d/i686-pc-cygwin/w
insup/cygwin -L/usr/src/cygwin/build/i686-pc-cygwin/winsup/w32api/lib -i
system /usr/src/sr
c/winsup/include -isystem /usr/src/src/winsup/cygwin/include -isystem
/usr/src/src/winsup/
w32api/include -isystem /usr/src/src/newlib/libc/sys/cygwin -isystem
/usr/src/src/newlib/l
ibc/sys/cygwin32 -B/usr/src/cygwin/build/i686-pc-cygwin/newlib/ -isystem
/usr/src/cygwin/b
uild/i686-pc-cygwin/newlib/targ-include -isystem
/usr/src/src/newlib/libc/include -MMD -g
-O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict-prototype
s -Wmissing-prototypes -Wmissing-declarations -Wcomments -mno-cygwin -I.
 -I/usr/src/src/wi
nsup/cinstall -I/usr/src/src/winsup/mingw/include  -I/usr/src/src/winsup
/bz2lib -mwindows
-c -o mklink2.o ../../../../../src/winsup/cinstall/mklink2.c
make -C zlib libzcygw.a
CC="gcc -L/usr/src/cygwin/build/i686-pc-cygwin/winsup -L/usr/src/c
ygwin/build/i686-pc-cygwin/winsup/cygwin -L/usr/src/cygwin/build/i686-pc
-cygwin/winsup/w32
api/lib -isystem /usr/src/src/winsup/include -isystem
/usr/src/src/winsup/cygwin/include -
isystem /usr/src/src/winsup/w32api/include -isystem
/usr/src/src/newlib/libc/sys/cygwin -i
system
/usr/src/src/newlib/libc/sys/cygwin32 -B/usr/src/cygwin/build/i686-pc-cy
gwin/newlib
/ -isystem
/usr/src/cygwin/build/i686-pc-cygwin/newlib/targ-include -isystem
/usr/src/src/
newlib/libc/include"
CFLAGS='-MMD -g -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-ali
gn -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-de
clarations -Wcomme
nts -mno-cygwin -I. -I/usr/src/src/winsup/cinstall -I/usr/src/src/winsup
/mingw/include  -I
/usr/src/src/winsup/bz2lib -mwindows'
make[1]: Entering directory
`/usr/src/cygwin/build/i686-pc-cygwin/winsup/cinstall/zlib'


Rob


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

telnet cannot see mount drive

[Tiffany Chan]

I mapped network drive (h:) in network neighboornood
in w2k SP2 advanced server. The network drive (h:) can
be accessed in both w2k "My computer" , w2k command
line "cd" and also in shortcut of Cygwin in w2k
desktop.

But when I telnet to the w2k server using Cygwin ,
type "mount". I cannot see h: or /cygdrive/h:, I also
try to use mount -s h: \\server\folder, but it does
not work. I cannot cd to h:

I telnet using w2k telnet server. I see that the
network drive is mapped by typing "mount", but it show
the status is "not available". also cannot "cd" to it.

Would you mind to help me ? Thanks

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

--
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: Downloading problems - either won't D/L at all or truncates over 1MB

[Robert Collins]

- Original Message -
From: "$Bill Luebkert" <[EMAIL PROTECTED]>
> You would think it would be easy to save the selections to a disk file
> (as are the servers etc) and reload on request.

It's not all that hard. Someone needs time and motivation. Also there
are some compromises due to the fact that setup acts as a half-a**ed
mirroring tool (the download mode) which is not allowed to store files
in any globall meaningful place if cygwin is not installed.

Rob


--
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: [Q]Windows PATH is not working..

[Bernard Dautrevaux]

> -Original Message-
> From: S.B.(SangBum) LEE [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 10, 2002 2:04 AM
> To: Pavel Tsekov
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Q]Windows PATH is not working..
> 
> 
> Is there anybody doing OK with Windows path? Cygwin 
> documentation says:
> 
> Cygwin supports both Win32- and POSIX-style paths, where 
> directory delimiters may be either forward or back slashes. UNC
> 
> pathnames (starting with two slashes and a network name) are 
> also supported.
> 
> I have a collegue who has no problem with doing as below. 
> However I can't find any of differences regarding installation
> 
> between me & him. That's why I raised this question.
> 
> Please let me know if you have anything you have in mind.. I 
> have to develop a program using Windows path.

I must say I'm a bit puzzled; I never look at it, but WIN32 path work very
well for arguments to programs but, I just test it now, they don't work for
executables in bash ;-(

Just a small test:

~> c:\\WINNT\\system32\\notepad.exe
bash: c:\WINNT\system32\notepad.exe: command not found
~> c:\\WINNT\\system32\\notepad
bash: c:\WINNT\system32\notepad: command not found
~> ls -l c:\\WINNT\\system32\\notepad.exe
-rwxr-xr-x1 Administ Aucun   46352 Nov  6  1996
c:\WINNT\system32\notepad.exe
~> notepad
~> mount
C:\bin on /usr/bin type system (binmode)
C:\lib on /usr/lib type system (binmode)
C: on / type system (binmode)

As can be seen my install is a little bit unusual (due to the need to mix
win32-native tools and cygwin tools without bothering too much with path
names) as I installed cygwin in the root of C:, but apart from that its
quite standard. 

However I don't have a clue to why this doesn't work.

Bernard

PS: here is a cygcheck run:

~> cygcheck -s -r

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Thu Jan 10 11:14:02 2002

Windows NT Ver 4.0 Build 1381 Service Pack 4

Path:   C:\usr\local\bin
C:\bin
C:\bin
t:\V3\DD\bin.NT
C:\LOCAL\gCVS-1.9-pc
C:\WINNT\SYSTEM32
C:\WINNT
C:\bin
C:\program files\devstudio\sharedide\bin\ide
C:\program files\devstudio\sharedide\bin
C:\program files\devstudio\vc\bin
C:\VisualGIPSY25\bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

HOME = `C:\cygwin'
MAKE_MODE = `unix'
PWD = `/cygwin'
USER = `Administrateur'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x0022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `C:'
  unix = `/'
  fbinary = 0x
  fsilent = 0x
HKEY_CURRENT_USER\Software\FTP Explorer\Profiles\Cygnus
  (default) = `sourceware.cygnus.com'
  Login = `anonymous'
  InitialPath = `/pub'
  AnonLogin = 0x0001
  CacheData = 0x
  DownloadPath = `D:\FTP'
  Description = `Cygnus Sourceware'
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrd
er\Start Menu\&Programs\
Cygnus Solutions
  (default) = (unsupported type)
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrd
er\Start Menu\Progra&mme
s\Cygnus Solutions
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrd
er\Start Menu\Progra&mme
s\Cygnus Solutions\Menu
  (default) = (unsupported type)
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/bin'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/lib'
  flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd   N/AN/A
c:  hd  NTFS4008Mb  88% CP CS UN PA FC
d:  hd  NTFS4000Mb  99% CP CS UN PA FC
e:  net NTFS2667Mb  50% CP CS UN PA FC
g:  net NTFS2667Mb  50% CP CS UN PA FC
h:  net NTFS   13782Mb  89% CP CS UN PA FC Datas
l:  net Samba   4063Mb  25% CPUN   Baseline
p:  net Samba   4063Mb  39% CPUN   Releases
r:  net Samba   4063Mb  25% CPUN   Repository
s:  net Samba   4063Mb  39% CPUN   SoftWorks
t:  net Samba   4063Mb  39% CPUN   Targets
u:  net Samba   4063Mb  57% CPUN   Users
x:  net NTFS 996Mb 100% CP CS UN PA FC Technique
y:  net Samba   4063Mb  57% CPUN   SoftWrks
z:  cd   

Re: Copy and Paste into Console

[Keith Starsmeare]

- Original Message -
From: "Rob" <[EMAIL PROTECTED]>
To: "Cygwin" <[EMAIL PROTECTED]>
Sent: Thursday, January 10, 2002 5:49 AM
Subject: RE: Copy and Paste into Console


> I am sure that I remember right-click being paste when I was using RedHat
> Linux.. anyway..

If you were using Linux then that would probably have been in an xterm or
similar (see the rxvt package which is currently having it's virtues
discussed endlessly in the mail list) however by default it's the middle
button to paste; but rxvt uses shift+left button (which I've got so used to
that I must get around to changing my .Xdefaults on Linux...).

Keith



--
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: building dll's under cygwin

[Gerrit P. Haase]

 Jean,

2002-01-10 11:15:36, du schriebst:

> Hi all

> Seems I've been on the receiving end of all the advice so far.. hope
> this will change in the future :)

> Until then.. here is the next piece of pain ;)
> I use the autotools(all of them) to build my project. I've read the
> whole of chapter 25 of the Autobook-1.3, and all I could find on
> dll's in the faq and in this list's archives.. and I'm still stumped :(

> Here is what my compiler tells me:

> cd . \
>   && CONFIG_FILES= CONFIG_HEADERS=config.h \
>  /bin/sh ./config.status
> creating config.h
> config.h is unchanged
> make  all-recursive
> make[1]: Entering directory `/cygdrive/e/projects/myproject'
> Making all in libsrc
> make[2]: Entering directory `/cygdrive/e/projects/myproject/libsrc'
> /bin/sh ../libtool --mode=link c++  -g -O2  -o libpmfp.la -rpath /usr/local/lib 
>--no-undefined  --version-info 0:0:0 common.lo pmfp.lo pmfp_log.lo crypto.lo mckey.lo 
> 
> libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared 
>libraries
> rm -fr .libs/libpmfp.la .libs/libpmfp.* .libs/libpmfp.*
> ar cru .libs/libpmfp.a  common.o pmfp.o pmfp_log.o crypto.o mckey.o 
> ranlib .libs/libpmfp.a
> creating libpmfp.la
> (cd .libs && rm -f libpmfp.la && ln -s ../libpmfp.la libpmfp.la)
> make[2]: Leaving directory `/cygdrive/e/projects/myproject/libsrc'
> make[2]: Entering directory `/cygdrive/e/projects/myproject'
> cd . \
>   && CONFIG_FILES= CONFIG_HEADERS=config.h \
>  /bin/sh ./config.status
> creating config.h
> config.h is unchanged
> make[2]: Leaving directory `/cygdrive/e/projects/myproject'
> make[1]: Leaving directory `/cygdrive/e/projects/myproject'


> Now, from  what I understand, the --no-undefined switch should

It is `-no-undefined' and also just `-version-info',
`-export-symbols' and so on, not `--xxx-xxx'.

> pre-empt any " warning: undefined symbols ..." warnings.
> I suspect if this is solved, then the dll will be created.

> In my configure.in i do have AC_LIBTOOL_WIN32_DLL, which seems to be
> the only major thing to look out for.

> Anyone else had this problem before ?

Gerrit
-- 
begin  signature:
=^..^=
end


--
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: [Q]Windows PATH is not working..

[Pavel Tsekov]

Heyho :)

Bernard Dautrevaux wrote:

Well, I felt the same way - I thought I should
investigate this but not until the weekend. I
hoped that someone will shed some light in the
meantime :)

> 
> I must say I'm a bit puzzled; I never look at it, but WIN32 path work very
> well for arguments to programs but, I just test it now, they don't work for
> executables in bash ;-(
> 
> Just a small test:
> 
> ~> c:\\WINNT\\system32\\notepad.exe
> bash: c:\WINNT\system32\notepad.exe: command not found
> ~> c:\\WINNT\\system32\\notepad
> bash: c:\WINNT\system32\notepad: command not found
> ~> ls -l c:\\WINNT\\system32\\notepad.exe
> -rwxr-xr-x1 Administ Aucun   46352 Nov  6  1996
> c:\WINNT\system32\notepad.exe
> ~> notepad
> ~> mount
> C:\bin on /usr/bin type system (binmode)
> C:\lib on /usr/lib type system (binmode)
> C: on / type system (binmode)
> 
> As can be seen my install is a little bit unusual (due to the need to mix
> win32-native tools and cygwin tools without bothering too much with path
> names) as I installed cygwin in the root of C:, but apart from that its
> quite standard. 
> 
> However I don't have a clue to why this doesn't work.



--
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: cygwin console

[Igor Bujna]

Charles Wilson wrote:

> Please keep replies on the list.
>
> Igor Bujna wrote:
>
>> Charles Wilson wrote:
>>
>>> Try installing this font:  Lucida ConsoleP from 
>>> http://www.neuro.gatech.edu/users/cwilson/cygutils/unversioned/bashprompt/ 
>>>
>>>
>>> It is Lucida Console, reencoded to put the linedraw chars where 
>>> codepage:oem expects them.  Then, start rxvt as:
>>>
>>> rxvt -fn "Lucida ConsoleP-14" .
>>>
>>> (also, you may need to set your TERM variable to 'rxvt-cygwin-native')
>>>
>>> --Chuck
>>
>>
>>
>> I make somethings wrong.
>> I have Win98 Second editions.in autoexec.bat i have this 'SET 
>> CYGWIN=codepage:oem'. I download the fonts Lucida ConsoleP end after 
>> i this *.ttf put into c:\windows\fonts.
>> I have script clock.bat:
>> @echo off
>> rxvt -tn rxvt-cygwin-native -fg lightblue -bg midnightblue -cr red 
>> -title -fn "Lucida ConsoleP-12" -e /bin/bash
>
>
>
>
>> And after i try to echo $TERM and i get rxvt-cywgin-native.
>> Then i run test program ./gdc.exe(this is test program from 
>> ncurses->a clock.This clock is in box().I put this in attachments )
>> I must see ACS_VLINE , but i see '3'.
>> What im doing wrong.
>
>
> I don't know.  Did you reboot?  Until you reboot, the change you made 
> in autoexec.bat won't have any effect.  I just tried this myself, and 
> it worked fine.  ACS_VLINE and all.

OK.now its running.Thanks very much.
This is the script clock.bat:
@echo off
start rxvt -fn "Lucida ConsoleP-20" -tn rxvt-cygwin-native -geometry 
110x40 -fg lightblue -bg midnightblue -vb -sr +sb -title  -e ./gdc.exe 
Can i see the blink cursor???
I have program when i must change color of cursor.Can i do this.On rxvt 
i see cursor in light blue color.
Bye

>
> BTW, there was no need to send the binary -- gdc.exe is in 
> /usr/bin/ncurses-test-dll/
>
> --Chuck
>
>
> -- 
> 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: RXVT Font Question

[Alex Malinovich]

I've been using Lucida Console since that's the closest that I could get
to terminal, but I really would like to get the actual terminal font
working. Does anyone have any suggestions? I've already checked the mail
archives, the FAQ, and done a Google search, all to no avail.

-Alex

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Parker, Ron
Sent: Wednesday, January 09, 2002 2:08 PM
To: [EMAIL PROTECTED]
Subject: RXVT Font Question


The Windows 2000 console can use two different fonts. The one is "Lucida
Console". The other is "Terminal". Is it possible to use "Terminal" in
say the 8x12 size with rxvt?  I think it does the right thing with box
characters and while it is not as smooth has a heavier weight and is
easier on my eyes with certain color combinations.

--
"Beauty is in the eye of the beholder and the beholder is blind."

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

libpng problems with png_info_init, png_read_destroy

[Gerrit P. Haase]

Hallo Cygwinners,

I'm getting these undefined references when linking against
libjpeg import lib:
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:79: undefined reference to 
`png_read_destroy'
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:94: undefined reference to `png_info_init'
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:286: undefined reference to 
`png_read_destroy'

Are there a known workaround besides linking the libs statically?

Gerrit
-- 
begin  Rename the README file to:
   'It_Is_Forbidden_To_Read_This_Super_Mega_Secret_File'
   =^..^=
end


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

rxvt ignores (displays!) escape codes

[Neil Bird]

   If I run up the cygwin bash (presukably under some flavour of 
cmd.exe), and then run rxvt, I get a new window with TERM=xterm 
as expected, but all attempts to print escape codes print '\e'!

   Cursor movement's shot to hell too; pressing 'up' actually 
moves the cursor in the window as opposed to recalling the 
previous command.


   What've I done wrong?  I don't recall messing with TERMINFO 
and the like.

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit


--
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: libpng problems with png_info_init, png_read_destroy

[Gerrit P. Haase]

 Gerrit,

2002-01-10 13:10:29, du schriebst:

> Hallo Cygwinners,

> I'm getting these undefined references when linking against
> libjpeg import lib:
Waddaza want?  Wanted to say> libpng import lib

> /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:79: undefined reference to 
>`png_read_destroy'
> /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:94: undefined reference to 
>`png_info_init'
> /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:286: undefined reference to 
>`png_read_destroy'

> Are there a known workaround besides linking the libs statically?

Gerrit
-- 
begin  signature:
=^..^=
end


--
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: Newbie Question (+ installation and security questions)

[David Starks-Browning]

Neither rxvt tips nor instructions for installing everything with
setup.exe are in the FAQ yet.  I'm really sorry.  Hopefully tonight?
Meanwhile you'll have to search the email archives.  (I think the FAQ
tells you to do that anyway, before writing to the mailing list.)

The problem with my FAQ maintainance has been that my connectivity to
work (where all my Cygwin mail archives are carefully organised) from
home (the only place I can maintain the FAQ) has degraded profoundly
over the past few months.  I had hoped that would be transient, but
since it is persisting, I've recently been working to get everything
in the right place(s).  So things should improve soon.

Regards,
David
(Cygwin FAQ maintainer)


--
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: URGENT: Cygwin Installation Problem

[Earnie Boyd]

indu britto wrote:
> 
> Hello Earnie
> 
> I went through your tutorial on 'Installing
> (Cygwin'http://gw32.freeyellow.com/InstallingCygwin.html) , and followed
> these steps, to install Cywin on my Windows 2000 machine:
> 

I'm only responding to you because you mention this out of date
website.  Please, further postings to [EMAIL PROTECTED] only.

> 1. Downloaded the latest version of setup.exe, by clicking on 'Install
> Cygwin Now' at www.wygwin.com, on to the Desktop.
> 2. Ran setup.exe
> 3. Selected 'Download from Internet'
> 4. Selected 'Use IE5 Settings'
> 5. Selected a download site in Japan ( i am in India)
> 6. On the package selection page, i clicked on 'View' to see all the
> packages, and clicked on each package to see their version number.
> 7. Then the setup proceeded to download all the files.
> 
> After the download was complete
> 8. Re-ran setup.exe
> 9. Selected Install from Local Directory
> 10. Did not deselect any of the packeages that had been downloaded earlier.
> 11. The setup wewnt through without any problems, and i finally got the
> option to have a desktop icon, and add cygwin to the Start menu.
> 
> Then i downloaded PostgreSQL (tar.gz file) and the cygipc (tar.gz file)
> 12. unpacked cygipc in the cygwin root directory.
> 13. copied the postgresql source file into /usr/src in the cygwin root
> 14. unpacked the source, and changed to the postgresql directory
> 15. entered the ./configure command
> 
> Then i got an error:
> gcc not found
> cc not found
> 
> and the compilation terminated.
> 

It sounds as if you need to execute setup again and install gcc.  Based
on your stated Cygwin install procedure above, you only installed the
Base category in the second execution of setup.  You would have had to
of selected again what to install.

> I have since found out that in the latest version of cygwin, you can select
> the file names, which in turn shows a checkbox for selecting files to
> download and this may have been where I made a mistake. I did not select
> each box (put in the 'x' symbol) the first time round.
> 

That checkbox will download/install the source tarball.  By installing
source it unarchives the tarball to /usr/src.

> I then went thru all the above mentioned steps in that order and remembered
> to select the box against each utility package.
> 
> I faced the same problem during compilation.
> 
> Can you please tell me what i am doing wrong.
> Thanks in advance.
> 

You might want to send the output of `cygcheck -s -r -v' to the list.

Earnie.

_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
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: Setting up user mode cron

[Corinna Vinschen]

On Wed, Jan 09, 2002 at 07:29:50PM -0800, Andrew DeFaria wrote:
>  Larry Hall (RFK Partners, Inc) wrote:
> 
> >OK, yes all your mounts are system.  Looking back over your original 
> >comments, what doesn't work again?  You seem to indicate that cron is 
> >running.  The output you show indicates it did run.  But you claim it 
> >didn't run a script.  How did you determine that?  Perhaps you're 
> >interpreting the fact that you're having problems accessing the network 
> >share as a cron script execution problem?
> >
> OK let's scale back a little bit. The situation is that I would like to 
> run cron on my desktop and by extension allow my users to run their own 
> crons on their desktop. We're in a domain and as such we have set it up 
> such that people's home directories are mounted on /home from the 
> Windows server that houses the home directories. Therefore we have the 
> following mount:
> 
> \\sonscentral\users on /home type system (textmode).
> 
> Given my username, adefaria, therefore ls /home/adefaria (or ls ~) will 
> list the contents of \\sonscentral\users\adefaria. Note there are no 
> mapped drives here, just UNC names.

Anyway, cron has no access to them.  It's running under SYSTEM account
which has only access to publically available net drives, that is,
drives which are available w/o any form of authentication required.
The forked cron jobs are running in the same logon session even if they
are running under another user account.  Keep in mind that the user
context has been changed w/o asking for logon credentials.  This is
different from what the native Windows scheduler does (which requires
entering the password).  No credentials, no authenticated network drive
access.  That's it.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: building dll's under cygwin

[Jean le Roux]

On Thu, Jan 10, 2002 at 11:18:11AM +0100, Gerrit P. Haase wrote:
>  Jean,
> 
> 2002-01-10 11:15:36, du schriebst:
> 
> >...
> > Now, from  what I understand, the --no-undefined switch should
> 
> It is `-no-undefined' and also just `-version-info',
> `-export-symbols' and so on, not `--xxx-xxx'.
> 

That does it :)
Millions of thankyou's :)


-- 
Jean le Roux
Binary Entropy Catalyst

Rules for driving in New York:
(1) Anything done while honking your horn is legal.
(2) You may park anywhere if you turn your four-way flashers on.
(3) A red light means the next six cars may go through the
intersection.

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

Cygwin 1.3.6 on NT 4.0: init_cygheap error

[Markus Brenner]

(1)

I saw only a few references to this in past postings, but actually did not
find a resolution (most recent posting is
http://sources.redhat.com/ml/cygwin/2001-11.t/msg00299.html )

I tried to install Cygwin 1.3.6 on our PC with NT 4.0, service pack 4.

When invoking the bash shell (either through the Cygnus icon or within a
DOS command prompt) I get the following message:

"0 [main] bash 302 init_cygheap::etc_changed: Can't open /etc for checking,
Win32 error 50"

The /etc directory exists.

When invoking another bash shell within the same window this message does
not appear again.

For compatibility and historical reasons the B20 release is also installed
on the same machine (I am not sure whether this has any influence on the
above described problem).

(2)

A second problem that appears as well is that when calling 'vim' from the
above installation (6.0.93-1) I get the following error message in a pop-up
window:

"The dynamic link library cygintl.dll could not be found in the specified
path ."

When searching for this DLL I could not find this anywhere in the
directories where Cygwin is installed.

Could anybody provide input to the above described problems?

Many thanks,
Markus Brenner

--
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: Windows XP and cygwin's heap

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 03:30:45AM +, Greg B. wrote:
> 
> Hi,
> 
> I've installed Cygwin on Windows XP
> when I execute the shortcut to Cygwin Bash Shell,
> I get
> 
> C:\cygwin\bin\id.exe: *** Couldn't reserve space
> for cygwin's heap (0x9B) in child, cygheap, Win32 error 487
> C:\cygwin\bin\mkdir.exe: *** Couldn't reserve space
> for cygwin's heap (0x9B) in child, cygheap, Win32 error 487
> bash: cd: /home/: no such file or directory
> 
> any help would be appreciated,

Old dll and/or prerelease of XP?  Try updating both.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: GCC 2.95.3-5 Internal Compiler Error for template, friend

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 06:20:41PM +0900, Humitaka Tamura wrote:
> Hello.
> 
> GCC 2.95.3-5 reports internal compiler error for the following source
> code. Maybe it's only the cygwin special version's case, since other
> versions of gcc (2.96, egcs-2.91.66) for Linux can compile it well.

You should report that to the gcc list.  That has nothing to do with Cygwin.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: telnet cannot see mount drive

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 09:59:16AM +, Tiffany Chan wrote:
> I mapped network drive (h:) in network neighboornood
> in w2k SP2 advanced server. The network drive (h:) can
> be accessed in both w2k "My computer" , w2k command
> line "cd" and also in shortcut of Cygwin in w2k
> desktop.
> 
> But when I telnet to the w2k server using Cygwin ,
> type "mount". I cannot see h: or /cygdrive/h:, I also
> try to use mount -s h: \\server\folder, but it does
> not work. I cannot cd to h:
> 
> I telnet using w2k telnet server. I see that the
> network drive is mapped by typing "mount", but it show
> the status is "not available". also cannot "cd" to it.
> 
> Would you mind to help me ? Thanks

That's how it works, unfortunately.  When telnetting into the box
you're running in another logon session.  You have no access
to the mapped drives of the same user when logged on in a
desktop session.

Workaround:  Create a new drive mapping *inside* your telnet session
using another drive letter:

net use J: 

But *DON'T FORGET* to release the drive mapping before logging
out that very telnet session.  Otherwise this drive letter
is never ever usable as long as the machine isn't rebooted:

net use J: /delete

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: telnet cannot see mount drive

[David Starks-Browning]

On Thursday 10 Jan 02, Corinna Vinschen writes:
> Workaround:  Create a new drive mapping *inside* your telnet session
> using another drive letter:
> 
> net use J: 
> 
> But *DON'T FORGET* to release the drive mapping before logging
> out that very telnet session.  Otherwise this drive letter
> is never ever usable as long as the machine isn't rebooted:
> 
> net use J: /delete

Thanks Corinna, I had not seen this before.  I'll add it to the FAQ.

("Yeah, right!" you say :-)

David


--
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: telnet cannot see mount drive

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 12:52:57PM +, David Starks-Browning wrote:
> On Thursday 10 Jan 02, Corinna Vinschen writes:
> > Workaround:  Create a new drive mapping *inside* your telnet session
> > using another drive letter:
> > 
> > net use J: 
> > 
> > But *DON'T FORGET* to release the drive mapping before logging
> > out that very telnet session.  Otherwise this drive letter
> > is never ever usable as long as the machine isn't rebooted:
> > 
> > net use J: /delete
> 
> Thanks Corinna, I had not seen this before.  I'll add it to the FAQ.
> 
> ("Yeah, right!" you say :-)

Yeah, right! :-)

However, another fact which should be mentioned in that FAQ is:

  That doesn't work in ssh/rsh sessions created without
  using a password.  These sessions have the same restrictions
  as all sessions running under SYSTEM account.

Did you see my previous mail related to using network drives
in ssh sessions, David?  That's the crucial stuff.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Fleischer, Karsten (K.)]

> >I know about that.
> 
> Ok.  Then that's the way to go.  Just follow the procedures in
> http://cygwin.com/contrib.html .  If your fix is big you'll 
> need to fill
> out an assignment form as that web page mentions.

It's a whole bunch of small fixes. I think I need to fill out the assignment form.
Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?

> >So can we get down to discuss my fixes now?
> 
> If you want to start a discussion, then... start it.  You don't need
> permission to begin.
> 
> It would be nice if, before you start making observations or 
> suggesting
> fixes, you checked the mailing list archives to see if you 
> are covering
> old ground or not.

I think I've done that thoroughly enough.
I've done some fixes to mmap() that might be superseded by other patches now. I 
haven't checked this yet.

> Also be advised that we can't break backwards compatibility 
> in the DLL.

That's one of the reasons I haven't been coming up with my patches until now. I wanted 
to test it carefully.

> If you provide patches, small well-defined ones are the best. 
>  Long patches
> which do many different things are less likely to be 
> inspected or accepted.

They're quite small.

> And, if you are really going to be engaged in a discussion 
> you probably should
> subscribe to the cygwin mailing list.  I don't think we're 
> going to be able
> to remember to include your two email addresses in every 
> response to you.

Done.


I'll give a short summary of what I've fixed:

- pathconf() doesn't check existance of the path
- getpagesize() should return a value compatible with mmap(), that is 
dwAllocGranularity (65536) instead of dwPageSize (1024).
- use .exe extension detection consequently in all syscalls
- automatically add the .exe extension to a newly created file on close() when the 
first four bytes are 0x4d, 0x5a, 0x90, 0x00 (MS Executable magic bytes) and the file 
name didn't have an extension already. (This is from UWIN, I think it's really nice).
- exec*() functions would always invoke a /bin/sh on a file that isn't a valid 
executable. Only execlp()/execvp() should do so, others must return with an ENOEXEC.
- the exec*() fix revealed a bug with vfork() in ash
- use the contents of $SHELL instead of /bin/sh for execvp()/execlp() and system() 
(with some additional checks, e.g. do not use a csh, use only 'trusted' shells from 
/bin, /usr/bin, /usr/local/bin etc.). This allows the user to select his favorite 
shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This is also from 
UWIN).
- some mmap() problems have been fixed.
- utime() doesn't mark st_ctime for update

Does this sound OK for you, especially the UWIN things I'm mimicing?

Karsten

--
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: telnet cannot see mount drive

[David Starks-Browning]

On Thursday 10 Jan 02, Corinna Vinschen writes:
> Did you see my previous mail related to using network drives
> in ssh sessions, David?  That's the crucial stuff.

Probably, but I may have to dig around my archives.  I'll let you know
if I can't find it.

David


--
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: libpng problems with png_info_init, png_read_destroy

[Gerrit P. Haase]

 Jean,

2002-01-10 14:01:30, du schriebst:

> Perhaps this time I can ofer my two cents worth ;)

>> > Hallo Cygwinners,
>> 
>> > I'm getting these undefined references when linking against
>> > libjpeg import lib:
>> Waddaza want?  Wanted to say> libpng import lib
>> 
>> > /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:79: undefined reference to 
>`png_read_destroy'
>> > /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:94: undefined reference to 
>`png_info_init'
>> > /stuff/test/mMosaic-src-3.7.2/src/readPNG.c:286: undefined reference to 
>`png_read_destroy'
>> 
>> > Are there a known workaround besides linking the libs statically?

> Since you are using .c, I presume that you are including the source
> and that the .c files do not contain the declerations, but only the
> implmentations of the code. Errors like your's if freuently
> encountered when forgetting to include a header file. Make sure that
> you are not looking for /stuff/test/mMosaic-src-3.7.2/src/readPNG.h
> instead.

> It appears that you want to rather include the .h files and add the
> relevant lib in your link-line.

No, the problem is that these functions are private and are not exported
from the dll lib, so I need to link libpng staticallz to get the
functions, but I want to link against the dynamic lib.

I found one reference in the archives how to substitute png_info_init
with png_create_info_struct() but nothing about png_read_destroy().


Anyway, thank you for your comment, please keep communication on the
cygwin list as long as it is ontopic there.

Gerrit
-- 
=^..^=


--
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: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 07:59:12AM -0500, Fleischer, Karsten (K.) wrote:
> It's a whole bunch of small fixes. I think I need to fill out the assignment form.

Yeah, please send it as soon as possible since you'll have to send
it by snail mail.  Sometimes it takes two to three weeks for some
reason.

> Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?

I would suggest to move them to the latest from CVS.  If you're
always working against the latest from CVS you don't get hit too
much by changes from other people.

> I'll give a short summary of what I've fixed:

I'll compare your below listing against current from CVS.  You should
evaluate my answers in that light.

> - pathconf() doesn't check existance of the path

It does.  However, there's an error in _PC_PATH_MAX.   It doesn't
validate the incoming path which could result in a SEGV.  I've
checked in a fix.

> - getpagesize() should return a value compatible with mmap(), that is 
>dwAllocGranularity (65536) instead of dwPageSize (1024).

We discussed that months ago.  I think we're not going to change that
(it's 4096, not 1024, btw.).  It will result in dubious problems
when a process mmaps a file.  For instance, the latest gcc expects to
be able to read over the end of an mmaped file if the size is not a
multiple of getpagesize().  Now think of a file which is coincidentally
exactly 1 page long...

> - use .exe extension detection consequently in all syscalls

You mean unlink() etc.?

> - automatically add the .exe extension to a newly created file on close() when the 
>first four bytes are 0x4d, 0x5a, 0x90, 0x00 (MS Executable magic bytes) and the file 
>name didn't have an extension already. (This is from UWIN, I think it's really nice).

Ugh.  I'm not quite sure if I like that.

> - exec*() functions would always invoke a /bin/sh on a file that isn't a valid 
>executable. Only execlp()/execvp() should do so, others must return with an ENOEXEC.

Sounds like a bug.

> - the exec*() fix revealed a bug with vfork() in ash

We have some vfork() changes in the meantime and even ash had an 
related error which should be fixed.

> - use the contents of $SHELL instead of /bin/sh for execvp()/execlp() and system() 
>(with some additional checks, e.g. do not use a csh, use only 'trusted' shells from 
>/bin, /usr/bin, /usr/local/bin etc.). This allows the user to select his favorite 
>shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This is also from 
>UWIN).

Hmm, interesting idea...

> - some mmap() problems have been fixed.

Since I have changed so much in mmap() you should actually first
compare your changes to the current version.

> - utime() doesn't mark st_ctime for update

Really?  I would never think so when inspecting the source code.

> Does this sound OK for you, especially the UWIN things I'm mimicing?

I don't like the idea to append a .exe suffix related to the first
bytes in the file.  But we can discuss everything, of course.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: telnet cannot see mount drive

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 01:07:35PM +, David Starks-Browning wrote:
> On Thursday 10 Jan 02, Corinna Vinschen writes:
> > Did you see my previous mail related to using network drives
> > in ssh sessions, David?  That's the crucial stuff.
> 
> Probably, but I may have to dig around my archives.  I'll let you know
> if I can't find it.

My bad.  I meant "cron", not "ssh".  The problem is the same.
The message is http://cygwin.com/ml/cygwin/2002-01/msg00607.html
from today.

Sorry,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Robert Collins]

- Original Message -
From: "Corinna Vinschen" <[EMAIL PROTECTED]>
> > - getpagesize() should return a value compatible with mmap(), that
is dwAllocGranularity (65536) instead of dwPageSize (1024).
>
> We discussed that months ago.  I think we're not going to change that
> (it's 4096, not 1024, btw.).  It will result in dubious problems
> when a process mmaps a file.  For instance, the latest gcc expects to
> be able to read over the end of an mmaped file if the size is not a
> multiple of getpagesize().  Now think of a file which is
coincidentally
> exactly 1 page long...

I'm not sure what you are implying. unless getpagesize returns 1, the
behaviour for gcc will be consistent for all larger sizes. If it's 4k,
then a file that is 4k will behave the same way as a 64K file if the
pagesize returned is 64k.

You seem to be implying that something bad happens when the file size ==
the returned page size.

What is that bad thing?

Rob


--
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: Cygwin 1.3.6 on NT 4.0: init_cygheap error

[Pavel Tsekov]

Markus Brenner wrote:

> (1)
> 
> I saw only a few references to this in past postings, but actually did not
> find a resolution (most recent posting is
> http://sources.redhat.com/ml/cygwin/2001-11.t/msg00299.html )
> 
> I tried to install Cygwin 1.3.6 on our PC with NT 4.0, service pack 4.
> 
> When invoking the bash shell (either through the Cygnus icon or within a
> DOS command prompt) I get the following message:
> 
> "0 [main] bash 302 init_cygheap::etc_changed: Can't open /etc for checking,
> Win32 error 50"
> 
> The /etc directory exists.
> 
> When invoking another bash shell within the same window this message does
> not appear again.
> 
> For compatibility and historical reasons the B20 release is also installed
> on the same machine (I am not sure whether this has any influence on the
> above described problem).


This is not good. I'm not 100 % sure if this is connected to your 
problem though. You can try removing both then reinstalling. Or
try searching the mailing list for alternative ways of deinstalling
the old version while keeping the new one.


> 
> (2)
> 
> A second problem that appears as well is that when calling 'vim' from the
> above installation (6.0.93-1) I get the following error message in a pop-up
> window:
> 
> "The dynamic link library cygintl.dll could not be found in the specified
> path ."
> 
> When searching for this DLL I could not find this anywhere in the
> directories where Cygwin is installed.
> 
> Could anybody provide input to the above described problems?

Well, search the mailing list archive for the following:
"[ANNOUNCEMENT] gettext-0.10.40-1" - this will help you
understand whats going on and how to fix you problem. You
need the old dll.


--
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: ksh on cygwin

[Corinna Vinschen]

On Fri, Jan 11, 2002 at 12:54:06AM +1100, Robert Collins wrote:
> - Original Message -
> From: "Corinna Vinschen" <[EMAIL PROTECTED]>
> > > - getpagesize() should return a value compatible with mmap(), that
> is dwAllocGranularity (65536) instead of dwPageSize (1024).
> >
> > We discussed that months ago.  I think we're not going to change that
> > (it's 4096, not 1024, btw.).  It will result in dubious problems
> > when a process mmaps a file.  For instance, the latest gcc expects to
> > be able to read over the end of an mmaped file if the size is not a
> > multiple of getpagesize().  Now think of a file which is
> coincidentally
> > exactly 1 page long...
> 
> I'm not sure what you are implying. unless getpagesize returns 1, the
> behaviour for gcc will be consistent for all larger sizes. If it's 4k,
> then a file that is 4k will behave the same way as a 64K file if the
> pagesize returned is 64k.
> 
> You seem to be implying that something bad happens when the file size ==
> the returned page size.
> 
> What is that bad thing?

mmap (MapViewOfFile resp.) alwaus map whole pages.  A page is 4096
bytes long. 

If a file is, say, 8190 bytes, then we have a two page map, size 8192.
So we have two trailing 0 bytes.  If getpagesize() returns 4096, gcc can
count that correctly, if getpagesize returns 65536, gcc assumes 57346
trailing bytes.  No problem, gcc only accesses exactly one trailing 0 byte.

If the file is 8192 bytes long, mmap maps exactly 8192 bytes, no
trailing bytes left.  If getpagesize() returns 4096, gcc knows that,
if getpagesize returns 65536, gcc assumes 57344 trailing bytes.
Now it is a problem, since the one trailing 0 byte doesn't exist.
Segmentation fault.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: Cygwin 1.3.6 on NT 4.0: init_cygheap error

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 03:01:12PM +0100, Pavel Tsekov wrote:
> Markus Brenner wrote:
> >For compatibility and historical reasons the B20 release is also installed
> >on the same machine (I am not sure whether this has any influence on the
> >above described problem).
> 
> 
> This is not good. I'm not 100 % sure if this is connected to your 
  ^
  Right!  Never have two copies of cygwin1.dll in the DLL search path.
  Even worse if they have diverging versions.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Fleischer, Karsten (K.)]

> > It's a whole bunch of small fixes. I think I need to fill 
> out the assignment form.
> 
> Yeah, please send it as soon as possible since you'll have to send
> it by snail mail.  Sometimes it takes two to three weeks for some
> reason.

OK, I'll fill it out later today.

> > Is it OK to send patches to 1.3.3-2 or should I move them 
> to 1.3.6 first?
> 
> I would suggest to move them to the latest from CVS.  If you're
> always working against the latest from CVS you don't get hit too
> much by changes from other people.

I'll try that.

> > I'll give a short summary of what I've fixed:
> 
> I'll compare your below listing against current from CVS.  You should
> evaluate my answers in that light.
> 
> > - pathconf() doesn't check existance of the path
> 
> It does.  However, there's an error in _PC_PATH_MAX.   It doesn't
> validate the incoming path which could result in a SEGV.  I've
> checked in a fix.

Good.

> > - getpagesize() should return a value compatible with 
> mmap(), that is dwAllocGranularity (65536) instead of 
> dwPageSize (1024).
> 
> We discussed that months ago.  I think we're not going to change that
> (it's 4096, not 1024, btw.).

Oops, I was writing this summary from memory, I don't have the patches at hand now...

> It will result in dubious problems
> when a process mmaps a file.  For instance, the latest gcc expects to
> be able to read over the end of an mmaped file if the size is not a
> multiple of getpagesize().  Now think of a file which is 
> coincidentally
> exactly 1 page long...

Glenn found some test cases where mmap() failed and has also written a nice test 
program. I will get this to you later.
He also states that the value returned by getpagesize() must conform to mmap() 
alignment by definition in the SUSv2. I'm not quite sure about that, though.

> > - use .exe extension detection consequently in all syscalls
> 
> You mean unlink() etc.?

Yes. chmod(), link(), open(), pathconf(), rename(), truncate() and unlink() (have I 
missed one?) didn't check for the .exe extension.

> > - automatically add the .exe extension to a newly created 
> file on close() when the first four bytes are 0x4d, 0x5a, 
> 0x90, 0x00 (MS Executable magic bytes) and the file name 
> didn't have an extension already. (This is from UWIN, I think 
> it's really nice).
> 
> Ugh.  I'm not quite sure if I like that.

This eliminates the need to fix up programs which produce executables, e.g. ld.
Also you don't need to take care of the .exe extension in cp.
It's there automatically.

> > - exec*() functions would always invoke a /bin/sh on a file 
> that isn't a valid executable. Only execlp()/execvp() should 
> do so, others must return with an ENOEXEC.
> 
> Sounds like a bug.

Yes. A big one.

> > - the exec*() fix revealed a bug with vfork() in ash
> 
> We have some vfork() changes in the meantime and even ash had an 
> related error which should be fixed.

Maybe we fixed the same error. I'll send you the details.

> > - use the contents of $SHELL instead of /bin/sh for 
> execvp()/execlp() and system() (with some additional checks, 
> e.g. do not use a csh, use only 'trusted' shells from /bin, 
> /usr/bin, /usr/local/bin etc.). This allows the user to 
> select his favorite shell manually, so no more "copy 
> /bin/bash to /bin/sh" troubles. (This is also from UWIN).
> 
> Hmm, interesting idea...

OK, more detailed. I allow only absolute pathes in $SHELL and don't allow any *csh.
If superuser then only shells from [/usr][/local]/bin are considered trusted shells.
If not superuser shells from other directories are allowed, but if uid != euid or gid 
!= egid the shell and the directory where it resides must not be writable.
Fall back value is /bin/sh.

> > - some mmap() problems have been fixed.
> 
> Since I have changed so much in mmap() you should actually first
> compare your changes to the current version.

I'll do that.

> > - utime() doesn't mark st_ctime for update
> 
> Really?  I would never think so when inspecting the source code.

Has this been fixed meanwhile? Also other calls like chmod() must mark st_ctime for 
update. My patches are not complete here.

Karsten

--
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: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 09:13:01AM -0500, Fleischer, Karsten (K.) wrote:
> > > It's a whole bunch of small fixes. I think I need to fill 
> > out the assignment form.
> > 
> > Yeah, please send it as soon as possible since you'll have to send
> > it by snail mail.  Sometimes it takes two to three weeks for some
> > reason.
> 
> OK, I'll fill it out later today.

Fine.  We can need everybody who dares to change Cygwin ;-)

> > It will result in dubious problems
> > when a process mmaps a file.  For instance, the latest gcc expects to
> > be able to read over the end of an mmaped file if the size is not a
> > multiple of getpagesize().  Now think of a file which is 
> > coincidentally
> > exactly 1 page long...
> 
> Glenn found some test cases where mmap() failed and has also written a nice test 
>program. I will get this to you later.
> He also states that the value returned by getpagesize() must conform to mmap() 
>alignment by definition in the SUSv2. I'm not quite sure about that, though.

See my reply to Robert.  It's just an example.  I don't have another
reason at hand now but we already considered that change and we
actually *had* reasons to avoid it.  Perhaps Chris can help out here.

> > We have some vfork() changes in the meantime and even ash had an 
> > related error which should be fixed.
> 
> Maybe we fixed the same error. I'll send you the details.

Please compare with the current CVS.  Vfork() isn't in my expertise.

> > > - use the contents of $SHELL instead of /bin/sh for 
> > execvp()/execlp() and system() (with some additional checks, 
> > e.g. do not use a csh, use only 'trusted' shells from /bin, 
> > /usr/bin, /usr/local/bin etc.). This allows the user to 
> > select his favorite shell manually, so no more "copy 
> > /bin/bash to /bin/sh" troubles. (This is also from UWIN).
> > 
> > Hmm, interesting idea...
> 
> OK, more detailed. I allow only absolute pathes in $SHELL and don't allow any *csh.
> If superuser then only shells from [/usr][/local]/bin are considered trusted shells.
> If not superuser shells from other directories are allowed, but if uid != euid or 
>gid != egid the shell and the directory where it resides must not be writable.
> Fall back value is /bin/sh.

But, uhm, what exactly is a `superuser' from your point of view?
We don't have that concept except for SYSTEM as _the_ user which
is able to change user context w/o changing security policies.
And on 9x/Me...

> > > - utime() doesn't mark st_ctime for update
> > 
> > Really?  I would never think so when inspecting the source code.
> 
> Has this been fixed meanwhile? Also other calls like chmod() must mark st_ctime for 
>update. My patches are not complete here.

I have searched in the ChangeLog since I'm thinking to have a vague
memory about soemthing related.  Unfortunately I couldn't find that.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Fleischer, Karsten (K.)]

> > Glenn found some test cases where mmap() failed and has 
> also written a nice test program. I will get this to you later.
> > He also states that the value returned by getpagesize() 
> must conform to mmap() alignment by definition in the SUSv2. 
> I'm not quite sure about that, though.
> 
> See my reply to Robert.  It's just an example.  I don't have another
> reason at hand now but we already considered that change and we
> actually *had* reasons to avoid it.  Perhaps Chris can help out here.

OK.

> But, uhm, what exactly is a `superuser' from your point of view?
> We don't have that concept except for SYSTEM as _the_ user which
> is able to change user context w/o changing security policies.
> And on 9x/Me...

Does the SYSTEM user have uid == 0? Does any user have an uid == 0?
If not then it does not matter anyway. I can just leave it as it is.
If in future some superuser concept might find it's way into Cygwin, this $SHELL stuff 
is safe already.


Oh, I forgot to mention that I changed the rename() logic a bit.
rename("a", "b"): If "a" is really "a.exe" it is renamed to "b.exe"
rename("a", "b.suffix"): If "a" is really "a.exe" it is nevertheless renamed to 
"b.suffix". The ".suffix" implies that the user knows what she's doing.
rename("a.exe", "b"): The ".exe" suffix implies that the user knows what she's doing, 
too, so "a.exe" is renamed to "b"

This also holds for link().

I've taken that from UWIN, too.

Karsten


--
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: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 10:09:59AM -0500, Fleischer, Karsten (K.) wrote:
> > But, uhm, what exactly is a `superuser' from your point of view?
> > We don't have that concept except for SYSTEM as _the_ user which
> > is able to change user context w/o changing security policies.
> > And on 9x/Me...
> 
> Does the SYSTEM user have uid == 0? Does any user have an uid == 0?
> If not then it does not matter anyway. I can just leave it as it is.
> If in future some superuser concept might find it's way into Cygwin, this $SHELL 
>stuff is safe already.

The problem is that by default the "Everyone" group has the uid and
gid 0.  The user can change that in the passwd and group files.
You just should stick with uid/gid 18 for the user SYSTEM.  Are you
familar with the NT security concept?  If you want to have a rough
insight how that's used in Cygwin, I suggest reading

  http://cygwin.com/cygwin-ug-net/ntsec.html

It's rather old and a bit badly maintained but it's basically still
correct.

> Oh, I forgot to mention that I changed the rename() logic a bit.
> rename("a", "b"): If "a" is really "a.exe" it is renamed to "b.exe"
> rename("a", "b.suffix"): If "a" is really "a.exe" it is nevertheless renamed to 
>"b.suffix". The ".suffix" implies that the user knows what she's doing.
> rename("a.exe", "b"): The ".exe" suffix implies that the user knows what she's 
>doing, too, so "a.exe" is renamed to "b"
> 
> This also holds for link().
> 
> I've taken that from UWIN, too.

Yup, that sounds reasonable to discuss.

One general question, though.  How do these changes to handle things
like U/WIN collide with the propietary U/WIN license?  We don't want
to have problems with AT&T suddenly.  Especially we don't want to
have sources taken from U/WIN.

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 04:28:54PM +0100, Corinna Vinschen wrote:
> 
>   http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> It's rather old and a bit badly maintained but it's basically still
> correct.

Unfortunately, it doesn't contain any word about the ability to change
user context w/o password through the seteuid() call as it's provided
by Cygwin since 1.3.x.  *sigh* I hate to work on documentation...

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: telnet cannot see mount drive

[Robert Praetorius]

 I have a crude, tacky workaround for this that I've been using with the AT 
command 
since the NT 3.51 days.  It fits much better with cron than with telnet (although 
perhaps something could be hacked up for telnet, too).

 Anyway, I have a little .BAT file in my Startup folder* that (implicitly) starts 
CMD.EXE and runs a little loop that, once a minute,  looks for .BAT files in my 
f:\Batch directory.  Whenever it finds one, it moves it to \Batch\Started and start up 
another CMD.EXE.

 Because this CMD.EXE was started in the context of my Windows NT login session, 
it 
has access to the drives I see interactively.  I can write batch jobs using the same 
drive mappings and not have to think about it.  My batch jobs, instead of being 
submitted directly, just put a stub in f:\Batch that points to the real job.

 I suppose, on the same principle, one could start a sort of CMD server in this 
context which would receive input/send output on a pipe, mailslot, whatever.  Whether 
it would perform reasonably for use with telnet, seems iffy, but vaguely possible. . .

 I imagine someone who knew the guts of NT pretty well could come up with a 
snappier solution, but that wouldn't be me.:-)  Meanwhile, what I have works for what 
I 
need it for.

*in NT 3.51, this seemed to need to be started as a login script, but
 NT 4.0 is happy if it's run from the Startup folder, which is a little
 less messy to set up.

> On Thu, Jan 10, 2002 at 01:07:35PM +, David Starks-Browning wrote:
> > On Thursday 10 Jan 02, Corinna Vinschen writes:
> > > Did you see my previous mail related to using network drives
> > > in ssh sessions, David?  That's the crucial stuff.
> > 
> > Probably, but I may have to dig around my archives.  I'll let you know
> > if I can't find it.
> 
> My bad.  I meant "cron", not "ssh".  The problem is the same.
> The message is http://cygwin.com/ml/cygwin/2002-01/msg00607.html
> from today.




start /low /i /min F:\Users\RPraetorius\BatchLoop.bat
exit


path
:again
for %%b in (f:\Batch\*.bat) do call :BatchExecute %%b
sleep 60
goto again
:BatchExecute
del f:\Batch\Started\%~nx1
move %1 f:\Batch\Started\%~nx1
start /i cmd /c "f:\Batch\Started\%~nx1 > f:\Batch\Logs\%~n1.log 2>&1"

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

    File information ---
 File:  SubmitToBatchLoop.pl
 Date:  2 Sep 1998, 0:17
 Size:  484 bytes.
 Type:  Program-source



SubmitToBatchLoop.pl
Description: Binary data

--
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: ksh on cygwin

[Fleischer, Karsten (K.)]

> The problem is that by default the "Everyone" group has the uid and
> gid 0.  The user can change that in the passwd and group files.

OK, I'll take that out again then.

> You just should stick with uid/gid 18 for the user SYSTEM.  Are you
> familar with the NT security concept?  If you want to have a rough
> insight how that's used in Cygwin, I suggest reading
> 
>   http://cygwin.com/cygwin-ug-net/ntsec.html
> 
> It's rather old and a bit badly maintained but it's basically still
> correct.

I've read it a long time ago...

> One general question, though.  How do these changes to handle things
> like U/WIN collide with the propietary U/WIN license?  We don't want
> to have problems with AT&T suddenly.  Especially we don't want to
> have sources taken from U/WIN.

No sources were taken from UWIN or from the AST libraries.
I'm using UWIN quite a lot here at Ford, because I needed to use the MSVC++ compiler.
I've found many bugs in UWIN and I have email contact with David and Glenn on a 
regular basis. They asked me if I could help out porting AST to Cygwin, because they 
didn't want to touch (or even read) the Cygwin sources for obvious copyright problems.
The concepts I've taken from UWIN were explained to me by them verbally, so no source 
code involved here.
Other portions are rewritten from the AST sources (which are open source, see 
http://www.research.att.com/sw/license/ast-open.html).
I don't know if this license and the GPL collide, so I've rewritten the code from 
memory after looking at the sources.
The differences are substancial, so no problem here either.

Karsten

--
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: bash/cmd CTRL-C problem...

[Christopher Faylor]

On Thu, Jan 10, 2002 at 06:59:54PM +1100, Robert Collins wrote:
>> I was going back over this thread before checking in a change to see if
>> I'd missed something.
>>
>> I just realized that I didn't address this concern.  Don't know if it
>> matters but...
>>
>> The difference between the SIG_IGN way and the "return TRUE" way is
>> that the SIG_IGN way stops the current process from responding to
>> a cygwin signal but still lets it respond to a Windows "signal".  That
>> means that the code in ctrl_c_handle can do its job, if it has to.
>
>Huh? I actually did the reverse - returning TRUE only prevented
>responding to a windows signal, but allowed responding to a cygwin
>signal.

Yep.  Wrong behavior.  The stub should respond to windows signals
while the child is initializing.  Remember this discussion?

>>If we always "return TRUE" in the exec case, then there will be some
>>situations where the SIGINT is not delivered to the rest of the process
>>group since the code in ctrl_c_handler would be short circuited.
>
>I don't believe that is the case: Every console process attached to
>that console independently recieves the windows signal.  Only one has
>been disabled.  So the execing process's children will still recieve
>the windows signals and the cygwin signals.

The newly executed subprocess may not have yet set up ctrl_c_handler so
it will not do anything but die when CTRL-C comes in.  The stub will
ignore the CTRL-C.  That means that the rest of the processes in the
process group will not receive a CTRL-C.

>> My SIG_IGN "solution" is wrong, too, though.  The SIG_IGN would be
>> inherited by the exec'ed process.  Then the execed process would never
>> see a cygwin SIGINT signal.
>
>Yes. I still believe that return TRUE is a good solution... but if
>you've solved the obvious behaviour I'll be quite now :}.

I guess I'm having a hard time understanding why I couldn't just say
"race" and have you understand that there is a race but I'll stop
now, too.

cgf

--
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: ksh on cygwin

[Corinna Vinschen]

On Thu, Jan 10, 2002 at 10:50:46AM -0500, Fleischer, Karsten (K.) wrote:
> >   http://cygwin.com/cygwin-ug-net/ntsec.html
> > 
> > It's rather old and a bit badly maintained but it's basically still
> > correct.
> 
> I've read it a long time ago...

I'm feeling flattered. :-)

> > One general question, though.  How do these changes to handle things
> > like U/WIN collide with the propietary U/WIN license?  We don't want
> > to have problems with AT&T suddenly.  Especially we don't want to
> > have sources taken from U/WIN.
> 
> No sources were taken from UWIN or from the AST libraries.
> I'm using UWIN quite a lot here at Ford, because I needed to use the MSVC++ compiler.
> I've found many bugs in UWIN and I have email contact with David and Glenn on a 
>regular basis. They asked me if I could help out porting AST to Cygwin, because they 
>didn't want to touch (or even read) the Cygwin sources for obvious copyright problems.
> The concepts I've taken from UWIN were explained to me by them verbally, so no 
>source code involved here.
> Other portions are rewritten from the AST sources (which are open source, see 
>http://www.research.att.com/sw/license/ast-open.html).
> I don't know if this license and the GPL collide

IANAL but AFAIK, they collide.

> , so I've rewritten the code from memory after looking at the sources.
> The differences are substancial, so no problem here either.

I think that's ok.  "Rewritten" should be enough.  IANAL, IANAL, ...

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Developermailto:[EMAIL PROTECTED]
Red Hat, Inc.

--
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: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 02:45:51PM +0100, Corinna Vinschen wrote:
>> Is it OK to send patches to 1.3.3-2 or should I move them to 1.3.6 first?
>
>I would suggest to move them to the latest from CVS.  If you're
>always working against the latest from CVS you don't get hit too
>much by changes from other people.

Yes.  This is a requirement.  Latest CVS.

cgf

--
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: telnet cannot see mount drive

[David Starks-Browning]

On Thursday 10 Jan 02, Corinna Vinschen writes:
> On Thu, Jan 10, 2002 at 01:07:35PM +, David Starks-Browning wrote:
> > On Thursday 10 Jan 02, Corinna Vinschen writes:
> > > Did you see my previous mail related to using network drives
> > > in ssh sessions, David?  That's the crucial stuff.
> > 
> > Probably, but I may have to dig around my archives.  I'll let you know
> > if I can't find it.
> 
> My bad.  I meant "cron", not "ssh".  The problem is the same.

Oh, yes!  Those I am definitely aware of.

David


--
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: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 05:03:26PM +0100, Corinna Vinschen wrote:
>> , so I've rewritten the code from memory after looking at the sources.
>> The differences are substancial, so no problem here either.
>
>I think that's ok.  "Rewritten" should be enough.  IANAL, IANAL, ...

If you've actually looked at the UWIN sources, this is not enough.  IANAL
either, but I believe that this means you've been tainted.  That means
that we can't use your patches.  Sorry.

I hope I am misinterpreting what you said incorrectly...

cgf

--
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: ksh on cygwin

[Fleischer, Karsten (K.)]

> If you've actually looked at the UWIN sources, this is not 
> enough.  IANAL
> either, but I believe that this means you've been tainted.  That means
> that we can't use your patches.  Sorry.

I've never had the chance to look at the UWIN sources. It's proprietary.
As I said before, the UWIN developers explained the concepts verbally to me, no source 
code involved.

The AST tools and libraries, which form the basis for the UWIN _tools_ (not the UNIX 
emulation itself) are open source. I rewritten some things from those sources (but 
from memory).

> I hope I am misinterpreting what you said incorrectly...

:-P

Karsten

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

How to return NaN?

[Underwood, Jonathan]

Hi

Sorry for the slightly off topic question, but i was wondering how best to
have a function of type double return NaN in C. I'm using the cygwin
environment for developement (so gcc), but am looking for the most portable
solution.

Thanks

Jonathan.

--
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: libpng problems with png_info_init, png_read_destroy

[Charles Wilson]

'man libpng' reveals:

png_read_init ---> png_create_read_struct
png_write_init ---> png_create_write_struct
png_info_init --> png_create_info_struct
png_read_destroy --> png_destroy_read_struct
png_write_destroy --> png_destroy_write_struct

The old methods have been deprecated.  They are currently marked 
INTERNAL and are not exported by the DLL, but  will be completely 
removed in the libpng-2.0.0 release.

If you MUST continue to use the old methods, then you should 
-DPNG_STATIC -DZLIB_STATIC when compiling, and -static when linking.

--Chuck

Gerrit P. Haase wrote:

>  Jean,
> 
> 2002-01-10 14:01:30, du schriebst:
> 
> 
>>Perhaps this time I can ofer my two cents worth ;)
>>
> 
Hallo Cygwinners,

I'm getting these undefined references when linking against
libjpeg import lib:

>>>Waddaza want?  Wanted to say> libpng import lib
>>>
>>>
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:79: undefined reference to 
>`png_read_destroy'
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:94: undefined reference to 
>`png_info_init'
/stuff/test/mMosaic-src-3.7.2/src/readPNG.c:286: undefined reference to 
>`png_read_destroy'

Are there a known workaround besides linking the libs statically?

> 
>>Since you are using .c, I presume that you are including the source
>>and that the .c files do not contain the declerations, but only the
>>implmentations of the code. Errors like your's if freuently
>>encountered when forgetting to include a header file. Make sure that
>>you are not looking for /stuff/test/mMosaic-src-3.7.2/src/readPNG.h
>>instead.
>>
> 
>>It appears that you want to rather include the .h files and add the
>>relevant lib in your link-line.
>>
> 
> No, the problem is that these functions are private and are not exported
> from the dll lib, so I need to link libpng staticallz to get the
> functions, but I want to link against the dynamic lib.
> 
> I found one reference in the archives how to substitute png_info_init
> with png_create_info_struct() but nothing about png_read_destroy().
> 
> 
> Anyway, thank you for your comment, please keep communication on the
> cygwin list as long as it is ontopic there.
> 
> Gerrit
> 



--
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: How to return NaN?

[Robinow, David]

 It's a bit more than slightly off topic.

Try http://groups.google.com/groups?hl=en&lr=&safe=off&group=comp.lang.c

-Original Message-
From: Underwood, Jonathan [mailto:[EMAIL PROTECTED]]
Subject: How to return NaN?
Sorry for the slightly off topic question, but i was wondering how best to
have a function of type double return NaN in C. I'm using the cygwin
environment for developement (so gcc), but am looking for the most portable
solution.

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

1.3.6 ssh Write failed: The descriptor is a file, not a socket

[Daryl Spartz]

The subject line problem, reported back in November, 2001 was stated to be
fixed in message archive post
http://www.cygwin.com/ml/cygwin/2001-11/msg00694.html by Jeff Mincy. I am
running 1.3.6 and STILL have the problem (running on win2k)

$ uname -a
CYGWIN_NT-5.0 POOLSIDE 1.3.6(0.47/3/2) 2001-12-08 17:02 i686 unknown

This problem has been around for a long time, last known to work on cygwin
version 1.3.2.

Daryl

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

RE: RXVT Font Question

[fergus at bonhard dot uklinux dot net]

Try

c:\Cygwin\bin\rxvt.exe -fn "Fixedsys" -tn cygwin -e /bin/bash --login -i

which gives a nice squarecut font and is (I think) the default for Windows
telnet and loads of other MS stuff.

Fergus


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

resize command hangs from ssh session

[James Garrison]

I've searched the archive and can't seem to find anything
applicable.  My problem:

Win2000SP2 CYGWIN_NT-5.0 1.3.6(0.47/3/2) 2001-12-08 17:02 i686 unknown
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

Open a Cygwin command shell (my default is configured to 80x45)
ssh to a RH Linux 7.1 box
Change the window size to, say, 80x60
Run the 'resize' command (on linux host)

The text cursor jumps to the bottom-right corner of the window
(this is normal) and just stays there (this is not normal).
resize never returns.  This behavior ALWAYS happens even if
I don't physically resize the window (i.e. run resize
immediately after logging in and it still hangs).

I've tried setting TERM=ansi, TERM=vt100 and TERM=cygwin
in the Linux shell with identical results.

If I logout (back to cygwin shell) and re-ssh from
the resized (80x60) window everything works and the
COLUMNS and LINES environment variables are correctly set.

As I understand it, resize sends a specific terminal control
sequence that requests the hardware to reply with the current
size.  I assume that either cygwin's bash isn't playing just
right, or something gets garbled over ssh.

As a side note, I tried running resize locally (in the
cygwin bash shell) and it fails looking for cygncurses5.dll,
which is not in any of my bin directories.  I did find
cygncurses6.dll in /usr/bin.  Is this related or just a
coincidence?

Suggestions on how to debug this further?

-- 
James GarrisonAthens Group, Inc.
mailto:[EMAIL PROTECTED]5608 Parkcrest Dr
http://www.athensgroup.comAustin, TX 78731
PGP: RSA=0x92E90A3B DH/DSS=0x498D331C (512) 345-0600 x150



--
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: resize command hangs from ssh session

[Larry Hall (RFK Partners, Inc)]

At 01:08 PM 1/10/2002, James Garrison wrote:
>I've searched the archive and can't seem to find anything
>applicable.  My problem:
>
>Win2000SP2 CYGWIN_NT-5.0 1.3.6(0.47/3/2) 2001-12-08 17:02 i686 unknown
>OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
>
>Open a Cygwin command shell (my default is configured to 80x45)
>ssh to a RH Linux 7.1 box
>Change the window size to, say, 80x60
>Run the 'resize' command (on linux host)
>
>The text cursor jumps to the bottom-right corner of the window
>(this is normal) and just stays there (this is not normal).
>resize never returns.  This behavior ALWAYS happens even if
>I don't physically resize the window (i.e. run resize
>immediately after logging in and it still hangs).
>
>I've tried setting TERM=ansi, TERM=vt100 and TERM=cygwin
>in the Linux shell with identical results.
>
>If I logout (back to cygwin shell) and re-ssh from
>the resized (80x60) window everything works and the
>COLUMNS and LINES environment variables are correctly set.
>
>As I understand it, resize sends a specific terminal control
>sequence that requests the hardware to reply with the current
>size.  I assume that either cygwin's bash isn't playing just
>right, or something gets garbled over ssh.
>
>As a side note, I tried running resize locally (in the
>cygwin bash shell) and it fails looking for cygncurses5.dll,
>which is not in any of my bin directories.  I did find
>cygncurses6.dll in /usr/bin.  Is this related or just a
>coincidence?
>
>Suggestions on how to debug this further?


Did you see this?

http://cygwin.com/ml/cygwin/2002-01/msg00212.html

Is it applicable?



Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 11:18:04AM -0500, Fleischer, Karsten (K.) wrote:
>>If you've actually looked at the UWIN sources, this is not enough.
>>IANAL either, but I believe that this means you've been tainted.  That
>>means that we can't use your patches.  Sorry.
>
>I've never had the chance to look at the UWIN sources.  It's
>proprietary.  As I said before, the UWIN developers explained the
>concepts verbally to me, no source code involved.
>
>The AST tools and libraries, which form the basis for the UWIN _tools_
>(not the UNIX emulation itself) are open source.  I rewritten some
>things from those sources (but from memory).
>
>>I hope I am misinterpreting what you said incorrectly...
>
>:-P

I'm not sure but I don't think it matters if the sources are
proprietary.  Maybe this is getting incredibly picky but if you adapted
algorithms from other non-GPL compliant programs then that is probably
an issue, too.

This wouldn't be an issue for the Berkeley license, though.  I don't know
what the AST tools use for licensing.

cgf

--
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: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 03:37:41PM +0100, Corinna Vinschen wrote:
>On Thu, Jan 10, 2002 at 09:13:01AM -0500, Fleischer, Karsten (K.) wrote:
>>Glenn found some test cases where mmap() failed and has also written a
>>nice test program.  I will get this to you later.  He also states that
>>the value returned by getpagesize() must conform to mmap() alignment by
>>definition in the SUSv2.  I'm not quite sure about that, though.
>
>See my reply to Robert.  It's just an example.  I don't have another
>reason at hand now but we already considered that change and we
>actually *had* reasons to avoid it.  Perhaps Chris can help out here.

Sorry, I don't remember the discussion.

>>>We have some vfork() changes in the meantime and even ash had an
>>>related error which should be fixed.
>>
>>Maybe we fixed the same error.  I'll send you the details.
>
>Please compare with the current CVS.  Vfork() isn't in my expertise.
>
- use the contents of $SHELL instead of /bin/sh for
>>>execvp()/execlp() and system() (with some additional checks, e.g.  do
>>>not use a csh, use only 'trusted' shells from /bin, /usr/bin,
>>>/usr/local/bin etc.).  This allows the user to select his favorite
>>>shell manually, so no more "copy /bin/bash to /bin/sh" troubles.  (This
>>>is also from UWIN).
>>>
>>>Hmm, interesting idea...
>>
>>OK, more detailed.  I allow only absolute pathes in $SHELL and don't
>>allow any *csh.  If superuser then only shells from [/usr][/local]/bin
>>are considered trusted shells.  If not superuser shells from other
>>directories are allowed, but if uid != euid or gid != egid the shell
>>and the directory where it resides must not be writable.  Fall back
>>value is /bin/sh.
>
>But, uhm, what exactly is a `superuser' from your point of view?  We
>don't have that concept except for SYSTEM as _the_ user which is able
>to change user context w/o changing security policies.  And on 9x/Me...

It sounds like all of this is pretty non-standard, AFAICT.  I can see
why you'd do something like this but I don't think there is any reason
to divert cygwin in this direction at this point in its life.  It's
a pretty major change.

cgf

--
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: Setting up user mode cron

[Andrew DeFaria]

Anyway, cron has no access to them. It's running under SYSTEM
account which has only access to publicly available net drives, that
is, drives which are available w/o any form of authentication
required. The forked cron jobs are running in the same logon session
even if they are running under another user account. Keep in mind
that the user context has been changed w/o asking for logon
credentials. This is different from what the native Windows
scheduler does (which requires entering the password). No
credentials, no authenticated network drive access. That's it.

Questions: What is a publicly available net drive? How does one tell if 
it is publicly available vs. non publicly available?

For example, I can run //sonscentral/common/clearcase/bin/update_view 
but I cannot run //sonscentral/users/adefaria/bin/update_view. I suspect 
the former is publicly available while the latter is not publicly 
available but I'd like to know how I tell the difference.

Seems to me that this is a major stumbling block for cron that severely 
limits it's usefulness. Given that Cygwin does not have su capability 
and login doesn't work from a shell (only for telnet, rlogin stuff) 
there appears to be no way for cron to effectively, really switch to 
another user's credentials such that a user mode cron is truly available 
and useful. It is not uncommon to have user's home directories on a 
network share. It is also very natural for users to have scripts to 
perform functions and want to schedule such functions via cron as well 
as to perhaps log output from such scripts to "natural" places like the 
user's home directory which would be a "network place" therefore "off 
limits" to cron. IOW I guess what I'm saying is that *something* should 
be done (I know you can see this as whining and perhaps it is. But it's 
whining for a good cause! :-)

This cron seems to support setting a MAILTO environment variable to tell 
cron where to mail output in case of errors. Could it not simply 
additionally support USERNAME and PASSWD environment variables that, if 
present in the crontab would cause cron to change user context with 
asking for logon credentials? Of course of concern would be the possibly 
cleartext PASSWD. Perhaps PASSWD could be required to be encrypted like 
that usually in bona fide Unix /etc/passwd (/etc/shadow) files. It's 
just a thought of a possible workaround to a possibly bad situation.



--
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: pdksh on windows compiles no but doesn't work?

[Leigh Hebblethwaite]

David,

I have pdksh working. I had the same problems as you.

The 'make check' action runs a perl script. The perl script requires some .ph files. 
These .ph files are perly versions of your system's .h files.

I made the .ph files. However, I had to hack then a bit to get 'make check' to work. 
As usual I did this with taking many notes. I can supply you with some instructions if 
you wish.

Alternative approach #1. I noticed in the pdksh readme files that there is an 
alternative way of running the tests. I didn't look into it in any depth as I'd 
already got 'make check' running.

Alternative approach #2. 'make check' found a number of failures. All but one of these 
were expected, apparently. The other one had a comment saying that ksh88 also fails on 
it, so I didn't think it was too important.

Since I installed pdksh I've had no problems. I haven't been thrashing it though.

Leigh Hebblethwaite, Consultant

Transoft Ltd, 5J Langley Business Centre, Station Road, Langley, Slough, SL3 8DS 
England
Tel: +44 (0)1753 778000 Fax: +44 (0)1753 773050
Direct Tel: +44 (0)1753 778020  Direct Fax: N/A
Mobile: +44 (0)7801 412331

Offices also in Atlanta GA, San Diego CA and Dayton OH in the USA.
P.S. Please check our web site for more information on Transoft www.transoft.com

To receive copies of 'Headlines' - our email information newsletter - please click the 
link below 
www.transoft.com/contact/headlines_signup.htm

Transoft is a leading international provider of application assembly, transformation 
and integration solutions. The Transoft Intelligent Adapters enable existing critical 
business application functions to be easily exposed and re-used as application and Web 
services, to build new scalable, integrated (e)business applications faster and with 
less risk.



--
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: resize command hangs from ssh session

[James Garrison]

Larry Hall (RFK Partners, Inc) wrote:

> At 01:08 PM 1/10/2002, James Garrison wrote:
> 
>>I've searched the archive and can't seem to find anything
>>applicable.  My problem:
[snip]


> 
> Did you see this?
> 
> http://cygwin.com/ml/cygwin/2002-01/msg00212.html
> 
> Is it applicable?

I'm not sure.  If the resize command relies on OOB transmission
of the terminal dimensions, then it's most likely the cause.
I'm not enough of a tty/ldisc/protocol hacker to know the answer.

Thanks for the pointer, though.  I would never have found it
by myself :-)

-- 
James GarrisonAthens Group, Inc.
mailto:[EMAIL PROTECTED]5608 Parkcrest Dr
http://www.athensgroup.comAustin, TX 78731
PGP: RSA=0x92E90A3B DH/DSS=0x498D331C (512) 345-0600 x150



--
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: Newbie Question

[Paul Johnson]

To the best of my knowledge, there is no way to set >25 lines on a DOS box
using Win98.  I was hoping that Cygwin itself had such a mechanism, or that
there was a third party tool in use.

Best Regards,

Paul

> -Original Message-
> From: Dylan Cuthbert [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 09, 2002 6:06 PM
> To: Paul Johnson; [EMAIL PROTECTED]
> Subject: Re: Newbie Question
>
>
> Just right click on the cygwin shell icon and click Properties, then alter
> the settings just as you would for a DOS box.
>
> Regards
> -
> Q-Games, Dylan Cuthbert.
> http://www.q-games.com
>
> - Original Message -
> From: "Paul Johnson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, January 10, 2002 10:52 AM
> Subject: Newbie Question
>
>
> > Having just installed Cygwin under Win98, I'm curious to know if I can
> > change the screen height to 50 lines (or some other, larger, number).
> >
> > TIA,
> >
> > Paul
> >
> >
> > --
> > 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: Setting up user mode cron

[Larry Hall (RFK Partners, Inc)]

At 01:45 PM 1/10/2002, Andrew DeFaria wrote:
>Anyway, cron has no access to them. It's running under SYSTEM
>account which has only access to publicly available net drives, that
>is, drives which are available w/o any form of authentication
>required. 



>No credentials, no authenticated network drive access. That's it.
>
>Questions: What is a publicly available net drive? How does one tell if it is 
>publicly available vs. non publicly available?

I think the above quote from Corinna answers this question.  In other words,
if Windows would ask you to identify yourself if you browsed to this share
as a user the domain doesn't know about, then you'll see a problem when 
trying to use this share with cron (and some other) tools.

Someone will correct me if I'm wrong. ;-)


Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: Newbie Question

[Paul Johnson]

> What would really be nice is if "newbies" actually read the message that
> they get when they subscribe to the list which contains the following:
>
>   Before posting, please check out following links:
>
>   The Cygwin Web Sitehttp://cygwin.com/
>   The Cygwin FAQ http://cygwin.com/faq/
>   Cygwin Bug Reporting   http://cygwin.com/bugs.html
>   The Mailing List Archive   http://cygwin.com/lists.html
>   Generic Web Searching  http://google.com/
>   (type in cygwin plus your search term)

I did all of the above before asking my question.  I checked the FAQ and
documentation and did several searches.  I did not find an answer to my
question, and have still not seen an answer to my question.

Paul


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

Console size on W9x - was RE: Newbie Question

[Larry Hall (RFK Partners, Inc)]

As a newbie, the first thing to learn is to search the Cygwin site and
the mail archives first for answers to questions like these.  Last time
I looked, Win9x could set a window size up to 50 lines.  Regardless, if
you look at the Cygwin web site you'll find references to Chuck Wilson's
site where you can get 'consize' if you like using the DOS prompt.  
Otherwise, you can use 'rxvt' which comes with Cygwin.  The email 
archives is literally packed with discussions on this subject.  You 
should be able to get yourself up-to-speed on this issue by looking
there.

Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX



At 01:55 PM 1/10/2002, Paul Johnson wrote:
>To the best of my knowledge, there is no way to set >25 lines on a DOS box
>using Win98.  I was hoping that Cygwin itself had such a mechanism, or that
>there was a third party tool in use.
>
>Best Regards,
>
>Paul
>
> > -Original Message-
> > From: Dylan Cuthbert [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, January 09, 2002 6:06 PM
> > To: Paul Johnson; [EMAIL PROTECTED]
> > Subject: Re: Newbie Question
> >
> >
> > Just right click on the cygwin shell icon and click Properties, then alter
> > the settings just as you would for a DOS box.
> >
> > Regards
> > -
> > Q-Games, Dylan Cuthbert.
> > http://www.q-games.com
> >
> > - Original Message -
> > From: "Paul Johnson" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, January 10, 2002 10:52 AM
> > Subject: Newbie Question
> >
> >
> > > Having just installed Cygwin under Win98, I'm curious to know if I can
> > > change the screen height to 50 lines (or some other, larger, number).
> > >
> > > TIA,
> > >
> > > Paul
> > >
> > >
> > > --
> > > 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/


--
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: ksh on cygwin

[Christopher Faylor]

On Thu, Jan 10, 2002 at 01:40:19PM -0500, Christopher Faylor wrote:
>On Thu, Jan 10, 2002 at 11:18:04AM -0500, Fleischer, Karsten (K.) wrote:
>>>If you've actually looked at the UWIN sources, this is not enough.
>>>IANAL either, but I believe that this means you've been tainted.  That
>>>means that we can't use your patches.  Sorry.
>>
>>I've never had the chance to look at the UWIN sources.  It's
>>proprietary.  As I said before, the UWIN developers explained the
>>concepts verbally to me, no source code involved.
>>
>>The AST tools and libraries, which form the basis for the UWIN _tools_
>>(not the UNIX emulation itself) are open source.  I rewritten some
>>things from those sources (but from memory).
>>
>>>I hope I am misinterpreting what you said incorrectly...
>>
>>:-P
>
>I'm not sure but I don't think it matters if the sources are
>proprietary.  Maybe this is getting incredibly picky but if you adapted
>algorithms from other non-GPL compliant programs then that is probably
>an issue, too.
>
>This wouldn't be an issue for the Berkeley license, though.  I don't know
>what the AST tools use for licensing.

FWIW, I'm checking on this internally now.

cgf

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

CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Alexei Lioubimov]

So,
Is it very difficult to give just a short answer?
Help, please! --
I'm trying to get the solution and sent this questions to cygwin list and to
cvs
list already twice -- but the result is poor -- i got no concrete answer!

But,
I CAN NOT USE ONE OF THE MAIN DEVELOPMENT TOOLS -- CVS,
because "cvs co -r " is not working under Cygwin!!!

I tried a  "cvs co -r mytag myproj" and receive the following:

cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
directory

Is it impossible to checkout a tag or revision if module doesn't
contain Attics?

Regards,
Alexei Lioubimov
[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/

Re: Newbie Question

[Charles Wilson]

Paul Johnson wrote:

> To the best of my knowledge, there is no way to set >25 lines on a DOS box
> using Win98.  I was hoping that Cygwin itself had such a mechanism, or that
> there was a third party tool in use.


consize, and win95cmd or ReactOS-cmd.  See here:

http://www.neuro.gatech.edu/users/cwilson/cygutils/unversioned/consize.

Disclaimer: provided as is, no guarantees, etc etc..

--Chuck


--
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: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Mark Himsley]

On Thu, 10 Jan 2002 22:28:32 +0300 you wrote:

>But,
>I CAN NOT USE ONE OF THE MAIN DEVELOPMENT TOOLS -- CVS,
>because "cvs co -r " is not working under Cygwin!!!
>
>I tried a  "cvs co -r mytag myproj" and receive the following:
>
>cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
>directory
>
>Is it impossible to checkout a tag or revision if module doesn't
>contain Attics?

Assuming that the CVS client is running under cygwin, you do not say if the
CVS server is also running under cygwin or the method you are using to
connect to the CVS server.

-- 
Mark Himsley
In Acton

--
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: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Randall R Schulz]

Alexei,

Beyond the uncalled-for shouting and the demanding tone, there's a paucity 
of information in your cry for help.

Please give is more details about your configuration: Cygcheck, the 
contents of any ".cvsrc" files. Likewise, please say more about what 
specifically you're attempting. Show us your CVSROOT (since you don't show 
a "-d" option). As it is, we don't know if you're using a remove (pserver) 
or local (file system) repository. The output of "type -a cvs" wouldn't 
hurt, since experience shows that people can have multiple installations of 
certain tools, and you could be invoking a non-Cygwin version of the "cvs" 
command.

Etc...

Details! We need more details!

Randall Schulz
Mountain View, CA USA


At 11:28 2002-01-10, Alexei Lioubimov wrote:
>So,
>Is it very difficult to give just a short answer? Help, please! -- I'm 
>trying to get the solution and sent this questions to cygwin list and to 
>cvs list already twice -- but the result is poor -- i got no concrete answer!
>
>But,
>I CAN NOT USE ONE OF THE MAIN DEVELOPMENT TOOLS -- CVS,
>because "cvs co -r " is not working under Cygwin!!!
>
>I tried a  "cvs co -r mytag myproj" and receive the following:
>
>cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
>directory
>
>Is it impossible to checkout a tag or revision if module doesn't
>contain Attics?
>
>Regards,
>Alexei Lioubimov
>[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/

Re: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Matthew Smith]

> So,
> Is it very difficult to give just a short answer?
> Help, please! --
> I'm trying to get the solution and sent this questions to cygwin list and
to
> cvs
> list already twice -- but the result is poor -- i got no concrete answer!

Berating volunteers is probably not going to help your cause.  If someone
had an answer, I'm sure they would have responded to you.  We're not trying
to be mean or anything (well most of us ;-)).

> But,
> I CAN NOT USE ONE OF THE MAIN DEVELOPMENT TOOLS -- CVS,
> because "cvs co -r " is not working under Cygwin!!!
>
> I tried a  "cvs co -r mytag myproj" and receive the following:
>
> cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
> directory
>
> Is it impossible to checkout a tag or revision if module doesn't
> contain Attics?

cvs co -r  works fine for me without Attics.  I don't know what else to
say.

cheers,
-Matt




--
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: Setting up user mode cron

[Polley Christopher W]

You wrote:
>At 01:45 PM 1/10/2002, Andrew DeFaria wrote:
>>Anyway, cron has no access to them. It's running under SYSTEM
>>account which has only access to publicly available net
drives, that
>>is, drives which are available w/o any form of authentication
>>required. 
>
>
>
>>No credentials, no authenticated network drive access. That's
it.
>>
>>Questions: What is a publicly available net drive? How does one
tell if it is publicly available vs. non publicly >available?
>
>I think the above quote from Corinna answers this question.  In
other words,
>if Windows would ask you to identify yourself if you browsed to
this share
>as a user the domain doesn't know about, then you'll see a problem
when 
>trying to use this share with cron (and some other) tools.
>
>Someone will correct me if I'm wrong. ;-)

This seems correct to me, and I would add (or rather expand on how
to become a "user the domain doesn't know about") that to find out what
shares are publicly accessible, you need to log in to your workstation with
unprivileged credentials, for example as \\localmachinedomain\guest (on NT,
use the "User Manager" to see what accounts are defined on your machine).
Accessing a non-public network share will then require you to enter a
domain\userid and password, while a public share will be accessible without
credentials.  I don't know if NT caches userid/password combinations for
network share attempts subsequent to a properly authenticated non-public
share access, so be careful here.

I have used batch files with NT's AT command and run into the same
problem.  My solution was to put a "net use : 
/user:\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: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Charles Wilson]

Alexei Lioubimov wrote:

> So,
> Is it very difficult to give just a short answer?
> Help, please! --
> I'm trying to get the solution and sent this questions to cygwin list and to
> cvs
> list already twice -- but the result is poor -- i got no concrete answer!
> 
> But,
> I CAN NOT USE ONE OF THE MAIN DEVELOPMENT TOOLS -- CVS,
> because "cvs co -r " is not working under Cygwin!!!
> 
> I tried a  "cvs co -r mytag myproj" and receive the following:
> 
> cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
> directory
> 
> Is it impossible to checkout a tag or revision if module doesn't
> contain Attics?


No, it is not impossible.  I do it all the time.  I don't know what your 
problem is -- and I didn't want to pollute the mailing list with "it 
works for me".  Apparently, it works for EVERYONE but you(*), because 
nobody has responded.

(*) this implies a problem with your computers' setup and/or configuration

Lack of response sometimes means no-one has an answer for you.  It 
appears that is the case here.  Sorry.  It is entirely possible you may 
have to (GASP) debug this problem yourself.  You can download the cygwin 
versions of the source code to gdbm and cvs using setup.exe, and then 
follow the directions to rebuild those packages -- but set CFLAGS="-g" 
first, in order to build a debuggable version.

You may even need to build a debuggable version of the cygwin kernel 
(search the mailing list archives for instructions).

Use gdb, and figure out WHY cvs is trying to access Attic, when there is 
no Attic in the project.  That's your first step -- and unfortunately, 
since nobody else seems to be experiencing the problem, nobody else will 
be able to debug it for you.  Including me.

--Chuck
gdbm, cvs maintainer

P.S. I debated whether to send this message at all -- unofficial mailing 
list "policy" seems to be that reposted messages are downgraded, not 
upgraded, in priority.  (IOW, "Why the hell haven't you evil bastards 
answered my question yet" doesn't endear the poster to those with the 
desired information.)  However, you do not seem to understand that -- 
and I've noticed a trend lately in "Answer me dammit" messages on the 
list so I thought a little explanation about why messages sometimes go 
unanswered was justified.

See:
   http://cygwin.com/faq/faq.html -- section entitled: "Posting 
Guidelines (Or: Why won't you/the mailing list answer my questions?)"

   http://www.tuxedo.org/~esr/faqs/smart-questions.html "How to ask 
smart questions"



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

vim and color

[Dan Horne]

Hi All

how do I set up syntax color coding with vim under cygwin? I use gvim in the
Windows environmnt, and that seesm to be working okay. I've looked at the
cygwin doco I could find, and it discusses windows and Unix - I'm not sure
where cygwin fits into the scheme of thngs. For instance, I added a .gvimrc
file to $HOME directory, but it doesn't seem to do anything.

Dan




--
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: vim and color

[Randall R Schulz]

Dan,

Most likely all you need to know is where to put your color scheme files. 
If you're doing it all from Vim's "rc" file, then you need to use the right 
one: "~/.vimrc" / "$HOME/.vimrc". The Cygwin-hosted Vim is a non-GUI, 
Unix-style Vim (just vim or vi), _not_ a GUI, stand-alone one (gvim).

 From what little experience I have, the Vim docs and help system are 
careful to distinguish the graphic from non-graphic Vim configuration 
details. Use the ":help ..." command.

Randall Schulz
Mountain View, CA USA


At 12:03 2002-01-10, Dan Horne wrote:
>Hi All
>
>how do I set up syntax color coding with vim under cygwin? I use gvim in the
>Windows environmnt, and that seesm to be working okay. I've looked at the
>cygwin doco I could find, and it discusses windows and Unix - I'm not sure
>where cygwin fits into the scheme of thngs. For instance, I added a .gvimrc
>file to $HOME directory, but it doesn't seem to do anything.
>
>Dan


--
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: vim and color

[Dan Horne]

Thanks Randall

upon further investigation (and putting .vimrc in my home directory on not
gvimrc doh) I've discovered that color-coding is working if I use the
command window. However, if I use rxvt, I lose color and instead get text
emphasis in bolds and underlines. Obviously, I'm missing something but not
sure what.

Ideas appreciated

Dan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Randall R Schulz
Sent: Friday, January 11, 2002 9:13 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: vim and color


Dan,

Most likely all you need to know is where to put your color scheme files.
If you're doing it all from Vim's "rc" file, then you need to use the right
one: "~/.vimrc" / "$HOME/.vimrc". The Cygwin-hosted Vim is a non-GUI,
Unix-style Vim (just vim or vi), _not_ a GUI, stand-alone one (gvim).

 From what little experience I have, the Vim docs and help system are
careful to distinguish the graphic from non-graphic Vim configuration
details. Use the ":help ..." command.

Randall Schulz
Mountain View, CA USA


At 12:03 2002-01-10, Dan Horne wrote:
>Hi All
>
>how do I set up syntax color coding with vim under cygwin? I use gvim in
the
>Windows environmnt, and that seesm to be working okay. I've looked at the
>cygwin doco I could find, and it discusses windows and Unix - I'm not sure
>where cygwin fits into the scheme of thngs. For instance, I added a .gvimrc
>file to $HOME directory, but it doesn't seem to do anything.
>
>Dan


--
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: vim and color

[Charles Wilson]

Dan Horne wrote:

> Thanks Randall
> 
> upon further investigation (and putting .vimrc in my home directory on not
> gvimrc doh) I've discovered that color-coding is working if I use the
> command window. However, if I use rxvt, I lose color and instead get text
> emphasis in bolds and underlines. Obviously, I'm missing something but not
> sure what.


What does `echo $TERM' say?  "xterm" doesn't support color -- but "rxvt" 
does.  Try:

export TERM=rxvt

when you're using rxvt.  Use TERM=cygwin when you use the 
bash-in-a-command.com window.

--Chuck



--
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: vim and color

[Dan Horne]

Hi

term is set to xterm. If I do ls -l --color (or set the ls alias to do so),
the listing is indeed in colour.

Dan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Charles Wilson
Sent: Friday, January 11, 2002 9:28 AM
To: [EMAIL PROTECTED]
Cc: Randall R Schulz; [EMAIL PROTECTED]
Subject: Re: vim and color




Dan Horne wrote:

> Thanks Randall
>
> upon further investigation (and putting .vimrc in my home directory on not
> gvimrc doh) I've discovered that color-coding is working if I use the
> command window. However, if I use rxvt, I lose color and instead get text
> emphasis in bolds and underlines. Obviously, I'm missing something but not
> sure what.


What does `echo $TERM' say?  "xterm" doesn't support color -- but "rxvt"
does.  Try:

export TERM=rxvt

when you're using rxvt.  Use TERM=cygwin when you use the
bash-in-a-command.com window.

--Chuck



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

FW: service won't start at boottime for w2000(w2k)/xp possible solution

[Ed Eden]

-Original Message-
From: 
Sent: Thursday, January 10, 2002 2:08 PM
To: cygwin (E-mail)
Subject: service won't start at boottime for w2000(w2k)/xp possible
solution



Think i have a solution to the service startup problem for sshd/inetd. 

Try the dependency of lanmanworkstation and see if that does it.


--
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: vim and color

[Charles Wilson]

Dan Horne wrote:

> Hi
> 
> term is set to xterm. If I do ls -l --color (or set the ls alias to do so),
> the listing is indeed in colour.


Because 'ls.exe' is less careful about emitting color codes than vim is. 
  You can even try this:  within vim, type

:se term=rxvt

and the :r a file in.  It should now show up in color.

--Chuck



--
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: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

Earnie Boyd wrote:
> Your wrapper script is a good idea but has the wrong name as has been
> pointed out already.  It needs to be named i386-pc-mingw32-gcc and a
> copy as mingw32-gcc so that when specifying the --host=mingw32 or
> --host=i386-pc-mingw32 the configure script will find it appropriately.
> Of course to do this you also need to do the same for the binutils
> binaries.
>
> Yes, specifying --host without the other parts of the triplet indicates
> a cross build to configure.  You are even warned of this fact.  Specify
> all three to avoid configure from figuring it out on it's own.  You've
> just been lucky enough to not configure a package that cares.  Try
> configuring binutils if you want to see what happens with just
> specifying host.

J. Henning Schwentner wrote:
> Dear Earnie,
>
> I do not get it with the --build switch. Am I not building on
> i686-pc-cygwin? Is it i368-pc-mingw because I use the mingw-headers?
> But I use the cygwin-compiler.
>
> Sorry, but I am confused a bit ...

Earnie, I'm confused too.

The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for
latter versions of autoconf, but it does not work for earlier versions. I
contribute to the OpenLDAP project, specifically its MinGW support. To build
MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and
libtool-1.4.2. As far as I can tell, none of the configure scripts in these
projects conform to the notion of looking for ${host}-gcc or any other
${host}-tool. In these projects, the solution I pointed out works
flawlessly:

CC=mgcc ./configure --host=i686-pc-mingw32

The configure script in regex-0.12 does not even accept the --host switch
(or --target or --build). Instead, it treats the last parameter on the
command line as the "host":

CC=mgcc ./configure i686-pc-mingw32

The configure script in regex-0.12 does not make any real use of this value,
so it doesn't really have any effect on the build.

I originally responded to J. Henning Schwentner, who started this thread. At
this point, I don't remember what he said he was building. However, it's
obvious to me that unless you're building a project with a configure script
built by an up-to-date version of autoconf, none of what you have suggested
will work. Note that the approach I suggested will work in either case, WITH
THE POSSIBLE EXCEPTION (as you have stated) that one runs into trouble
if --build and --target are not specified as well.

This spawns another associated topic. What are the right values for the
triplets (in CURRENT autoconf)? If you're building MinGW binaries in a
Cygwin-hosted environment, it seems to me that you should ONLY
specify --target=i686-pc-mingw32 and let the other two switches resolve
themselves to i686-pc-cygwin. When I build MinGW binaries with Cygwin tools,
I am not using a MinGW-hosted environment or MinGW tools. All of binutils,
for example, are still Cygwin tools, and they DON'T honor the -mno-cygwin
switch. I don't want to symlink those tools either. None of this should
matter as long as GCC produces MinGW binaries. Why should it matter if
configure believes that you're doing a cross-compile. In a loose sense, you
are. This, of course, is a religious argument.

Note that I have tried to only use the --target switch in my projects,
opposed to the --host switch. However, in OpenLDAP and the other related
projects, NONE of the configure scripts handle these switches correctly. I
found that using --host was the best solution for these projects.

Indeed, until the latest version of autoconf makes its way into all projects
as a standard, these switches will need to be examined by the project
builder in order to have context on how to build.

Jon


--
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: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[John Marshall]

On Thu, Jan 10, 2002 at 01:44:28PM -0600, Matthew Smith wrote:
>> I'm trying to get the solution and sent this questions to cygwin list
>> and to cvs list already twice -- but the result is poor -- i got no
>> concrete answer!
> 
> Berating volunteers is probably not going to help your cause.

Indeed.  But what I don't understand is that I thought Alexei asked the
question very well here

http://sources.redhat.com/ml/cygwin/2002-01/msg00172.html

and got a very useful answer here

http://sources.redhat.com/ml/cygwin/2002-01/msg00177.html

and you can see the resulting checkin here

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dir.cc.diff?r1=1.54&r2=1.55&cvsroot=src&f=h

Maybe Alexei just needs to subscribe to the list or remember to read
responses to his messages in the web archives?

John

--
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: CVS 1.11: (reposted many times!) Will anybody answer me about "cvs co -r" bug under cygwin, finally???

[Charles Wilson]

Hmmm...perhaps ESR's Smart Questions document should also state:
   "Do not assume that respondents to your question on a mailing list 
will send the replies directly to you.  Be sure to check the mailing 
list itself -- or the archives if you are not subscribed to it -- for 
replies to your question.

(Hmm...seems like I had another suggestion for ESR that I was supposed 
to forward to him...must dig thru old email...)

--Chuck


John Marshall wrote:

> On Thu, Jan 10, 2002 at 01:44:28PM -0600, Matthew Smith wrote:
> 
>>>I'm trying to get the solution and sent this questions to cygwin list
>>>and to cvs list already twice -- but the result is poor -- i got no
>>>concrete answer!
>>>
>>Berating volunteers is probably not going to help your cause.
>>
> 
> Indeed.  But what I don't understand is that I thought Alexei asked the
> question very well here
> 
>   http://sources.redhat.com/ml/cygwin/2002-01/msg00172.html
> 
> and got a very useful answer here
> 
>   http://sources.redhat.com/ml/cygwin/2002-01/msg00177.html
> 
> and you can see the resulting checkin here
> 
> 
>http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/dir.cc.diff?r1=1.54&r2=1.55&cvsroot=src&f=h
> 
> Maybe Alexei just needs to subscribe to the list or remember to read
> responses to his messages in the web archives?
> 
> John
> 
> --
> 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: Compiling apps to Mingw32 with cygwin

[Robert Collins]

- Original Message -
From: "Jon Leichter" <[EMAIL PROTECTED]>

I hope I don't repeat anything from this thread, I've only been scanning
it lightly.

..
> obvious to me that unless you're building a project with a configure
script
> built by an up-to-date version of autoconf, none of what you have
suggested
> will work. Note that the approach I suggested will work in either
case, WITH
> THE POSSIBLE EXCEPTION (as you have stated) that one runs into trouble
> if --build and --target are not specified as well.

Autoconf 2.13 supports these options - so the configure script doesn't
need to be *that* up to date.

However, the script needs
AC_CANONICAL_BUILD
AC_CANONICAL_HOST
(and if the package generates platform specific output (ie it's an
assembler/compiler etc)
AC_CANONICAL_TARGET
in the configure.in. You may need to add the relevant macros and run
autoconf again.

As for --build, it is automatically detected as long as
AC_CANONICAL_BUILD is in the script. You may get a warning
==
configure: WARNING: If you wanted to set the --build type, don't
use --host.
If a cross compiler is detected then cross compile mode will be
used.
==
This warning is safe IFF you have a cross compiler.

> This spawns another associated topic. What are the right values for
the
> triplets (in CURRENT autoconf)? If you're building MinGW binaries in a
> Cygwin-hosted environment, it seems to me that you should ONLY
> specify --target=i686-pc-mingw32 and let the other two switches
resolve

No. Specify --host. The meaning is clearly documented in the autoconf
documentation.
For clarity:
build - what OS the compilation is running on..
host  - what OS the binaries created should run on.
target - what OS the binaries created should target their output to.

> Note that I have tried to only use the --target switch in my projects,
> opposed to the --host switch. However, in OpenLDAP and the other
related
> projects, NONE of the configure scripts handle these switches
correctly. I
> found that using --host was the best solution for these projects.

--target being the wrong switch, I'm not surprised it didn't do what you
wanted :}.

Rob


--
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: vim and color

[Dan Horne]

Thanks that worked

Dan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Charles Wilson
Sent: Friday, January 11, 2002 9:52 AM
To: [EMAIL PROTECTED]
Cc: Randall R Schulz; [EMAIL PROTECTED]
Subject: Re: vim and color




Dan Horne wrote:

> Hi
>
> term is set to xterm. If I do ls -l --color (or set the ls alias to do
so),
> the listing is indeed in colour.


Because 'ls.exe' is less careful about emitting color codes than vim is.
  You can even try this:  within vim, type

:se term=rxvt

and the :r a file in.  It should now show up in color.

--Chuck



--
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: Copy and Paste into Console

[Randall R Schulz]

Gary,

I was happy to learn about this:

># Make insert actually useful
>"\e[2~": paste-from-clipboard

...since it is not documented via "man readline," "man bash" nor in my 
rather dated hard-copy BASH manual.

However, I now have two questions:

1) Where does one find complete and definitive information on readline as 
implemented / used by BASH.
2) Why does "paste-from-clipboard" stop just before the first newline in 
the clipboard contents while middle-mouse pastes the entire contents? Is 
there another undocumented clipboard pasting readline primitive that pastes 
the entire clipboard? (Running strings on /lib/libreadline.a suggests there 
is not.) Is this a bug, or intended behavior?

Thanks.

Randall Schulz
Mountain View, CA USA


At 21:35 2002-01-09, Gary R. Van Sickle wrote:
>...
>
>Here's what I have for my .inputrc, and it rarely steers me wrong:
>
>
># This file is read by the 'readline' library ...
>
># Make Home work
>"\e[7~": beginning-of-line
>
># Make End work
>"\e[8~": end-of-line
>
># Make Delete work
>"\e[3~": delete-char
>
># Make insert actually useful
>"\e[2~": paste-from-clipboard
>
># Ignore case for the command-line-completion
># functionality.
>set completion-ignore-case On
>
>...
>
>--
>Gary R. Van Sickle


--
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: Compiling apps to Mingw32 with cygwin

[Charles Wilson]

Robert Collins wrote:

> No. Specify --host. The meaning is clearly documented in the autoconf
> documentation.
> For clarity:
> build - what OS the compilation is running on..
> host  - what OS the binaries created should run on.
> target - what OS the binaries created should target their output to.


Thank you thank you thank you.  I have *never* really understood what 
all those were *really* for -- only what I *thought* they were for. 
Guess what -- I was wrong.  I thought (wrongly)

host: what OS the compilation is running on
target: what OS the binaries created should run on
build: And I never understood what this was for.

THANKS for the succinct explanation.  I'm going to tattoo this on my 
arm.  (Well, not really, but you get the idea)

--Chuck



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

No stderr output

[William S Fulton]

Anything sent to stderr does not appear on the terminal. It seems to
disappear into a black hole. I think it started when I was attempting to
redirect stdout and stderr into the same file in the same order it appears
on the console using something like
runme 1>&2 > filename
I tried all sorts of combinations and didn't get it to work :(

Any suggestions for bringing stderr back from the dead?
Thanks.


--
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: Compiling apps to Mingw32 with cygwin

[Jon Leichter]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Robert Collins
> Sent: Thursday, January 10, 2002 1:44 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Compiling apps to Mingw32 with cygwin
>
> Autoconf 2.13 supports these options - so the configure script doesn't
> need to be *that* up to date.
>
> However, the script needs
> AC_CANONICAL_BUILD
> AC_CANONICAL_HOST
> (and if the package generates platform specific output (ie it's an
> assembler/compiler etc)
> AC_CANONICAL_TARGET
> in the configure.in. You may need to add the relevant macros and run
> autoconf again.
>
> As for --build, it is automatically detected as long as
> AC_CANONICAL_BUILD is in the script. You may get a warning
> ==
> configure: WARNING: If you wanted to set the --build type, don't
> use --host.
> If a cross compiler is detected then cross compile mode will be
> used.
> ==
> This warning is safe IFF you have a cross compiler.

Ok. Definitely some misunderstandings on my part. So, I will restate:

For any particular project, the --build, --host, --target switches are not
guaranteed to be work "properly". This will depend on how well configure.in
has been written. In that respect, the project builder STILL needs to
manually check the 'configure' script (or just try to use it and see what
happens).

>
> > This spawns another associated topic. What are the right values for
> > the triplets (in CURRENT autoconf)? If you're building MinGW
> > binaries in a Cygwin-hosted environment, it seems to me that you
> > should ONLY specify --target=i686-pc-mingw32 and let the other
> > two switches resolve.
>
> No. Specify --host. The meaning is clearly documented in the autoconf
> documentation.
> For clarity:
> build - what OS the compilation is running on..
> host  - what OS the binaries created should run on.
> target - what OS the binaries created should target their output to.

Actually, I'm a little unclear. Are you saying that 'target' is for binaries
that you build, which in themselves, generate other binaries? Would an
example of this be GCC? Would I still need to "properly" specify --target if
I wasn't building binaries that generated binaries? Would you then say that
the following is the appropriate set of switches for Cygwin-GCC to produce
MinGW binaries:

--build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32

Can I leave out the --build switch? Will it get automatically resolved? Or
does that ALSO depend on how well configure.in was written? In the configure
scripts I've used, I have consistently seen the 'build' variables get
assigned the same values as the 'host' variables.

> > Note that I have tried to only use the --target switch in my projects,
> > opposed to the --host switch. However, in OpenLDAP and the other
> > related projects, NONE of the configure scripts handle these switches
> > correctly. I found that using --host was the best solution for these
> > projects.
>
> --target being the wrong switch, I'm not surprised it didn't do what you
> wanted :}.
>

Ok. Once I've had my switch questions answered, I will go back and see how
well those switches play in my projects.

Jon


--
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: No stderr output

[Larry Hall (RFK Partners, Inc)]

At 05:07 PM 1/10/2002, William S Fulton wrote:
>Anything sent to stderr does not appear on the terminal. It seems to
>disappear into a black hole. I think it started when I was attempting to
>redirect stdout and stderr into the same file in the same order it appears
>on the console using something like
>runme 1>&2 > filename
>I tried all sorts of combinations and didn't get it to work :(
>
>Any suggestions for bringing stderr back from the dead?


You can check the documentation on this but I expect you'll find you
have a user error.  Try 'runme 2>&1 >filename'.

BTW, this is OT for this list.




Larry Hall  [EMAIL PROTECTED]
RFK Partners, Inc.  http://www.rfk.com
838 Washington Street   (508) 893-9779 - RFK Office
Holliston, MA 01746 (508) 893-9889 - FAX


--
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: Compiling apps to Mingw32 with cygwin

[Robert Collins]

- Original Message -
From: "Jon Leichter" <[EMAIL PROTECTED]>

> > No. Specify --host. The meaning is clearly documented in the
autoconf
> > documentation.
> > For clarity:
> > build - what OS the compilation is running on..
> > host  - what OS the binaries created should run on.
> > target - what OS the binaries created should target their output to.
>
> Actually, I'm a little unclear. Are you saying that 'target' is for
binaries
> that you build, which in themselves, generate other binaries? Would an
> example of this be GCC?

Yes. The way they are used is kinda cool. Imagine that you've got a new
platform (say wince). It's got no gcc at the moment, and the c compiler
you've got for it is brain-dead (can't host a two-stage gcc build). You
do have a C library that should build for it.
What you do is:
build gcc+binutils with --build=here --host=here --target=wince
and then build the C library for that platform. Place those libraries in
an appropriate search location (ie /usr/local/lib/wince :})
then you
build gcc+binutils with --build=here --host=wince --target=wince
and then you copy the resulting binaries to the target platform, and
finally can build
gcc as a native 3 step boot strap, to ensure everything is ok. i.e. (for
completeness)
build gcc+binutils with --build=wince --host=wince --target=wince

> Would I still need to "properly" specify --target if
> I wasn't building binaries that generated binaries? Would you then say
that
> the following is the appropriate set of switches for Cygwin-GCC to
produce
> MinGW binaries:

Target can be safely skipped if you know for sure that the package does
not create platform specific output. I'm not saying 'binaries' here
because there are other forms of platform specific output that may
exist.

> --build=i686-pc-cygwin --host=i686-pc-mingw32 --target=i686-pc-mingw32

Yes, that should work. GCC will look for a i686-pc-mingw32 cross
compiler.

> Can I leave out the --build switch? Will it get automatically
resolved? Or

Thats what I said :}. I was wrong (I've just rechecked).

In theory I'm right, but for backward compatability, if you specify
host, but not build, then build is set to host. This is (obviously)
wrong and will eventually get removed. For now specify both build and
host explicitly. (which is a bummer for cross- scripts (because the user
must then know what build is, or the script must duplicate what
config.guess and config.sub do.).

> does that ALSO depend on how well configure.in was written? In the
configure
> scripts I've used, I have consistently seen the 'build' variables get
> assigned the same values as the 'host' variables.

You've seen broken scripts then. There may well be brain damaged scripts
around.

See http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC117

Rob


--
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: Compiling apps to Mingw32 with cygwin

[Earnie Boyd]

Jon Leichter wrote:
> 
> Earnie Boyd wrote:
> > Your wrapper script is a good idea but has the wrong name as has been
> > pointed out already.  It needs to be named i386-pc-mingw32-gcc and a
> > copy as mingw32-gcc so that when specifying the --host=mingw32 or
> > --host=i386-pc-mingw32 the configure script will find it appropriately.
> > Of course to do this you also need to do the same for the binutils
> > binaries.
> >
> > Yes, specifying --host without the other parts of the triplet indicates
> > a cross build to configure.  You are even warned of this fact.  Specify
> > all three to avoid configure from figuring it out on it's own.  You've
> > just been lucky enough to not configure a package that cares.  Try
> > configuring binutils if you want to see what happens with just
> > specifying host.
> 
> J. Henning Schwentner wrote:
> > Dear Earnie,
> >
> > I do not get it with the --build switch. Am I not building on
> > i686-pc-cygwin? Is it i368-pc-mingw because I use the mingw-headers?
> > But I use the cygwin-compiler.
> >
> > Sorry, but I am confused a bit ...
> 
> Earnie, I'm confused too.
> 

Using `gcc -mno-cygwin' is switching the build environment to MinGW.  It
says use the headers in /usr/include/mingw instead of /usr/include and
to use the libraries in /usr/lib/mingw instead of the ones in /usr/lib. 
Thus you're switching the build environment to MinGW.

> The symlink approach (i.e. i386-pc-mingw32-gcc) might be appropriate for

No, the poster has a wrapper script he named mgcc.  The symlink was for
binutils binaries.

> latter versions of autoconf, but it does not work for earlier versions. I
> contribute to the OpenLDAP project, specifically its MinGW support. To build
> MinGW OpenLDAP, I've also got to build regex-0.12, gdbm-1.8.0, and
> libtool-1.4.2. As far as I can tell, none of the configure scripts in these
> projects conform to the notion of looking for ${host}-gcc or any other
> ${host}-tool. In these projects, the solution I pointed out works
> flawlessly:
> 
> CC=mgcc ./configure --host=i686-pc-mingw32
> 

Not all configure.in contains AC_CANONICAL_SYSTEM.  Try ones that do. 
E.G.: binutils, gcc.

> The configure script in regex-0.12 does not even accept the --host switch
> (or --target or --build). Instead, it treats the last parameter on the
> command line as the "host":
> 
> CC=mgcc ./configure i686-pc-mingw32
> 

Must have been built using and older version of autoconf.  This method
is deprecated and will most likely support for this will be removed with
version 3.0.

> The configure script in regex-0.12 does not make any real use of this value,
> so it doesn't really have any effect on the build.
> 

Not all configure.in conform to the standard obviously.  My statements
are based on the standard.

> I originally responded to J. Henning Schwentner, who started this thread. At
> this point, I don't remember what he said he was building. However, it's
> obvious to me that unless you're building a project with a configure script
> built by an up-to-date version of autoconf, none of what you have suggested
> will work. Note that the approach I suggested will work in either case, WITH
> THE POSSIBLE EXCEPTION (as you have stated) that one runs into trouble
> if --build and --target are not specified as well.
> 

My statements are based on the standard.  For those packages conforming
to AC_CAN0NICAL_SYSTEM my statements will make a difference.  I'm saying
you should just get used to always doing it that way so that you never
have a problem.  Fine if you don't, you will find the package that needs
it.

> This spawns another associated topic. What are the right values for the
> triplets (in CURRENT autoconf)? If you're building MinGW binaries in a
> Cygwin-hosted environment, it seems to me that you should ONLY
> specify --target=i686-pc-mingw32 and let the other two switches resolve
> themselves to i686-pc-cygwin. When I build MinGW binaries with Cygwin tools,
> I am not using a MinGW-hosted environment or MinGW tools. All of binutils,
> for example, are still Cygwin tools, and they DON'T honor the -mno-cygwin
> switch. I don't want to symlink those tools either. None of this should
> matter as long as GCC produces MinGW binaries. Why should it matter if
> configure believes that you're doing a cross-compile. In a loose sense, you
> are. This, of course, is a religious argument.
> 

It depends on the filters in your config.sub.

> Note that I have tried to only use the --target switch in my projects,
> opposed to the --host switch. However, in OpenLDAP and the other related
> projects, NONE of the configure scripts handle these switches correctly. I
> found that using --host was the best solution for these projects.
> 

Host is the environment the resulting binaries will execute on.  Build
is the environment doing the building.  Target is the environment that
the resulting binaries for host will produce.  Not all packages need the
target but if the configure script i

Re: Compiling apps to Mingw32 with cygwin

[Robert Collins]

===
- Original Message -
From: "Earnie Boyd" <[EMAIL PROTECTED]>
> My statements are based on the standard.  For those packages
conforming
> to AC_CAN0NICAL_SYSTEM my statements will make a difference.  I'm
saying
> you should just get used to always doing it that way so that you never
> have a problem.  Fine if you don't, you will find the package that
needs
> it.

BTW: According to
http://www.gnu.org/manual/autoconf/html_mono/autoconf.html#SEC144
AC_CANONICAL_SYSTEM is obsolete.

Rob


--
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: No stderr output

[Don Sharp]

William S Fulton wrote:
> 
> Anything sent to stderr does not appear on the terminal. It seems to
> disappear into a black hole. I think it started when I was attempting to
> redirect stdout and stderr into the same file in the same order it appears
> on the console using something like
> runme 1>&2 > filename
> I tried all sorts of combinations and didn't get it to work :(
> 
> Any suggestions for bringing stderr back from the dead?
> Thanks.
> 

For Bourne style shells I use

runme > filename 2>&1

This redirects stdout first and then stderr to whereever stdout is
pointing.

Cheers

Don Sharp

--
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: No stderr output

[Christopher Faylor]

On Thu, Jan 10, 2002 at 11:06:57PM +, Don Sharp wrote:
>William S Fulton wrote:
>> Anything sent to stderr does not appear on the terminal. It seems to
>> disappear into a black hole. I think it started when I was attempting to
>> redirect stdout and stderr into the same file in the same order it appears
>> on the console using something like
>> runme 1>&2 > filename
>> I tried all sorts of combinations and didn't get it to work :(
>> 
>> Any suggestions for bringing stderr back from the dead?
>> Thanks.
>
>For Bourne style shells I use
>
>runme > filename 2>&1
>
>This redirects stdout first and then stderr to whereever stdout is
>pointing.

If this doesn't do it, then I think the best plan is to find help from
another mailing list.  Basic shell questions are not really appropriate
here -- especially given the recent volume we've been experiencing.

cgf

--
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: Problem with winsup/cinstall compilation

[Ralf Habacker]

> - Original Message -
> From: "Ralf Habacker" <[EMAIL PROTECTED]>
> To: "Cygwin" <[EMAIL PROTECTED]>
> Sent: Thursday, January 10, 2002 8:45 PM
> Subject: Problem with winsup/cinstall compilation
>
>
> > Hi,
> >
> > I've tried to compile a recent setup.exe from the cvs and got an error
> while compiling
> > mklink2.c about "function declaration isn't a prototype"
> > I've found that in cinstall/Makefile.in the -Werror option is set, so
> warnings causes
> > compiling failures.
> >
> > What about this ? As I see there are two solutions for this.
> >
> > 1. remove the -Werror in Makefile.in
> > CFLAGS :=
> @CFLAGS@ -Werror -Winline -Wall -Wpointer-arith -Wcast-align\
> >   
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \
> > -Wmissing-declarations -Wcomments
> >
> > 2. fix the bad header.
> >This seems to me the better solution, so a patch for the w32api
> header is appended.
>
> 2. is correct. The -Werror is there deliberately.
>
> I don't see these errors however. What version of gcc are you building
> with?
gcc  2.95.3-5


> Also, why are you building against your system includes , not the winsup includes? 
>(see my
compile line below.

The system includes are included automatic at the end of the list, so the winsup 
includes are
used first, see my compile line. I have updated today from cvs.

gcc -MMD -g -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict-
prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments -mno-cygwin -I. 
-I/home/hab
acker/src/cvs.cygwin.com/src/winsup/cinstall 
-I/home/habacker/src/cvs.cygwin.com/src/winsup/m
ingw/include -I/home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include 
-I/home/habacker/s
rc/cvs.cygwin.com/
src/winsup/bz2lib -mwindows -c -o mklink2.o ../../../src/winsup/cinstall/mklink2.c

$ make CC="gcc -v"
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
gcc -v -c -g -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict
-prototypes -Wmissing-prototypes -Wmissing-declarations -Wcomments ... mklink2.c
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/specs
gcc version 2.95.3-5 (cygwin special)

/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/cpp0.exe -lang-c -v -I. 
-I/home/habacker/src/cvs.cyg
win.com/src/winsup/cinstall -I/home/
habacker/src/cvs.cygwin.com/src/winsup/mingw/include 
-I/home/habacker/src/cvs.cygwin.com/src/
winsup/w32api/include -I/home/habacke
r/src/cvs.cygwin.com/src/winsup/bz2lib -MMD
mklink2.d -D__GNUC__=2 -D__GNUC_MINOR__=95 -D_X86_=1 -D_X86_=1 -Asystem(winnt) -D__OPT
IMIZE__ -g -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings 
-Wstrict-proto
types -Wmissing-prototypes -Wmissing-
declarations -Wcomments -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 
-Dpenti
umpro -D__i686 -D__i686__ -D__pentium
pro -D__pentiumpro__ -D__stdcall=__attribute__((__stdcall__)) 
-D__cdecl=__attribute__((__cdec
l__)) -D_stdcall=__attribute__((__std
call__)) -D_cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) 
-D__MSVCRT__ 
-D__MINGW32__ -isystem /usr/local/inc
lude/mingw -idirafter
/usr/include/mingw -DWIN32 -DWINNT -D_WIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -idirafter
/usr/include/w32api ..
/../../src/winsup/cinstall/mklink2.c /c/DOKUME~1/habacker/LOKALE~1/Temp/ccUo6xxm.i
GNU CPP version 2.95.3-5 (cygwin special) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 .
 /home/habacker/src/cvs.cygwin.com/src/winsup/cinstall
 /home/habacker/src/cvs.cygwin.com/src/winsup/mingw/include
 /home/habacker/src/cvs.cygwin.com/src/winsup/w32api/include
 /home/habacker/src/cvs.cygwin.com/src/winsup/bz2lib
 /usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/include
 /usr/include/mingw
 /usr/include/w32api

> The patch looks ok though, you should make a ChangeLog etc and send it to 
>cygwin-patches.
>
> Rob
>
> $ make
> gcc -L/usr/src/cygwin/build/i686-pc-cygwin/winsup -L/usr/src/cygwin/buil
> d/i686-pc-cygwin/w
> insup/cygwin -L/usr/src/cygwin/build/i686-pc-cygwin/winsup/w32api/lib -i
> system /usr/src/sr
> c/winsup/include -isystem /usr/src/src/winsup/cygwin/include -isystem
> /usr/src/src/winsup/
> w32api/include -isystem /usr/src/src/newlib/libc/sys/cygwin -isystem
> /usr/src/src/newlib/l
> ibc/sys/cygwin32 -B/usr/src/cygwin/build/i686-pc-cygwin/newlib/ -isystem
> /usr/src/cygwin/b
> uild/i686-pc-cygwin/newlib/targ-include -isystem
> /usr/src/src/newlib/libc/include -MMD -g
> -O2 -Werror -Winline -Wall -Wpointer-arith -Wcast-align -Wwrite-strings
> -Wstrict-prototype
> s -Wmissing-prototypes -Wmissing-declarations -Wcomments -mno-cygwin -I.
>  -I/usr/src/src/wi
> nsup/cinstall -I/usr/src/src/winsup/mingw/include  -I/usr/src/src/winsup
> /bz2lib -mwindows
> -c -o mklink2.o ../../../../../src/winsup/cinstall/mklink2.c
> make -C zlib libzcygw.a
> CC="gcc -L/usr/src/cygwin/build/i686-pc-cygwin/winsup -L/usr/src/c
> ygwin/build/i686-pc-cygwi

gcc under windows xp

[aon . 912166165 . 1]

hi there!

i previously used cygwin under a windows 2000 environment, and it worked
really fine. (i more or less only use the gcc compiler and tools)
but i got myself a new machine, and - bad luck - it only really runs fine
under windows xp. So there i am on my win xp system, and, yes the cygwin shell
works, but: gcc always complains about not being able to reserve space for a
heap or stack.
I'm not really sure, if this tells you what problem i have, i'm not a pro, i
just wanted to ask, if there is a known possibilty to use cygwin and gcc
under windows xp.
If there is, please tell me, and if it would help you to have the complete
error message, just tell me. (but i think you know more about the technical
problems than i probably ever will)

it would be real nice to hear from you

chri

--
Christoph Schwarz
[EMAIL PROTECTED]
+43 664 1446824




Versendet durch Jet2Web Internet - Webmail (webmail.jet2web.net)

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