[SOLVED] Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Carlo Florendo]

Hello Brian,
What we had was *not* a cygwin problem after all...
Brian Dessent wrote:
Carlo Florendo wrote:
 

Anyway, I got this error:
getservbyname() returned NULL: win32 error 11004
   

Googling shows that this is consistent with trying to run a
program/server that tries to look up its port in the services file when
no such matching line exists.
 

I also read the message regarding the \r\n and \n line endings (still
not in my mailbox) and Corinna's reply.  I've checked the services file
and confirmed that the line endings are \r\n  (with the simple test of
^M showing up when invoking `vim -b'.  Notepad also views the file
correctly, thus it's really \r\n.).
I'm confident we're getting close!
   

Closer yes, 

Yes.  In fact, ftp is working perfectly well now.   Thank you very 
much.  More below...

but I'm afraid I don't have much else coming to mind. 
Everything indicates that it's not finding what it's looking for in the
services file.  

Correct.  That is because the services file wasn't present in the first 
place.  Let me explain...

Since the `services' file  was involved, I thought of having a way to 
monitor which files the ftp client accesses to make sure that it really 
accesses the `services' file.  I then remembered that I  had  this copy 
of sysinternal's (www.sysinternals.com) filemonitor program filemon.exe 
which displays file access on a system in real time.   Thus, I simply 
fired up filemon.exe, then fired up ftp, and poof, got the answer right 
smack in my face.

ftp was trying to access c:\winnt\nsdb\services.  I then checked my 
system and c:\winnt\nsdb\ really existed but c:\winnt\nsdb\services did 
not.   Then, I wondered why it was looking at that directory and not 
c:\winnt\system32\drivers\etc.   I had no way of finding out where the 
system got c:\winnt\nsdb but I first assumed that it got that location 
from the registry.  I fired up regedit and looked for all instances of 
`nsdb'.  Interestingly, I got this registry key/value:

\HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DataBasePath = 
%SystemRoot%\nsdb

I changed the registry entry value to
%SystemRoot%\system32\drivers\etc
then fired up ftp.  Whew!  It worked perfectly.
I searched on the cause of a modification of this registry entry and it 
was a virus (which has long been removed from the system).

One thing is clear though, this is not a Cygwin problem.  The mingw
example shows a minimal testcase that involves no Cygwin code at all,
just direct calls to the Winsock functions.  I'm willing to bet if you
found a regular windows application that tried to look up a port using
getservbyname() it would fail in the same way.
Correct again.  In fact, I made a simple program in VC++ that used 
getservbyname() and it failed exactly the same way as
your *.c codes.

 This is a relatively
rare/antiquated thing to do as most apps either have the port
configurable via a URL or a config file, or they just hard-code it.
If you want a quick and dirty solution, comment out the call to
getservbyname in the ftp source code and modify it to assume port 21. 
But that's admitting defeat, really.

 

We won't, we didn't and we won.  Thanks Brian and to everyone for the 
valuable comments which led us to lay this problem to rest.
On a curious note, why do the inetutils  apps like ftp, telnet, etc. 
still use getservbyname() and the other getserv  functions when, as you 
said,
these apps could just have the port and protocol hardcoded or specified 
in a config file?

In any case, this is what I like with cygwin the cygwin mailing list.  
They're the best!  Cygwin...It Rocks!

Best Regards,
Carlo
--
Carlo Florendo
Astra Philippines Inc.
www.astra.ph
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: non-interactive cygwin setup

[Gary R. Van Sickle]

[snip]
> >I thought if a GUI app called printf it generally caused a 
> console to 
> >be opened for it.  Maybe that's only with msvcrt.  In any case, the 
> >fact is that it is being run from a cmdline and so it certainly can 
> >communicate with the console.  The presence of command-line 
> options in 
> >argc/argv could be taken as a fairly strong hint that it was 
> being run 
> >from a shell rather than an icon.  And there's always 
> "isatty (1)" if 
> >you really really want to be sure.
> 
> This is a windows limitation.  GUI apps (apps created with 
> -mwindows) can't send output to or receive input from the 
> console.  Of course, a GUI can interpret command line 
> information.  It just cannot send output to the console that 
> started it.
> 
> You could use AllocConsole to create a separate console which 
> the GUI could then use, however.

Here's a maybe-less-icky way to do it.  Have two exes, one "setup.exe" which
is a 100% command-line program that normally just spawns "winsetup.exe", the
current GUI setup, and goes away.  Give it "--help", and it prints help in
the regular command-line way and exits.  Yeah, two exes, but worse tragedies
have happened.

-- 
Gary R. Van Sickle
 


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

Virtual (meta-) packages

[Jani Tiainen]

Could setup be extended (or even used in current form) to have virtual 
packages that could install some basic tools as a whole working 
combination, like X11 server? More or less like it is done in Debian (my 
favourite Linux distribution)

I recently wondered where my X11 start scripts went and found out that 
I've missing startup-scripts. It would be more convenient to have 
virtual package that installs "all" for that first time so you don't 
have to know what you're installing... It would be helpful.

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

Re: Setup failure: mount error

[luke]

luke wrote:
luke wrote:
At the moment, it looks like I'm going to have to scrub Windows and 
re-install it.

I suppose before that, I can try installing from our stable mirror.
Perhaps the Cygwin on the mirror site is badly buggy (despite all MD5
checksums being correct).
I got the identical result isntalling from our stable mirror of an older 
Cygwin, that's known to work.  It didn't, on this Win2K laptop.

I'm currently running a file system check on the two local drives (both 
NTFS).
Both drives checked out okay.  An install of the stable Cygwin failed 
anyway.


However I do notice that someone else reported the same problem in 2001:
http://www.cygwin.com/ml/cygwin/2001-12/msg00884.html
In summary:
Upgraded to latest setup today (2.125.2.10) and tried to update my 
already-
existing installation. I have several systems with it installed, so I
download
the new packages first, then install from the local directory. Setup
downloaded
a few packages.

I tried to install onto a 50.3G FAT32 partition, with 28.5GB free. I
tried to
install from a 57.2G NTFS partition, with 23.4G free.
When I tried to install from the local directory, and after selecting the
packages recommended, setup instantly puts up a dialog box labeled
"mount" that
says "The operation completed successfully". Behind that box is the 
"Cygwin
Setup", and says "Installing...", The Package and Total indicator bars 
are
blank, and the button says "Cancel". Clicking OK on the "mount" box
terminates
the installation, with nothing installed.

I tried a complete install to a different partition from the local disk;
same
thing, although the directory structure is created.

but the person never came back with followup to the requested actions:
* From: "Robert Collins" * To: "Kevin Quitt" * Date: Wed, 
19 Dec 2001 18:54:54 +1100
* Subject: Re: Setup 2.125.2.10 fails to install on Win2K
* References: <[EMAIL PROTECTED]>

Try deleting setup.ini, and doing a download again.
delete setup.log and setup.log.full
Then do an 'install from Net'
post inline the resulting log files.
Also check the contents of /etc/setup/installed.db
Rob

I'll let people know how I get on.  Plan: first the FS check, then I'll 
try installing a stable known to work Cygwin, then I'll scrub and 
reinstall W2K, then I'll give up and try another PC.
Well, since I know the MD5 checksums are correct on both our local
stable Cygwin mirror, known to work, and on the nightly mirrored
"latest" mirror, and since these mirrors work on other PCs, it starts to
look like the problem is specific to this PC.
In other words, it appears to have nothing to do with having run "mount"
from a network install of Cygwin.  (Since all files created by Cygwin
and all registry entries were deleted, Cygwin stores no other
information on the system, and yet the problem persisted.)
I have scrubbed Windows, reformatted the drives, and am re-installing 
W2K now.  I fully expect this to fail as well.

In which case I'll just pick a different PC that Cygwin can be installed
on, and go back to testing what I was originally trying to test!
luke
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: problem with find/grep

[Christopher Faylor]

On Wed, Oct 13, 2004 at 07:43:33PM -0700, Joshua Daniel Franklin wrote:
>On Tue, 12 Oct 2004 12:04:11 -0600, Mark Paulus <[EMAIL PROTECTED]> wrote:
>> Thanks.  I was not aware of the -print0 option.  This is
>> what I love about *n*x:  Always something new to learn,
>> or another way to find a solution.
>
>What! Do NOT use -print0! It will null-terminate EVERY LINE!

Huh?  -print0 is perfectly usable for the situation in which it was raised,
namely for situations where there are filenames with spaces in them.

You shouldn't use it if you don't need it, of course.  It certainly
won't display correctly if you do.

cgf

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

Re: problem with find/grep

[Joshua Daniel Franklin]

On Tue, 12 Oct 2004 12:04:11 -0600, Mark Paulus <[EMAIL PROTECTED]> wrote:
> Thanks.  I was not aware of the -print0 option.  This is
> what I love about *n*x:  Always something new to learn,
> or another way to find a solution.

What! Do NOT use -print0! It will null-terminate EVERY LINE!

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

Re: tcsh and chere-0.3-1

[Christopher Faylor]

On Wed, Oct 13, 2004 at 06:20:55PM -0600, Andrew Grimm wrote:
>I think with most login shells the "cd $HOME" behavior is due to the way
>the scripts are written in /etc (for example Cygwin's /etc/csh.login).
>That is probably a good thing to have in the script, but it presents a
>difficulty for this unusual application.

Aha.  I didn't know that this was something we were doing.

If that is the case then maybe we could get some coordination going and
set a CYGWIN_CD_HERE environment variable or something and just have the
login shell cd to the right directory automatically with the help of
the /etc/* scripts.

cgf

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

Re: tcsh and chere-0.3-1

[Andrew Grimm]

On Wed, Oct 13, 2004 at 07:02:13PM -0400, Christopher Faylor wrote:
>Actually, All shells which support -l seem to cd to the home directory.
>I'm not sure what the -l adds to the above since the above code just
>calls the shell again after cd'ing to the directory.

I think the purpose of that is to ensure that ~/.login (or whatever) gets
called to completely set up the shell's environment.  Normal shells don't
read in that file because they are assumed to inherit their environment
from the base login shell.

>It almost seems like you could just use ash to invoke the real shell in
>all cases.  That would be faster.

True, you could use any shell as the base login shell which exec's the
desired shell.  That has the benefit of always working.  However, that
approach will bypass the login-shell-specific config files for other shell
types.  For instance, "ash -" will load env vars from ~/.profile rather
than ~/.login which a tcsh user is unlikely to have set up to produce
identical results (for instance I like to put MANPATH in ~/.login but I
don't have a ~/.profile at all).  This would result in a "chere" shell
which will not behave quite like the user's regular shells, which are
spawned from a login shell of the same flavor.

Actually that appears to be another bug in the script:  chere should
invoke ash as "ash -" to start an ash login shell (I haven't tested this
though).

I think with most login shells the "cd $HOME" behavior is due to the way
the scripts are written in /etc (for example Cygwin's /etc/csh.login).
That is probably a good thing to have in the script, but it presents a
difficulty for this unusual application.

-Andy


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

Re: cygwin & openssh(d) & login without password (gold star)

[Robert R Schneck-McConnell]

Igor Pechtchanski wrote:
> On Tue, 12 Oct 2004, Robert R Schneck wrote:
>> But hey... my Jan 2004 gold star seems to have gone missing.
>
> Huh?  From :
>Robert R. Schneck <*> (Jan 2004) <*> (Oct 2004) -- For an attempt to apply a 
> creative solution to a problem

A case of poor observation.

> P.S. I've changed the name, too -- was that right?

Ah, it seems I forgot to change my newsreader config file to use my
married name!  (The older star came from cygwin-apps to which I post
using e-mail rather than news.)  But you needn't bother to change it,
I still do use the shorter bachelor name occasionally.

Robert


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

RE: [ANNOUNCEMENT] NEW: cyrus-sasl-2.1.19-1, libsasl2-2.1.19-1, libsasl2-devel-2.1.19-1

[Gareth Pearce]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dr. Volker Zell
> Sent: Thursday, 14 October 2004 3:49 AM
> Subject: Re: [ANNOUNCEMENT] NEW: cyrus-sasl-2.1.19-1, libsasl2-2.1.19-1,
> libsasl2-devel-2.1.19-1
> 
> 
> Hi Gareth
> 
> I'm just trying to compile openldap with cyrus-sasl support.
> 
> It seems
> 
>   libsasl2-devel
> 
> is missing the following files:
> 
>   /usr/lib/libsasl2.dll.a
>   /usr/lib/libsasl2.la
> 
> Can you fix this ASAP
> 

Fixed in -3 (which I hope will be up shortly)

Regards,
Gareth Pearce
Security Developer
Panareef Pty. Ltd. (www.panareef.com)



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

Re: tcsh and chere-0.3-1

[Christopher Faylor]

On Wed, Oct 13, 2004 at 07:02:13PM -0400, Christopher Faylor wrote:
>It almost seems like you could just use to invoke the real shell in all
   ash
>cases.  That would be faster.

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

Re: tcsh and chere-0.3-1

[Christopher Faylor]

On Wed, Oct 13, 2004 at 03:58:02PM -0600, Andrew Grimm wrote:
>The new (very cool!) chere package doesn't work with tcsh, at least on my
>system.  The problem is that "tcsh -l" doesn't work with any additional
>arguments.  There is even a comment to that effect in the script:
>
>tcsh )
># Apparently -l only applies if it is the only argument
># so this may not work
>SHELL_EXE="/bin/tcsh.exe"
>SHELL_CMD="-l -c \\\"cd '%L'; exec $SHELL_EXE\\\""
>
>If I run this, the tcsh immediately bombs out, closing the shell window,
>because tcsh exits when it sees the additional arguments.
>
>There may not be a perfect solution because tcsh won't work with the
>code pattern used for the other shells.  If you make the exec'd shell a
>login shell it cd's to your home directory which defeats the purpose of
>the package.  This hack works for me, it doesn't create a real login
>shell but it fakes one fairly well:

Actually, All shells which support -l seem to cd to the home directory.
I'm not sure what the -l adds to the above since the above code just calls
the shell again after cd'ing to the directory.

It almost seems like you could just use to invoke the real shell in all
cases.  That would be faster.

cgf

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

Re: tcsh and chere-0.3-1

[Andrew Grimm]

Actually I made a minor goof, the order should be:

/etc/csh.cshrc
/etc/csh.login
~/.tcshrc
~/.login

There is also the possibility that ~/.tcshrc does not exist, if that is
the case ~/.cshrc should be read (but not both).  I didn't bother with
that as I use ~/.tcshrc but a more general script should.

Of course there may be a much more elegant solution than this approach,
but I wanted it to be correct for the record =)

-Andy


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

Re: When is WinXP not WinXP?? - not *really* OT

[Daniel Miller]

Christopher Faylor <[EMAIL PROTECTED]> wrote in 
news:[EMAIL PROTECTED]:

>>> Daniel Miller <[EMAIL PROTECTED]> wrote in
>>> news:[EMAIL PROTECTED]: 
>>> 
>>> I propose that this is *not* really off-topic, since the problems 
that
>>> I'm experiencing do not occur in cmd.exe, nor in 4NT, only in Bash. 
>>> So it's something Bash is doing in its environment that is breaking
>>> StdOut, at least relative to whatever Win32 looks at.
>>> 
> 
> Why does it matter?  If that was the case, are you asking if we will
> change cygwin to help get your application working?  If so, the answer
> is "no".
> 
> You've found your problem.  Don't use STD_OUTPUT_HANDLE for this 
purpose.
> Use STD_INPUT_HANDLE instead.  Problem solved.
> 
Actually, no, problem not solved.  First of all, disregarding the 
redirection issue entirely, GetConsoleScreenBufferInfo() is used in Win32 
programs to get information about the console configuration.  I need that 
information regardless.

STD_INPUT_HANDLE does *not* solve the problem, it isn't valid at all in 
that function, even in a normal console (cmd.exe) (I tested it).  The 
StdOut handle is used because I want info about the window I'm writing 
to.  The function works properly in every console except Bash, which is 
why I'm presenting the issue on this group.  I don't think this is an 
unreasonable request.  

Besides, I'm not necessarily suggesting that the problem is even with 
Bash itself, since Bash works on another XP machine.  I'm mainly trying 
to figure out what the difference is between XPPro+Bash and XPHome+Bash.  
But either way, Bash itself *is* a required component in creating this 
failure mechanism; no other console program produces it...



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

tcsh and chere-0.3-1

[Andrew Grimm]

The new (very cool!) chere package doesn't work with tcsh, at least on my
system.  The problem is that "tcsh -l" doesn't work with any additional
arguments.  There is even a comment to that effect in the script:

tcsh )
# Apparently -l only applies if it is the only argument
# so this may not work
SHELL_EXE="/bin/tcsh.exe"
SHELL_CMD="-l -c \\\"cd '%L'; exec $SHELL_EXE\\\""

If I run this, the tcsh immediately bombs out, closing the shell window,
because tcsh exits when it sees the additional arguments.

There may not be a perfect solution because tcsh won't work with the
code pattern used for the other shells.  If you make the exec'd shell a
login shell it cd's to your home directory which defeats the purpose of
the package.  This hack works for me, it doesn't create a real login
shell but it fakes one fairly well:

SHELL_CMD="-f -c \\\"if ( -f /etc/csh.login ) source
/etc/csh.login; if ( -f /etc/csh.cshrc ) source /etc/csh.cshrc; if ( -f
~/.tcshrc ) source ~/.tcshrc; if ( -f ~/.login ) source ~/.login; cd '%L';
exec $SHELL_EXE\\\""

A more complicated line could be created to handle more unusual tcsh
configurations but this approach works with the default setup.

-Andy

P.S.  Output of "chere -r" as requested on bug reports (with the above
  modification to line 244 of the chere script):

OS is CYGWIN_NT-5.0
chere version 0.3

--- ash keys ---

--- bash keys ---

--- cmd keys ---

--- pdksh keys ---

--- tcsh keys ---
Directory menu item
&Tcsh Here

Directory command
D:\cygwin\bin\rxvt.exe -e /bin/tcsh.exe -f -c "if ( -f /etc/csh.login )
source /etc/csh.login; if ( -f /etc/csh.cshrc ) source /etc/csh.cshrc; if
( -f ~/.tcshrc ) source ~/.tcshrc; if ( -f ~/.login ) source ~/.login; cd
'%L'; exec /bin/tcsh.exe"

Drive menu item
&Tcsh Here

Drive command
D:\cygwin\bin\rxvt.exe -e /bin/tcsh.exe -f -c "if ( -f /etc/csh.login )
source /etc/csh.login; if ( -f /etc/csh.cshrc ) source /etc/csh.cshrc; if
( -f ~/.tcshrc ) source ~/.tcshrc; if ( -f ~/.login ) source ~/.login; cd
'%L'; exec /bin/tcsh.exe"

Uninstall description
Cygwin Tcsh Prompt Here

Uninstall command
D:\cygwin\bin\sh -c "/bin/chere -u -s tcsh"


--- zsh keys ---

--- passwd keys ---



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

Re: lseek 2GB wrap problem (with tail)? [need textutils repackage]

[Brian Dessent]

Alexander Geraldy wrote:

> I've seen the following problem and don't know how to handle it.
> 
> Configuration: Cygwin 1.5.11-1, tail (textutils) 2.0.21, strace (cygwin)
> 1.21

Unfortunately, it looks like the textutils package has gone
unmaintained.  The last release of it was in Feb of 2002:


Cygwin did not have 64 bit file IO support until the 1.5.x series, from
July 2003, meaning this package was compiled against 1.3.x and will
choke on the 2GB barrier.  It could be as simple as rebuilding it and
releasing a new package.  Someone should really look into this, and I've
CC'd cygwin-apps to see if there's any interest.

File under "Cygwin really needs a proper coreutils maintainer to take
over these dead packages."

Brian

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

Re: Backup script not working properly

[Robin Bowes]

Brian Dessent wrote:
Fredrik Persson wrote:

All works but for the last for-loop which is responsible for deleting old
backups such that only NUMBKPS=4 of the last backups are stored.
The problem is in 'if [ ${num} -le 0 ]' and 'else num=$((${num}-1))'. It seems
like the num-variable can't be used as an integer. Any suggestions how to fix
this???

On Linux, /bin/sh is /bin/bash.  This is not the case on Cygwin and
other *nixs.  The "$((...))" thing is a bash feature/extension I think,
and not found in the standard Bourne shell.  Try using the expr command
instead to do math, or change the shebang to call bash explicitly.
Indeed.
man bash
/Arithmetic Expansion
 Arithmetic expansion allows the evaluation of an arithmetic  expression
 and  the  substitution of the result.  The format for arithmetic expan-
 sion is:
   $((expression))
 The expression is treated as if it were within  double  quotes,  but  a
 double  quote  inside  the  parentheses  is not treated specially.  All
 tokens in the expression undergo parameter expansion, string expansion,
 command  substitution, and quote removal.  Arithmetic substitutions may
 be nested.
 The evaluation is performed according to the rules listed  below  under
 ARITHMETIC EVALUATION.  If expression is invalid, bash prints a message
 indicating failure and no substitution occurs.
R.
--
http://robinbowes.com
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Ping: Cygwin libtool / assembler problem with -DPIC

[Gerrit P. Haase]

Noah Misch wrote:
On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote:
Gerrit wrote:
PING!

Hello,

With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
generated assembly is broken.  I saw this problem with a
reautoconfiscated version of GMP.  This may be unusual, but there was
libtool used to invoke gas.

What do you mean by ``the generated assembly is broken''?  Please show the error
you encountered.
I built gmp-4.1.4 on Cygwin, and it passed all tests.  I used the shipped
``configure'', but adding -DPIC is not a new libtool behavior.
>
There was a thread about this general topic awhile ago.  That GMP actively uses
-DPIC to select the correct assembly came up:
http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html
I saw that -DPIC was used on Cygwin to compile assembly and it couldn't be
linked.  Also I read in the GMP sources somewhere that libtool adds this
flag where it is a noop on Cygwin when not compiling assembler code where
it breaks things, so the conclusion was to remove the flag entirely when
platform is Cygwin, I was able to build GMP and thats it.
Unfortunately I have no logs, but I tracked it down and realized that
this flag is the culprit and removing it resolves my problem.  Even
more bad that the demo I suspect to show the error doesn't build at all
with the recent Cygwin release (demos/expr).
Anyway, this flag is used where it is completely useless, so please
remove it, patch was already submitted to the Cygwin libtool maintainer.
Gerrit
--
=^..^=
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: vim problem with my install, y?

[Lane, Frank L]

Thanks Chris: you nailed it.  TERM was nutc, whatever that's supposed to
be, changed it to cygwin and all's well with the world!:-)


Thanks,
Frank

-Original Message-
From: Christopher Faylor
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 13, 2004 4:07 PM
To: [EMAIL PROTECTED]
Subject: Re: vim problem with my install, y?

On Wed, Oct 13, 2004 at 02:40:57PM -0500, Lane, Frank L wrote:
>Just installed cygwin, and tried to use vi.  For some reason, which I
>hope someone on the list will make abundantly clear to me, all the
>keyboard input was focused into the leftmost, topmost character of my
>edit screen.

Sounds like you have the TERM environment variable set incorrectly.

If not, then: http://cygwin.com/problems.html .

cgf

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


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

Re: vim problem with my install, y?

[Christopher Faylor]

On Wed, Oct 13, 2004 at 02:40:57PM -0500, Lane, Frank L wrote:
>Just installed cygwin, and tried to use vi.  For some reason, which I
>hope someone on the list will make abundantly clear to me, all the
>keyboard input was focused into the leftmost, topmost character of my
>edit screen.

Sounds like you have the TERM environment variable set incorrectly.

If not, then: http://cygwin.com/problems.html .

cgf

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

Re: non-interactive cygwin setup

[Christopher Faylor]

On Wed, Oct 13, 2004 at 06:31:28PM +0100, Dave Korn wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Christopher Faylor
>> Sent: 13 October 2004 15:17
>
>> On Wed, Oct 13, 2004 at 01:01:07PM +0100, Dave Korn wrote:
>> >> -Original Message-
>> >> From: cygwin-owner On Behalf Of Rainer Hochreiter
>> >> Sent: 13 October 2004 08:32
>> >
>> >>is there a chance to install cygwin without gui dialog?
>> >>
>> >>my plan is to download all needed packages into a local 
>> directory and
>> >>then install the packages from that local directory by 
>> starting setup
>> >>from a command line without further user interaction.
>> >
>> >"setup.exe --help" gives this output, which for some bizarre 
>> reason it
>> >places in the setup.log file...
>> 
>> Probably because a GUI app can't communicate with the console.
>
>I thought if a GUI app called printf it generally caused a console to
>be opened for it.  Maybe that's only with msvcrt.  In any case, the
>fact is that it is being run from a cmdline and so it certainly can
>communicate with the console.  The presence of command-line options in
>argc/argv could be taken as a fairly strong hint that it was being run
>from a shell rather than an icon.  And there's always "isatty (1)" if
>you really really want to be sure.

This is a windows limitation.  GUI apps (apps created with -mwindows)
can't send output to or receive input from the console.  Of course, a
GUI can interpret command line information.  It just cannot send output
to the console that started it.

You could use AllocConsole to create a separate console which the GUI
could then use, however.

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

Re: When is WinXP not WinXP?? - not *really* OT

[Christopher Faylor]

On Wed, Oct 13, 2004 at 04:45:46PM +, Daniel Miller wrote:
>Daniel Miller <[EMAIL PROTECTED]> wrote in
>news:[EMAIL PROTECTED]: 
>
>> Daniel Miller <[EMAIL PROTECTED]> wrote in
>> news:[EMAIL PROTECTED]: 
>> 
>> I propose that this is *not* really off-topic, since the problems that
>> I'm experiencing do not occur in cmd.exe, nor in 4NT, only in Bash. 
>> So it's something Bash is doing in its environment that is breaking
>> StdOut, at least relative to whatever Win32 looks at.
>> 
>> BTW, I did not install Cygwin on the Home machine by copying from the
>> other machine, I installed it using setup.exe, downloaded from Cygwin.
>> 
>> Also, in response to Dave Korn's previous message, GetLastError() is 
>> returning error 6 (The handle is Invalid)...
>> 
>A further note is that handles returned by GetStdHandle() always have 
>GENERIC_READ and GENERIC_WRITE access, "unless SetStdHandle function was 
>used to set a standard handle to be some handle with a lesser access." 
>(per MSDN).  Certainly  I didn't use SetStdHandle for *any* purpose, 
>which is why the utility works under other shells.  Does Bash use 
>SetStdHandle or some equivalent to change the console environment??

Why does it matter?  If that was the case, are you asking if we will
change cygwin to help get your application working?  If so, the answer
is "no".

You've found your problem.  Don't use STD_OUTPUT_HANDLE for this purpose.
Use STD_INPUT_HANDLE instead.  Problem solved.

cgf

>//  repeating the offending code snippet:
>   /* get the standard handles */
>   hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
>   PERR(hStdOut != INVALID_HANDLE_VALUE, "GetStdHandle");
>
>   //  get screen information.
>   //  If this call fails, assume we are re-directing output.
>   bSuccess = GetConsoleScreenBufferInfo(hStdOut, &sinfo) ;
>   // PERR(bSuccess, "GetConsoleScreenBufferInfo");
>   if (bSuccess == false) {
>  fprintf(stderr, "gcsbi error: %s\n", get_system_message()) ;
>  exit(1) ;
>  redirected = 1 ;
>  return ; 
>   }
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Problem reports:   http://cygwin.com/problems.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/
>

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

vim problem with my install, y?

[Lane, Frank L]

Hi List,

Just installed cygwin, and tried to use vi.  For some reason, which I
hope someone on the list will make abundantly clear to me, all the
keyboard input was focused into the leftmost, topmost character of my
edit screen.

I tried reinstalling vim, uninstalling and going back a version, and
reinstalling all of cygwin, all to no avail.

Tried searching the archives with the string "vim problem"(hence the
subject line of this post).  It looked like everything returned was
related to something other than vim problems.  I'm learning here,
could've made a mistake.

Please tell me what I've done wrong.  Is there an environment variable
or something that I've missed?

Thanks,
Frank

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

Re: SableVM & Cygwin (was: Re: sablevm + windows)

[Peter Lovell]

Hi Gerrit,
many thanks for this. Great !
Speaking only for myself, I believe that option (2) would be the 
appropriate one. It might be nice to include it also back to gcc but I 
suspect that sablevm developers might prefer to not have that 
dependency.

I'll fetch your patches and test and let you know.
Many thanks.Peter
On Oct 13, 2004, at 11:57 AM, Gerrit P. Haase wrote:
Hi Peter,
coming back to this now.
I'm also willing to help port and maintain.
Fine.  I have to offer two possible scenarios.
1.
I have a stripped down standalone libffi package with a shared libffi
now.  This version is based on the sources from the cygwin release of
gcc-3.3.3. You can take this package and maintain it, that means update
it when Cygwin GCC is updated and integrate the changes happened in the
libffi subdirectory.
2.
Include this stripped down libffi version with the SableVM sourcetree
and link libffi into the main DLL as a convenience library.
IMO it would be easier to keep it uptodate when it is included with the
SableVM sources and also distributed this way.  So one can continue 
when
you or me are gone.

I have a patch I can send you, there is the stripped down libffi
integrated in the SablVM build.  The standalone libffi is available as
separate package from my webserver:
http://anfaenger.de/cygwin/cygwin-1.5/libffi-cygwin-standalone/
Ready compiled SableVM binary and source package:
http://anfaenger.de/cygwin/cygwin-1.5/saqblevm/
The source package includes also the patch and uses a statically 
libffi,
so it doesn't need a FFI DLL.  Could you verify that this SableVM works
as expected, please?

Classpath is still compiling.
Gerrit
--
=^..^= 
http://nyckelpiga.de/donate.html

___
SableVM-devel mailing list
[EMAIL PROTECTED]
http://sablevm.org/lists/control/listinfo/sablevm-devel

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

Re: non-interactive cygwin setup

[Jan Nieuwenhuizen]

Rainer Hochreiter writes:

> is there a chance to install cygwin without gui dialog?

There's my cyg-apt script that I use to keep my cross build
environment up to date.  It tries to be compatible with setup.exe, but
it lacks registry settings, postinstall scripts, and needs
python.popen to work.

http://lilypond.org/cygwin/cyg-apt

Jan.

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org

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

Re: gcc exception handling

[Peter Xiaochuan Huang]

Responses are below


--- Peter Xiaochuan Huang <[EMAIL PROTECTED]> wrote:

> > -Original Message-
> > From: cygwin-owner On Behalf Of Peter Xiaochuan
> Huang
> > Sent: 12 October 2004 17:59
> 
> > I don't know if this a known issue. But I
> encounter
> > this problem when using gcc 3.3.3 on cygwin. The
> code
> > similar to below core dumps me.
> > 
> >try {
> >   obj->dothis();
> >}
> > catch ( myexception& e)
> > {
> > return true;
> >  }
> > 
> > It core dumps on the return statement in gdb. But
> when
> > I make a simplified test including only above
> code,
> > the core dump doesn't happen any more. My program
> that
> > gets core dumped links pthread and uses mutex.
> > Actually the return statement should invoke stack
> > unwinding that will do mutex locking and
> unlocking.
> > Though I don't know if that is related or not.
> 
>   Are you using the correct command line options to
> compile with exceptions?

I tried -mthreads that didn't fix it. What is the
right compile flag?

> 
>   Are you doing the final link using g++ rather than
> gcc?

Yes, I compiled and linked use g++


> 
>   Do all functions have the correct throw specifiers
> on their prototypes?

None of my functions has any throw specifier,
which means throw possibly anything. Is that good
enough ?

>  
> > Anybody else has similar problem ? 
> 
>   Maybe the same problem: we never resolved it yet:
>
http://www.cygwin.com/ml/cygwin/2004-09/msg01380.html
> 
> 
>   Are there any shared libraries involved?
> 
> >Any suggestion?
> 
> 1)  Keep trying to come up with a simple testcase?
> 2)  Switch gdb into assembly code view and debug the
> problem by seeing what
> actual values are in registers, stack and memory and
> what actual machine
> code instructions are getting executed to cause the
> problem?

I may have to try this if the compile flag you
give to me doesn't fix the problem

> 
> cheers, 
>   DaveK
> -- 
> Can't think of a witty .sigline today
> 
> 
> --
> 

Thanks a lot for your quick response, Dave.

-Peter




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

Re: [ANNOUNCEMENT] NEW: cyrus-sasl-2.1.19-1, libsasl2-2.1.19-1, libsasl2-devel-2.1.19-1

[Dr. Volker Zell]

> Gareth Pearce writes:

> The Cyrus SASL API implementation is now available via the cygwin mirrors.
> This library allows applications the ability to authenticate and secure
> connections between client and server via a standardised method.  It is an
> extensible system which supports many different authentication techniques
> via a pluggable approach.  

Hi Gareth

I'm just trying to compile openldap with cyrus-sasl support.

It seems

  libsasl2-devel

is missing the following files:

  /usr/lib/libsasl2.dll.a
  /usr/lib/libsasl2.la

Can you fix this ASAP

> Gareth Pearce

Ciao
  Volker


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

RE: non-interactive cygwin setup

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 13 October 2004 15:17

> On Wed, Oct 13, 2004 at 01:01:07PM +0100, Dave Korn wrote:
> >> -Original Message-
> >> From: cygwin-owner On Behalf Of Rainer Hochreiter
> >> Sent: 13 October 2004 08:32
> >
> >>is there a chance to install cygwin without gui dialog?
> >>
> >>my plan is to download all needed packages into a local 
> directory and
> >>then install the packages from that local directory by 
> starting setup
> >>from a command line without further user interaction.
> >
> >"setup.exe --help" gives this output, which for some bizarre 
> reason it
> >places in the setup.log file...
> 
> Probably because a GUI app can't communicate with the console.

  I thought if a GUI app called printf it generally caused a console to be
opened for it.  Maybe that's only with msvcrt.  In any case, the fact is
that it is being run from a cmdline and so it certainly can communicate with
the console.  The presence of command-line options in argc/argv could be
taken as a fairly strong hint that it was being run from a shell rather than
an icon.  And there's always "isatty (1)" if you really really want to be
sure.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: Tcl doesn't build out of src repository on cygwin

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 13 October 2004 15:11

> On Oct 13 15:01, Dave Korn wrote:
> > > From: cygwin-owner On Behalf Of Corinna Vinschen
> > >   That's solved in w32api in
> > > CVS or in recent snapshots.  Or (but that's ugly and not actually
> > > recommended, use at your own risk) use #define __INSIDE_CYGWIN__
> > > at the beginning of the affected files (tclWin32Dll.c and tkWinX.c
> > > AFAIK)
> > 
> >   Or use CFLAGS='-D__INSIDE_CYGWIN__ -g -O2' on the command line,
> > presumably?
> 
> DDT

  Mess up other stuff in the same build, or change the meaning of header
files or something, would it?  Ok, fair enough.  I'll stick with the
locally-modded C files.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Ping: Cygwin libtool / assembler problem with -DPIC

[Noah Misch]

On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote:
> Gerrit wrote:
> 
> PING!
> 
> > Hello,
> 
> > With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
> > generated assembly is broken.  I saw this problem with a
> > reautoconfiscated version of GMP.  This may be unusual, but there was
> > libtool used to invoke gas.

What do you mean by ``the generated assembly is broken''?  Please show the error
you encountered.

I built gmp-4.1.4 on Cygwin, and it passed all tests.  I used the shipped
``configure'', but adding -DPIC is not a new libtool behavior.

There was a thread about this general topic awhile ago.  That GMP actively uses
-DPIC to select the correct assembly came up:

http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html

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

Re: When is WinXP not WinXP?? - not *really* OT

[Daniel Miller]

Daniel Miller <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]: 

> Daniel Miller <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]: 
> 
> I propose that this is *not* really off-topic, since the problems that
> I'm experiencing do not occur in cmd.exe, nor in 4NT, only in Bash. 
> So it's something Bash is doing in its environment that is breaking
> StdOut, at least relative to whatever Win32 looks at.
> 
> BTW, I did not install Cygwin on the Home machine by copying from the
> other machine, I installed it using setup.exe, downloaded from Cygwin.
> 
> Also, in response to Dave Korn's previous message, GetLastError() is 
> returning error 6 (The handle is Invalid)...
> 
A further note is that handles returned by GetStdHandle() always have 
GENERIC_READ and GENERIC_WRITE access, "unless SetStdHandle function was 
used to set a standard handle to be some handle with a lesser access." 
(per MSDN).  Certainly  I didn't use SetStdHandle for *any* purpose, 
which is why the utility works under other shells.  Does Bash use 
SetStdHandle or some equivalent to change the console environment??

//  repeating the offending code snippet:
   /* get the standard handles */
   hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
   PERR(hStdOut != INVALID_HANDLE_VALUE, "GetStdHandle");

   //  get screen information.
   //  If this call fails, assume we are re-directing output.
   bSuccess = GetConsoleScreenBufferInfo(hStdOut, &sinfo) ;
   // PERR(bSuccess, "GetConsoleScreenBufferInfo");
   if (bSuccess == false) {
  fprintf(stderr, "gcsbi error: %s\n", get_system_message()) ;
  exit(1) ;
  redirected = 1 ;
  return ; 
   }


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

lseek 2GB wrap problem (with tail)?

[Alexander Geraldy]

Hello!
I've seen the following problem and don't know how to handle it.
Configuration: Cygwin 1.5.11-1, tail (textutils) 2.0.21, strace (cygwin) 
1.21

I noticed that various utilities (including grep and tail) have problems 
with the following textfile (let's call it test.txt):

"ls -l test.txt" gives  44589740378 (i.e. about 44 GB)
"tail test.txt" outputs some lines taken somewhere in the text file, but 
not the last lines of the file.
"strace tail test.txt" reports "lseek64: 1640067418=lseek(3,0,2)"

which obviously is filesize(test.txt) mod 2GB and which definitely does 
not point at the end of the input file.

I dont't know where to search the error, could anybody give me a hint?
Alexander Geraldy
--
--
Alexander Geraldy  <[EMAIL PROTECTED]>
AG Rechnernetze, Fachbereich Informatik
Universität Kaiserslautern
Tel.: +49(631) 205-2591,  Fax: -3956
PGP : http://rn.informatik.uni-kl.de/~geraldy/pgp.asc
Fingerprint:
  D7D0 6505 B731 2D4F 0481 FD86 EF5D B98A D05B 5F7E
--
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: inetd is unable to accept incoming connections when started as service on WinXP SP1

[Corinna Vinschen]

On Oct 13 17:45, [EMAIL PROTECTED] wrote:
> Igor,
> 
> thank you for quick replying.
> 
> I read the page following the link you gave me. It addresses another problem.
> 
> When I run 'inetd' from command line (bash) all works fine. That means there is
>  not a configuration problem.
> The key information is that 'inetd' refuses ALL incoming connections when
> started as a service, no port is reachable.
> I think there's a problem with 'accept' system call.

Sure it's not just a firewall problem?  I'm running XPsp2 with firewall
switched on and the firewall drops local packets the same way as remote
packets.  If I start inetd (as service) and try to connect to ftp w/o
having opened up port 21, it doesn't work.  If I open up port 21, I can
connect.  To get it working entirely, you also have to add
/usr/sbin/in.ftpd.exe to the allowed applications.  But it works usually.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

When is WinXP not WinXP?? - not *really* OT

[Daniel Miller]

Daniel Miller <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]: 

I propose that this is *not* really off-topic, since the problems that I'm 
experiencing do not occur in cmd.exe, nor in 4NT, only in Bash.  So it's 
something Bash is doing in its environment that is breaking StdOut, at 
least relative to whatever Win32 looks at.

BTW, I did not install Cygwin on the Home machine by copying from the other 
machine, I installed it using setup.exe, downloaded from Cygwin.

Also, in response to Dave Korn's previous message, GetLastError() is 
returning error 6 (The handle is Invalid)...

Dan


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

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Reini Urban]

Dave Korn schrieb:
  Time to start suspecting LSP problems, which I think are known to
sometimes damage the getXbyY functions.  Maybe "netsh winsock reset catalog"
(sp2 only) or http://www.cexx.org/lspfix.htm could help?
Thanks. This saved my day!
(Babylon was my culprit, but gDivx is also very common)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: libtool / assembler problem with -DPIC

[Reini Urban]

Charles Wilson schrieb:
Gerrit P. Haase wrote:
With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
generated assembly is broken.  I saw this problem with a
reautoconfiscated version of GMP.  This may be unusual, but there was
libtool used to invoke gas.
While -DPIC is a noop for usual compilation, it is harmful when used
as gas flag to compile assembly, I suggest to remove it entirely when
target is cygwin. Change would be in libtool.m4 line 4971 ff in
libtool-1.5.10.
Alternative: don't pass flag through when gas is called.
I don't see anywhere that "-DPIC" is ever invoked on cygwin.  Please 
send a patch to libtool.m4 that fixes the problem for you.
The problem is when a user (or makefile) adds this -DPIC, which does no 
harm usually. Gerrit thought that it might be clever to strip it on 
cygwin when gas is involved, since this does harm.
Or maybe emit a warning to fix the makefile for cygwin.
(Gerrit: Really -DPIC, not -fPIC?)

BTW, somebody mentioned libtool CVS branch-2.0 as being too "cutting 
edge" for cygwin use...FYI, libtool-cvs-branch2.0 passes ALL regression 
tests which is better than libtool has EVER done on our platform.  I'm 
thinking of releasing a test version of the next beta...
Ah! Cannot wait for that.
I couldn't find a fix for my -o  => exe problem so far.
And libtool --debug is soo huge.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

SableVM & Cygwin (was: Re: sablevm + windows)

[Gerrit P. Haase]

Hi Peter,

coming back to this now.

> I'm also willing to help port and maintain.

Fine.  I have to offer two possible scenarios.

1.
I have a stripped down standalone libffi package with a shared libffi
now.  This version is based on the sources from the cygwin release of
gcc-3.3.3. You can take this package and maintain it, that means update
it when Cygwin GCC is updated and integrate the changes happened in the
libffi subdirectory.

2.
Include this stripped down libffi version with the SableVM sourcetree
and link libffi into the main DLL as a convenience library.

IMO it would be easier to keep it uptodate when it is included with the
SableVM sources and also distributed this way.  So one can continue when
you or me are gone.

I have a patch I can send you, there is the stripped down libffi
integrated in the SablVM build.  The standalone libffi is available as
separate package from my webserver:
http://anfaenger.de/cygwin/cygwin-1.5/libffi-cygwin-standalone/

Ready compiled SableVM binary and source package:
http://anfaenger.de/cygwin/cygwin-1.5/saqblevm/

The source package includes also the patch and uses a statically libffi,
so it doesn't need a FFI DLL.  Could you verify that this SableVM works
as expected, please?

Classpath is still compiling.


Gerrit
-- 
=^..^= http://nyckelpiga.de/donate.html


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

Re: inetd is unable to accept incoming connections when started as service on WinXP SP1

[[EMAIL PROTECTED]]

Igor,

thank you for quick replying.

I read the page following the link you gave me. It addresses another problem.

When I run 'inetd' from command line (bash) all works fine. That means there is
 not a configuration problem.
The key information is that 'inetd' refuses ALL incoming connections when
started as a service, no port is reachable.
I think there's a problem with 'accept' system call.

Michele Liberi

-- Initial Header ---

From  : "Igor Pechtchanski" [EMAIL PROTECTED]
To  : [EMAIL PROTECTED]
Cc  : [EMAIL PROTECTED]
Date  : Tue, 12 Oct 2004 12:18:50 -0400 (EDT)
Subject : Re: inetd is unable to accept incoming connections when started as
service on WinXP SP1

> On Tue, 12 Oct 2004, mliberi wrote:
>
> > I downloaded on October, 7 a fresh cygwin package set, then I installed
> > it on an XP SP1 box.
> >
> > After reading inetutils*.README, I tried to setup inetd as a service,
> > with the following steps:
> >
> > 1. added CYGWIN='binmode tty ntsec' to environment variables set
> > 2.added c:\cygwin\bin to PATH environment variable
> > 3.run 'mount' to ensure that /usr/bin, /usr/lib and / mountpoints have
'system' attribute set.
> > 4.rebooted the box
> > 5.installed inetd as service, /usr/sbin/inetd --install-as-service
> > 6.manually started service using windows GUI
> >
> > All seems ok, ps -ef reports two instances of running inetd , as
> > expected.
> > But when I try a connection to any server present in /etc/inetd.conf, I
> > always obtain a 'can't connect' error message.
> > Example:
> > ftp localhost
> > .. connection refused
> > ftp>
> >
> > It seems that inetd can't 'accept' the incoming connection.
> >
> > If I start inetd from command line (not as a service), all works fine.
> >
> > Does anybody know how to get it working as a service?
>
> It's hard to guess given the amount of information you provided, but it's
> possible that  could be
> useful for you as well.
>   Igor
> --
>   http://cs.nyu.edu/~pechtcha/
>   |\  _,,,---,,_  [EMAIL PROTECTED]
> ZZZzz /,`.-'`'-.  ;-;;,_  [EMAIL PROTECTED]
>  |,4-  ) )-,_. ,\ (  `'-' Igor Pechtchanski, Ph.D.
> '---''(_/--'  `-'\_) fL   a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!
>
> "Happiness lies in being privileged to work hard for long hours in doing
> whatever you think is worth doing."  -- Dr. Jubal Harshaw
> 




Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione. 
Abbonati subito su http://www.libero.it 



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

Re: Bash: when is WinXP not WinXP??

[Christopher Faylor]

On Wed, Oct 13, 2004 at 10:49:55AM +0100, Dave Korn wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Daniel Miller
>> Sent: 13 October 2004 01:57
>
>>hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
 ^
>>PERR(hStdOut != INVALID_HANDLE_VALUE, "GetStdHandle");
>>bSuccess = GetConsoleScreenBufferInfo(hStdOut, &sinfo) ;
>>if (bSuccess == false) {
>>   //  this returned "The handle is invalid"
>>   fprintf(stderr, "gcsbi error: %s\n", get_system_message()) ;
>>   exit(1) ;
>>   redirected = 1 ;
>>   return ; 
>>}
>
>  Hmm.  That's the first time I've heard of GetConsoleScreenBufferInfo.
>Let's see what MSDN says about it:
>
>
>The GetConsoleScreenBufferInfo function retrieves information about the
>specified console screen buffer. 
>
>Parameters
>hConsoleOutput 
>[in] Handle to a console screen buffer. The handle must have GENERIC_READ
  
>access. 
>lpConsoleScreenBufferInfo 

>Right.  So I would suggest that all you can reasonably infer from
>bSuccess being false is that the function failed.  You are going one
>step beyond that in deducing that if the function fails, the handle
>must not be a console screen buffer handle.  There are of course other
>reasons why the function might fail.  You should have called
>GetLastError, then you'd have more information about what was going on.

Bingo.  Like, maybe the STD_OUTPUT_HANDLE doesn't have GENERIC_READ access?

cgf

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

RE: Problem installing PerlMagick 6.02

[Bryan Thrall]

Gerrit P. Haase wrote:
> Hello Bryan,
>
> Am Freitag, 8. Oktober 2004 um 19:23 schriebst du:
>
>> I am trying to install PerlMagick on my WinXP box with Cygwin, and
>> everything seems to install (after some tweaking of the build
>> process, described below) fine.  Except that none of the PerlMagick
>> tests pass and when I run the demo, I get this error:
>
>> PerlMagick-6.02/demo$ make
>> perl demo.pl
>> Read...
>> Exception 435: unable to open image `': No such file or directory at
>> demo.pl line 14. Exception 435: unable to open image `': No such
>> file or directory at demo.pl line 18. Exception 410: no images
>> defined `label' at demo.pl line 19.
>> make: *** [all] Error 10
>
>
>> Using the Cygwin ImageMagick package.  I've also built and installed
>> ImageMagick 6.08 myself and have no problems with it (display and
>> convert work fine, for example). ImageMagick is installed in
>> /usr/local. The errors produced from my own ImageMagick install are
>> slightly different:
>
>> PerlMagick-6.02/demo$ make
>> perl demo.pl
>> Read...
>> Exception 435: unable to open image `ck': No such file or directory
>> at demo.pl line 14. Exception 435: unable to open image `f': No such
>> file or directory at demo.pl line 18. Exception 410: no images
>> defined `label' at demo.pl line 19.
>> make: *** [all] Error 10
>
>> It looks like the image name is being truncated somehow ('ck' is the
>> last part of 'NULL:black' and 'f' is the last part of 'model.gif'),
>> but I don't know enough about DLLs and perl to guess why that might
>> be happening.
>
> There is a bug in cygwin-1.5.11, do you use 1.5.11?
> Then please try the latest snapshot and report back.
>
> And update ExtUtils::MakeMaker, the .dll.a bug was fixed a year ago,
> but it seems that MakeMaker in the stable release of perl was not
> updated.
>
>
> Gerrit

I think I know what the problem was, now.  I thought I'd uninstalled the
Cygwin ImageMagick packages, but for some reason I still had libMagick6 on
my system.  So, while some stuff worked fine and display gave me 6.0.8 as
the version, PerlMagick was dynamically loading the 6.0.4 DLL.  Obviously,
there's a mismatch there.  When I finally figured this out and removed the
libMagick6 package, everything worked fine.

I now also have PerlMagick (from ImageMagick's 6.0.4-5 release) running fine
with Cygwin's ImageMagick packages, though I had to copy a couple of
ImageMagick 6.0.4-5's mgk files into /usr/lib/ImageMagick-6.04/config
(namely coder.mgk, log.mgk, and magic.mgk).

Thanks for listening, everything's resolved now :-)

--
Bryan Thrall
Realtime Software Engineer
FlightSafety International


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

Re: script replacement: ttyrec-1.0.6 ported

[Christopher Faylor]

On Wed, Oct 13, 2004 at 12:42:52PM +0200, Gerrit P. Haase wrote:
>sionce it is requested often, I ported a replacement for script:
>ttyrec-1.0.6: http://namazu.org/~satoru/ttyrec/
>
>Patch is attached.

I don't recall script being requested often but if it was why wouldn't
we just package up script?

cgf

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

Re: non-interactive cygwin setup

[Christopher Faylor]

On Wed, Oct 13, 2004 at 01:01:07PM +0100, Dave Korn wrote:
>> -Original Message-
>> From: cygwin-owner On Behalf Of Rainer Hochreiter
>> Sent: 13 October 2004 08:32
>
>>is there a chance to install cygwin without gui dialog?
>>
>>my plan is to download all needed packages into a local directory and
>>then install the packages from that local directory by starting setup
>>from a command line without further user interaction.
>
>"setup.exe --help" gives this output, which for some bizarre reason it
>places in the setup.log file...

Probably because a GUI app can't communicate with the console.

cgf

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

Re: cygwin & openssh(d) & login without password

[Christopher Faylor]

On Tue, Oct 12, 2004 at 08:33:52PM -0700, Joshua Daniel Franklin wrote:
>On Sat, 9 Oct 2004 09:13:21 -0700 (PDT), Vince Rice wrote:
>> Lots of things are "obvious" to an experienced user that aren't to a
>> new user (something I'm thankfully reminded of every time I sit with my wife at
>> a computer for more than five minutes).  And the steps lex ein laid are
>> extremely accurate.  For a new user.
>
>I agree with Chris that this is a Unix/Linux problem and not
>Cygwin-specific, and thus off-topic for this mailing list.  However, I
>would like our documentation to be improving and I am open to
>suggestions that might have helped in this case.
>
>On the other hand, I also believe that for every beginning user that
>has trouble installing from confusion, there are probably many who look
>at the FAQ or User's Guide, both of which answer questions about
>finding documentation:
>
>

Did you see my suggestion that we should mention the existence of the
man and info commands in the FAQ entry?

cgf

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

Re: No longer works.

[David Baron]

OK -- here is the result of cygcheck:


Cygwin Win95/NT Configuration Diagnostics
Current System Time: Wed Oct 13 15:39:28 2004

Windows 98 Ver 4.10 Build 1998 

Path: C:\
 C:\WIN98
 C:\WIN98\COMMAND
 C:\WIN98\SYSTEM32
 C:\WIN98\SYSTEM
 C:\PROGRA~1\EXECUT~1\DISKEE~5
 C:\PROGRA~1\INTERAD\BUILDI~1
 C:\PERL\BIN
 C:\PROGRA~1\COMMON~1\NTONYX

SysDir: C:\WIN98\SYSTEM
WinDir: C:\WIN98

HOME = `D:\cygwin\setups'
PWD = `/cygdrive/d/cygwin/bin'

CMDLINE = `bash --login -i'
COMSPEC = `C:\COMMAND.COM'
JAVA_HOME = `C:\j2sdk1.4.2_02'
LMOUSE = `C:\MOUSE'
PROMPT = `$p$g'
SHLVL = `1'
SNDSCAPE = `C:\WIN98'
TEMP = `C:\TEMP'
TERM = `cygwin'
TMP = `C:\WIN98\TEMP'
WINBOOTDIR = `C:\WIN98'
WINDIR = `C:\WIN98'
_ = `./cygcheck'
POSIXLY_CORRECT = `1'

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\mounts v2\/
  (default) = `D:\cygwin\setups'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `D:\cygwin\setups/bin'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `D:\cygwin\setups/lib'
  flags = 0x0002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts 
v2\/usr/X11R6/lib/X11/fonts
  (default) = `D:\CYGWIN\USR\X11R6\LIB\X11\FONTS'
  flags = 0x000a
HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options

a:  fd   N/AN/A
c:  hd  FAT32  16368Mb  40% CPUN   WIN-MASTER
d:  hd  FAT32   5964Mb  55% CPUN   CYGWIN
e:  hd  FAT32  15788Mb  33% CPUN   WIN DATA
f:  hd  FAT32  19064Mb  34% CPUN   AUDIO DATA
x:  cd   N/AN/A
y:  cd   N/AN/A

D:\cygwin\setups   / userbinmode
D:\cygwin\setups/bin   /usr/bin  userbinmode
D:\cygwin\setups/lib   /usr/lib  userbinmode
.  /cygdrive user
binmode,cygdrive
D:\CYGWIN\USR\X11R6\LIB\X11\FONTS  /usr/X11R6/lib/X11/fonts  system  binmode

Not Found: awk
Found: .\bash.exe
Found: .\cat.exe
Found: .\cp.exe
Found: .\cpp.exe
Found: .\find.exe
Found: C:\WIN98\COMMAND\find.exe
Warning: .\find.exe hides C:\WIN98\COMMAND\find.exe
Found: .\gcc.exe
Found: .\gdb.exe
Found: .\grep.exe
Found: .\ld.exe
Found: .\ls.exe
Found: .\make.exe
Found: .\mv.exe
Found: .\rm.exe
Found: .\sed.exe
Found: .\sh.exe
Found: .\tar.exe

  330k 2004/02/09 .\cyghttpd.dll - os=4.0 img=1.0 sys=4.0
  "cyghttpd.dll" v0.0 ts=2004/2/9 20:14
7k 2003/10/19 .\cygcrypt-0.dll - os=4.0 img=1.0 sys=4.0
  "cygcrypt-0.dll" v0.0 ts=2003/10/19 9:57
  617k 2004/03/22 .\cygcurl-2.dll - os=4.0 img=1.0 sys=4.0
  "cygcurl-2.dll" v0.0 ts=2004/3/22 17:52
   22k 2004/02/10 .\cygcygipc-2.dll - os=4.0 img=1.0 sys=4.0
  "cygcygipc-2.dll" v0.0 ts=2004/2/10 4:48
  155k 2004/01/07 .\cygexpat-0.dll - os=4.0 img=1.0 sys=4.0
  "cygexpat-0.dll" v0.0 ts=2004/1/7 18:14
  654k 2003/11/04 .\cygfltknox-0.dll - os=4.0 img=1.0 sys=4.0
  "cygfltknox-0.dll" v0.0 ts=2003/11/4 23:57
   65k 2003/11/04 .\cygfltknox_forms-0.dll - os=4.0 img=1.0 sys=4.0
  "cygfltknox_forms-0.dll" v0.0 ts=2003/11/4 23:57
   81k 2003/11/04 .\cygfltknox_gl-0.dll - os=4.0 img=1.0 sys=4.0
  "cygfltknox_gl-0.dll" v0.0 ts=2003/11/4 23:58
  108k 2003/11/04 .\cygfltknox_images-0.dll - os=4.0 img=1.0 sys=4.0
  "cygfltknox_images-0.dll" v0.0 ts=2003/11/4 23:58
  167k 2003/09/09 .\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
  "cyggmp-3.dll" v0.0 ts=2003/9/10 0:03
 1506k 2003/11/05 .\cyggsl-0.dll - os=4.0 img=1.0 sys=4.0
  "cyggsl-0.dll" v0.0 ts=2003/11/5 23:19
  190k 2003/11/05 .\cyggslcblas-0.dll - os=4.0 img=1.0 sys=4.0
  "cyggslcblas-0.dll" v0.0 ts=2003/11/5 22:35
   12k 2003/02/17 .\cygioperm-0.dll - os=4.0 img=1.0 sys=4.0
  "cygioperm-0.dll" v0.0 ts=2003/2/17 21:58
   48k 2003/08/10 .\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
  "cygjbig1.dll" v0.0 ts=2003/8/11 1:58
  802k 2003/09/15 .\cygaspell-15.dll - os=4.0 img=1.0 sys=4.0
  "cygaspell-15.dll" v0.0 ts=2003/9/15 14:32
   54k 2002/01/27 .\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
  "cygbz21.0.dll" v0.0 ts=2002/1/27 3:07
   61k 2003/08/09 .\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
  "cygbz2-1.dll" v0.0 ts=2003/8/9 8:35
   14k 2003/08/10 .\cygcharset-1.d

Re: Tcl doesn't build out of src repository on cygwin

[Corinna Vinschen]

On Oct 13 15:01, Dave Korn wrote:
> > From: cygwin-owner On Behalf Of Corinna Vinschen
> >   That's solved in w32api in
> > CVS or in recent snapshots.  Or (but that's ugly and not actually
> > recommended, use at your own risk) use #define __INSIDE_CYGWIN__
> > at the beginning of the affected files (tclWin32Dll.c and tkWinX.c
> > AFAIK)
> 
>   Or use CFLAGS='-D__INSIDE_CYGWIN__ -g -O2' on the command line,
> presumably?

DDT

Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

RE: Tcl doesn't build out of src repository on cygwin

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 13 October 2004 14:53

> On Oct 13 13:15, Dave Korn wrote:
> > 
> > 
> >   Should it?  I see loads of error messages caused by a bad 
> table of static
> > initialisers in src/tcl/win/tclWin32Dll.c.
> 
> It happens because DLLIMPORT is used a lot in w32api which is only
> conditionalized with __INSIDE_CYGWIN__.  That's solved in w32api in
> CVS or in recent snapshots.  Or (but that's ugly and not actually
> recommended, use at your own risk) use #define __INSIDE_CYGWIN__
> at the beginning of the affected files (tclWin32Dll.c and tkWinX.c
> AFAIK)

  Or use CFLAGS='-D__INSIDE_CYGWIN__ -g -O2' on the command line,
presumably?

  Thanks Corinna.  I wasn't sure if there was a better list to bring this up
on, since Tcl isn't a sourceware project; then again, since the build
failure was cygwin-specific, I guess it was on-topic anyway.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Tcl doesn't build out of src repository on cygwin

[Corinna Vinschen]

On Oct 13 13:15, Dave Korn wrote:
> 
> 
>   Should it?  I see loads of error messages caused by a bad table of static
> initialisers in src/tcl/win/tclWin32Dll.c.

It happens because DLLIMPORT is used a lot in w32api which is only
conditionalized with __INSIDE_CYGWIN__.  That's solved in w32api in
CVS or in recent snapshots.  Or (but that's ugly and not actually
recommended, use at your own risk) use #define __INSIDE_CYGWIN__
at the beginning of the affected files (tclWin32Dll.c and tkWinX.c
AFAIK)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: script replacement: ttyrec-1.0.6 ported

[Reini Urban]

Gerrit P. Haase schrieb:
since it is requested often, I ported a replacement for script:
ttyrec-1.0.6: http://namazu.org/~satoru/ttyrec/
Patch is attached.
Great!
Don't we want that as package? I do.
Maybe with the java class ttyplayer.class and some example data also.
In Debian it's in bsdutils, but the player implemented in perl.
Having them seperate from bsdutils and all three as binaries is an 
advantage IMHO. Though having the original bsdutils 
script(1)/ttyrec/ttyplay would also be ok.
http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=bsdutils&version=stable&arch=i386

OT: And I'd really like to see something like that
http://kakugawa.aial.hiroshima-u.ac.jp/misc/ttyplayer/tty-ttydump-develop.html
from cgf or corinna then. Rebuilding winsup, debugging cygserver, ...
I bet you see the difference to bsdutils then.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Buffered output/Forked processes

[Nuno Leitao]

  Sorry, I should have stated my question better -- look at the following command on 
cygwin:

  % vmstat 1 > somefile.txt &
  (...time passes...)
  % ls -la somefile.txt
  -rw-r--r--1 leitaon  mkgroup-  0 Oct 13 13:48 somefile.txt
  (...time passes...)
  % ls -la somefile.txt
  -rw-r--r--1 leitaon  mkgroup- 4096 Oct 13 13:52 somefile.txt
  
  What is going on is that vmstat/cygwin/glibc/whatever is just buffering the output 
until the buffer is full (4096 bytes) at which point it flushes it. The effect I want 
is for each line outputed from vmstat to go straight into the file (or in my original 
example, into the pipe and the Perl script) -- the problem is *not* on the Perl script 
but the way vmstat is buffering the output.

  Any clues ?

  Thanks.

--Nuno.


-Original Message-
From: Reini Urban [mailto:[EMAIL PROTECTED]
Sent: 13 October 2004 13:12
To: Nuno Leitao
Cc: '[EMAIL PROTECTED]'
Subject: Re: Buffered output/Forked processes


Nuno Leitao schrieb:
>   I have a Perl script which looks like:
> 
>   open( VMSTAT, "vmstat 5|" );
>   VMSTAT->autoflush( 1 );
>   while( ) {
>  print $_;
>   }
> 
>   Now, under Linux and other UNIX OS's this works fine, and "print $_" will
> print the vmstat output every 5 seconds since the output from vmstat is not
> buffered. Under Cygwin however, it seems vmstat will always buffer its
> stdout with the undesirable effect that lines come in batches as the output
> buffer gets full and is flushed by the Cygwin C libraries.
> 
>   Is there a way to go around this without having to patch and recompile
> vmstat or other binaries I might want to use in this way ?

basic perl question, not cygwin related.
$ perldoc -q buffer
$ perldoc -f select

cygwin perl doesn't honor $| ? not true.
Because you told VMSTAT not to buffer.
But you shold have told it to STDOUT.

open( VMSTAT, "vmstat 5|" );
VMSTAT->autoflush( 1 );
$| = 1; # STDOUT is selected so STDOUT will get unbuffered.
while( ) {
 print $_;
}


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


Please note that:
 
1. This e-mail may constitute privileged information. If you are not the intended 
recipient, you have received this confidential email and any attachments transmitted 
with it in error and you must not disclose, copy, circulate or in any other way use or 
rely on this information.
2. E-mails to and from the company are monitored for operational reasons and in 
accordance with lawful business practices.
3. The contents of this email are those of the individual and do not necessarily 
represent the views of the company.
4. The company does not conclude contracts by email and all negotiations are subject 
to contract.
5. The company accepts no responsibility once an e-mail and any attachments is sent.

http://www.integralis.com


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

Tcl doesn't build out of src repository on cygwin

[Dave Korn]

  Should it?  I see loads of error messages caused by a bad table of static
initialisers in src/tcl/win/tclWin32Dll.c.


cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: non-interactive cygwin setup

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Rainer Hochreiter
> Sent: 13 October 2004 08:32

> is there a chance to install cygwin without gui dialog?
> 
> my plan is to download all needed packages into a local directory
> and then install the packages from that local directory by starting
> setup from a command line without further user interaction.

"setup.exe --help" gives this output, which for some bizarre reason it
places in the setup.log file...

2004/10/07 10:19:09 Starting cygwin install, version 2.437
2004/10/07 10:19:09 Current Directory: C:\install-cyg
2004/10/07 10:19:09 
Command Line Options:
 -D --download  Download from internet
 -L --local-install Install from local directory
 -s --site  Download site
 -R --root  Root installation directory
 -q --quiet-modeUnattended setup mode
 -h --help  print help
 -l --local-package-dir Local package directory
 -r --no-replaceonrebootDisable replacing in-use files on
next
reboot.
 -5 --no-md5Suppress MD5 checksum verification
 -n --no-shortcuts  Disable creation of desktop and
start
menu shortcuts
 -N --no-startmenu  Disable creation of start menu
shortcut
 -d --no-desktopDisable creation of desktop shortcut
 -A --disable-buggy-antivirus   Disable known or suspected buggy
anti
virus software packages during
execution.
Ending cygwin install

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

RE: other services ok, ftp not (was 1.5.11 - tcp problems)

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Corinna Vinschen
> Sent: 13 October 2004 09:43

> On Oct 13 00:05, Brian Dessent wrote:
> > Carlo Florendo wrote:
> > 
> > > Here's what I got:
> > > 
> > > getservbyname() returned NULL: Operation not permitted
> 
> Not good.


  Time to start suspecting LSP problems, which I think are known to
sometimes damage the getXbyY functions.  Maybe "netsh winsock reset catalog"
(sp2 only) or http://www.cexx.org/lspfix.htm could help?


cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Buffered output/Forked processes

[Nuno Leitao]

  Hi,

  I have a Perl script which looks like:

  open( VMSTAT, "vmstat 5|" );
  VMSTAT->autoflush( 1 );
  while( ) {
 print $_;
  }

  Now, under Linux and other UNIX OS's this works fine, and "print $_" will
print the vmstat output every 5 seconds since the output from vmstat is not
buffered. Under Cygwin however, it seems vmstat will always buffer its
stdout with the undesirable effect that lines come in batches as the output
buffer gets full and is flushed by the Cygwin C libraries.

  Is there a way to go around this without having to patch and recompile
vmstat or other binaries I might want to use in this way ?

  Thanks and best regards,

--Nuno.


Please note that:
 
1. This e-mail may constitute privileged information. If you are not the intended 
recipient, you have received this confidential email and any attachments transmitted 
with it in error and you must not disclose, copy, circulate or in any other way use or 
rely on this information.
2. E-mails to and from the company are monitored for operational reasons and in 
accordance with lawful business practices.
3. The contents of this email are those of the individual and do not necessarily 
represent the views of the company.
4. The company does not conclude contracts by email and all negotiations are subject 
to contract.
5. The company accepts no responsibility once an e-mail and any attachments is sent.

http://www.integralis.com


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

Re: libtool / assembler problem with -DPIC

[Gerrit P. Haase]

Charles wrote:

> Gerrit P. Haase wrote:
>> With GNU as PIC is not an noop, when -DPIC is used to invoke gas the
>> generated assembly is broken.  I saw this problem with a
>> reautoconfiscated version of GMP.  This may be unusual, but there was
>> libtool used to invoke gas.
>> 
>> While -DPIC is a noop for usual compilation, it is harmful when used
>> as gas flag to compile assembly, I suggest to remove it entirely when
>> target is cygwin. Change would be in libtool.m4 line 4971 ff in
>> libtool-1.5.10.
>> 
>> Alternative: don't pass flag through when gas is called.

> I don't see anywhere that "-DPIC" is ever invoked on cygwin.  Please 
> send a patch to libtool.m4 that fixes the problem for you.

> BTW, somebody mentioned libtool CVS branch-2.0 as being too "cutting 
> edge" for cygwin use...FYI, libtool-cvs-branch2.0 passes ALL regression
> tests which is better than libtool has EVER done on our platform.  I'm
> thinking of releasing a test version of the next beta...

--- libtool.m4~ 2004-08-04 13:08:29.955128000 +0200
+++ libtool.m4  2004-08-04 13:09:27.497870400 +0200
@@ -4972,6 +5028,9 @@ case "$host_os" in
   *djgpp*)
 _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
 ;;
+  *cygwin*)
+_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
+;;
   *)
 _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, 
$1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])"
 ;;


-- 
=^..^= http://nyckelpiga.de/donate.html


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

[ANNOUNCEMENT] NEW: cyrus-sasl-2.1.19-1, libsasl2-2.1.19-1, libsasl2-devel-2.1.19-1

[Gareth Pearce]

The Cyrus SASL API implementation is now available via the cygwin mirrors.
This library allows applications the ability to authenticate and secure
connections between client and server via a standardised method.  It is an
extensible system which supports many different authentication techniques
via a pluggable approach.  

See http://asg.web.cmu.edu/sasl/sasl-library.html for more information.


---
Gareth Pearce
Panareef Pty. Ltd. (http://www.panareef.com/)



To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.



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

Re: Backup script not working properly

[Brian Dessent]

Fredrik Persson wrote:

> All works but for the last for-loop which is responsible for deleting old
> backups such that only NUMBKPS=4 of the last backups are stored.
> 
> The problem is in 'if [ ${num} -le 0 ]' and 'else num=$((${num}-1))'. It seems
> like the num-variable can't be used as an integer. Any suggestions how to fix
> this???

On Linux, /bin/sh is /bin/bash.  This is not the case on Cygwin and
other *nixs.  The "$((...))" thing is a bash feature/extension I think,
and not found in the standard Bourne shell.  Try using the expr command
instead to do math, or change the shebang to call bash explicitly.

Brian

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

script replacement: ttyrec-1.0.6 ported

[Gerrit P. Haase]

Hello,

sionce it is requested often, I ported a replacement for script:
ttyrec-1.0.6: http://namazu.org/~satoru/ttyrec/

Patch is attached.


Have fun,
Gerrit
-- 
=^..^=

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

Backup script not working properly

[Fredrik Persson]

I have used a very nice backup script i Linux which i now want to use in 
cygwin. 

--
#!/bin/sh
# for FULL backups
# this backs up the important stuffs listed in ${lists} to ${BKPDIR}
# the lists *should* be in ${BKPDIR} and named .lst
# the resulting backups will be ..tgz
#
# notes:
# - assumes ${BKPDIR} is unmounted and has an /etc/fstab entry
# - assumes /boot is unmounted and has an /etc/fstab entry
# - variables in CAPS are ok for you to set... change the other
#   vars if you know what you're doing
# - you can get fancy in the lists... think xargs *wink*, but
#   you can't use thes spanning feature to break up an
#   archive to smaller pieces of arbitrary size
# - follow your security policy when setting perms on ${BKPDIR}
#
# written by razamatan
#
# DISCLAIMER: razamatan didn't write this if something goes wrong
BKPDIR=/cygdrive/d/backup   # where the backups go
#BOOT=sys   # list that has /boot
NUMBKPS=4   # how many backups to keep
if [ ! -d ${BKPDIR} ] ; then
echo ${BKPDIR} is not a valid directory or does not exist
fi
#mount ${BKPDIR}# i have my backup directory on a seperate 
partition
lists=${BKPDIR}/*.lst
ext=tgz
for list in `ls ${lists}`; do
type=`basename ${list} .lst`
#if [ ${type} = ${BOOT} ] ; then mount /boot ; fi
cat ${list} | xargs tar zlcf \
${BKPDIR}/${type}.`date +%Y-%m-%d-%H%M`.${ext} > /dev/null 2>&1
#if [ ${type} = ${BOOT} ] ; then umount /boot ; fi
num=${NUMBKPS}
for evict in `ls -t ${BKPDIR}/${type}.*.${ext}`; do
echo ${evict}
if [ ${num} -le 0 ] ; then rm -f ${evict}
else num=$((${num}-1)) ; fi
done
done
#umount ${BKPDIR}   # and i like to keep it unmounted
--

All works but for the last for-loop which is responsible for deleting old 
backups such that only NUMBKPS=4 of the last backups are stored.

The problem is in 'if [ ${num} -le 0 ]' and 'else num=$((${num}-1))'. It seems 
like the num-variable can't be used as an integer. Any suggestions how to fix 
this???



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

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Brian Dessent]

Carlo Florendo wrote:

> Anyway, I got this error:
> 
> getservbyname() returned NULL: win32 error 11004

Googling shows that this is consistent with trying to run a
program/server that tries to look up its port in the services file when
no such matching line exists.

> I also read the message regarding the \r\n and \n line endings (still
> not in my mailbox) and Corinna's reply.  I've checked the services file
> and confirmed that the line endings are \r\n  (with the simple test of
> ^M showing up when invoking `vim -b'.  Notepad also views the file
> correctly, thus it's really \r\n.).
> 
> I'm confident we're getting close!

Closer yes, but I'm afraid I don't have much else coming to mind. 
Everything indicates that it's not finding what it's looking for in the
services file.  Maybe some spaces got replaced by tabs and windows
cannot cope?  Maybe your cat walked across the keyboard when you had the
file open in an editor?  :-)  Try the minimal services file necessary:

cd `cygpath -u $SYSTEMROOT/system32/drivers/etc`
mv services services.bak
echo "ftp 21/tcp" >services   # according to corinna there's no need for
\r here

If that fixes the testcase then gradually add back the rest of the stuff
in the file until you figure out what it is that's causing it to fail.

One thing is clear though, this is not a Cygwin problem.  The mingw
example shows a minimal testcase that involves no Cygwin code at all,
just direct calls to the Winsock functions.  I'm willing to bet if you
found a regular windows application that tried to look up a port using
getservbyname() it would fail in the same way.  This is a relatively
rare/antiquated thing to do as most apps either have the port
configurable via a URL or a config file, or they just hard-code it.

If you want a quick and dirty solution, comment out the call to
getservbyname in the ftp source code and modify it to assume port 21. 
But that's admitting defeat, really.

Brian

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

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Carlo Florendo]

Brian Dessent wrote:
Brian Dessent wrote:
 

cat 

RE: Bash: when is WinXP not WinXP??

[Dave Korn]

> -Original Message-
> From: cygwin-owner On Behalf Of Daniel Miller
> Sent: 13 October 2004 01:57

[Reply-To set on "TITTTL"!]

> "Dave Korn"  wrote in
> news:[EMAIL PROTECTED]: 

  Hey Dan!  http://cygwin.com/acronyms#PCYMTNQREAIYR !

> >> -Original Message-
> >> From: cygwin-owner On Behalf Of Daniel Miller
> >> Sent: 12 October 2004 19:06
> > 
> >> under Bash.  Under WXPPro/Bash it worked fine.  However, 
> under Home 
> >> edition, my utility apparently thinks its output is being 
> >> redirected, so it tries to generate the output as html code 
> >> (to preserve colors), which of course generates tons of garbage.
> > 
> >   Then your code has a bug.  Whatever technique it is using 
> to decide if it is being redirected is wrong.  

> Well, the code that's causing me to think I'm redirected is:
> 
>hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
>PERR(hStdOut != INVALID_HANDLE_VALUE, "GetStdHandle");
>bSuccess = GetConsoleScreenBufferInfo(hStdOut, &sinfo) ;
>if (bSuccess == false) {
>//  this returned "The handle is invalid"
>   fprintf(stderr, "gcsbi error: %s\n", get_system_message()) ;
>   exit(1) ;
>   redirected = 1 ;
>   return ; 
>}

  Hmm.  That's the first time I've heard of GetConsoleScreenBufferInfo.
Let's see what MSDN says about it:


The GetConsoleScreenBufferInfo function retrieves information about the
specified console screen buffer. 

Parameters
hConsoleOutput 
[in] Handle to a console screen buffer. The handle must have GENERIC_READ
access. 
lpConsoleScreenBufferInfo 

Return Values
If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error
information, call GetLastError. 


  Right.  So I would suggest that all you can reasonably infer from bSuccess
being false is that the function failed.  You are going one step beyond that
in deducing that if the function fails, the handle must not be a console
screen buffer handle.  There are of course other reasons why the function
might fail.  You should have called GetLastError, then you'd have more
information about what was going on.

> So even if I did as you suggest above, I would still have to 
> terminate my 
> program when GetConsoleScreenBufferInfo failed... 

  Or operate with different/reduced functionality.  Many *nix tools operate
differently, e.g. non-interactively, when used in pipes, e.g. 'man' or
'info'.

> Now *why* is that 
> function failing on hStdOut, which was not itself invalid (since 
> GetStdHandle succeeded)... ??  And again, why only on the 
> Home machine, 
> not on the Pro machine??

  Good question.  Is one of them SP2 but not the other?  I reckon it'll be
some kind of device perms/acls problem; let's see if GetLastError returns
ACCESS_DENIED or something else like INVALID_HANDLE.

  BTW, since this is really now about win32 coding and getting OT, I'm
redirecting it to the talk list.

cheers, 
  DaveK
-- 
Can't think of a witty .sigline today


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

Re: Bash: when is WinXP not WinXP??

[Corinna Vinschen]

On Oct 12 17:42, Brian Dessent wrote:
> Daniel Miller wrote:
> > I've already had *one* problem to solve under Home, for some reason
> > Executable flags are not set on files that I copy over the network; I
> > didn't even know Windows *had* executable flags, but I'd copy console
> > utilities which worked fine under XPPro (in both Bash and 4NT), but when I
> > copied them to XPHome and tried to run them, I'd get "access denied".  I
> > ran 'chmod 777' on these files and they all worked fine after that.
> 
> One of the things that MS removed from XP in creating the Home version
> was the ability to modify file ACLs.  The "security" properties tab that
> is normally used is absent.  I don't know if Windows uses some set of
> default/immutable ACLs under-the-hood, or if they simply removed the
> ability to query and set them from the front-end but left the underlying
> ACL machinery.  I suspect the latter.  In that case, when you copy files

You're right.  Under the hood it's a normal kernel and a normal NTFS.
Just the UI is crippled.  From the Cygwin perspective XP home and XP pro 
is the same system.

> via native windows methods, who knows what the ACL gets set to, since
> that version of Windows ostensibly does not support that feature at
> all.  Apparently since chmod and getfacl/setfacl still work then the low

AFAIR cacls is available also on XP home.  But setfacl/getfacl are working
fine, too, if POSIX permission sets are sufficient for you.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Corinna Vinschen]

On Oct 13 00:05, Brian Dessent wrote:
> Carlo Florendo wrote:
> 
> > Here's what I got:
> > 
> > getservbyname() returned NULL: Operation not permitted

Not good.

> Perhaps the line endings got screwed up in your services file at some
> point?  They should be DOS (\r\n) not unix (\n).

AFAIK and AFAICS, the line endings shouldn't affect NT systems (tested
on NT4sp6 and XPsp2).


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: Cron doesn't work

[Brian Dessent]

Marcos Rebelo wrote:

> $  cygrunsrv --start cron
> cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error
> 1062:
> The service has not been started.
> 
> Just the last one seems to be incorrect

This is your problem.  However, that is not the actual error.  It's just
telling you that the service couldn't start.  The real error message
will be in /var/log/cron.log and/or the Windows event log.

Brian

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

[ANNOUNCEMENT] Updated: ORBit2-2.12.0-1, ORBit2-devel-2.12.0-1

[Yaakov Selkowitz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The following packages have been updated in the Cygwin distribution:

*** ORBit2-2.12.0-1
*** ORBit2-devel-2.12.0-1

This is an update to the newest upstream release for GNOME 2.8.  In
addition, some Cygwin-related changes:

* Build fixes for gcc-3.3.3 (Gerrit Haase)
* Built against libintl3 (instead of libintl2)
* The libraries now require minires.

ORBit2 is a CORBA 2.4-compliant Object Request Broker (ORB)
featuring mature C and Perl bindings.  It supports POA, DII, DSI,
TypeCode, Any, IR and IIOP.  Optional features including INS and
threading are available. ORBit2 is engineered for the GNU Object Model
Environment (GNOME) with a focus on performance, low resource usage,
and security.

Yaakov

- --
~   *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBbKUfpiWmPGlmQSMRAlUKAKCZFZ0HKxzSKvGBeLhxJUsPPvlrUwCgky+D
75cJ9zuivWF/vYqa4yEC/L4=
=y1vK
-END PGP SIGNATURE-


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

RE: Cron doesn't work

[Marcos Rebelo]

I runed the script and evriting seems correct. Script Output

##

cron_diagnose.sh 1.6

This script did not find any errors in your crontab setup.
If you are still unable to get cron to work, then try
shutting down the cron service, uninstalling it,
reinstalling it, and restarting it.

The following commands will do that:
  $ cygrunsrv --stop cron
  $ cygrunsrv --remove cron
  $ cygrunsrv --install cron -p /usr/sbin/cron -a -D
  $ cygrunsrv --start cron

Also, examine the log file for cron, /var/log/cron.log, for
information that it might give you about the problem cron is
having.

If none of this fixes the problem, then report your problem
to [EMAIL PROTECTED]  Please include a copy of your crontab,
('crontab -l') and the output of 'cygcheck -srv > cygcheck.txt'.

Please include the generated file 'cygcheck.txt' *as an attachment*,
and NOT in the body of the mail message.

##

so runned the scripts

$ cygrunsrv --stop cron

$  cygrunsrv --remove cron

$ cygrunsrv --install cron -p /usr/sbin/cron -a -D

$  cygrunsrv --start cron
cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error
1062:
The service has not been started.

Just the last one seems to be incorrect

##

out from  'crontab -l'

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.2212 installed on Tue Oct 12 10:23:27 2004)
# (Cron version -- $Id: crontab.c,v 1.7 2003/04/15 15:13:41 corinna Exp
$)
*   *   *   *   *   'perl -w /cygdrive/c/Documents\
and\ Settings/mrebelo.EDISOFT/bin/cron/test.pl'
*   *   *   *   *   '/bin/echo "hello"'

##

Output from 'cygcheck -srv > cygcheck.txt'


Cygwin Configuration Diagnostics
Current System Time: Wed Oct 13 08:57:34 2004

Windows XP Professional Ver 5.1 Build 2600 Service Pack 2

Path:   ~\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
.\
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\j2sdk1.4.2_04\bin
c:\Perl\bin\
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Program Files\UltraEdit
c:\Program Files\ATI Technologies\ATI Control Panel
c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
c:\Program Files\Microsoft Visual Studio\Common\Tools
c:\Program Files\Microsoft Visual Studio\VC98\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11839(mrebelo) GID: 10513(mkgroup-l-d)
10513(mkgroup-l-d)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11839(mrebelo) GID: 10513(mkgroup-l-d)
0(root)  544(Administrators)  
545(Users)   10513(mkgroup-l-d)

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

HOME = `c:\Documents and Settings\mrebelo.EDISOFT'
MAKE_MODE = `unix'
PWD = `/cygdrive/c'
USER = `mrebelo'

!EXITCODE = `'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\mrebelo.EDISOFT\Application Data'
CLIENTNAME = `Console'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `EDWKN234'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
CVS_RSH = `/bin/ssh'
CYGWIN_ROOT = `\cygwin'
DISPLAY = `127.0.0.1:0.0'
EDITOR = `nedit'
FP_NO_HOST_CHECK = `NO'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\mrebelo.EDISOFT'
HOSTNAME = `edwkn234'
INCLUDE = `C:\Program Files\Microsoft Visual
Studio\VC98\atl\include;C:\Program Files\Microsoft Visual
Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual
Studio\VC98\include'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr
/autotool/stable/info:'
LIB = `C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program
Files\Microsoft Visual Studio\VC98\lib'
LOGNAME = `mrebelo'
LOGONSERVER = `\\EDISOFTNT02'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ss
l/man:/usr/X11R6/man'
MSDEVDIR = `C:\Program Files\Microsoft Visual Studio\Common\MSDev98'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/cygdrive/d'
OS = `Windows_NT'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 4, GenuineIntel'
PROCESSOR_LEVEL = `15'
PROCESSOR_REVISION = `0304'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PS1 = `\[\033]0;\w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
SESSIONNAME = `Console'
SHLVL = `2'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINDOWS'
TEMP = `c:\DOCUME~1\MREBEL~1.EDI\LOCALS~1\Temp'
TERM = `xterm'
TERMCAP = `xterm-r6|xterm|xterm X11R6
version:am:km:mi:ms:xn:co#150:it#8:li#45:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:D
O=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:ae=^O:al=\E[L:as=^N:bl=^

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Brian Dessent]

Carlo Florendo wrote:

> >Correction: add "-lws2_32" to the gcc options.
>
> Oh, thank you.  I've actually done it and my previous post actually
> shows the output of the executable compiled with
> 
> gcc -mno-cygwin -lws2_32  getservbyname-mingw.c
> 
> There's something definitely wrong here.  I know that doing the compile
> should work.

The order that you specify the options matters.  Put the "-lws2_32"
after the .c filename argument.

Brian

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

Re: Setup failure: mount error

[luke]

luke wrote:
Dave Korn wrote:

That's what I thought.  My problem was in trusting the Registry's search 
command.
Actually, the search is relative to whatever key you have selected.
So, to search the whole registry you have to select the root.
Unfortunately, it's still failing.
Are there any other places in the registry that Cygwin data is kept?
At the moment, it looks like I'm going to have to scrub Windows and 
re-install it.

I suppose before that, I can try installing from our stable mirror.
Perhaps the Cygwin on the mirror site is badly buggy (despite all MD5
checksums being correct).
Right now I'll try again, this time deleting both known keys, deleting 
all the download files, deleting the 300kb of installed Cygwin files,
rebooting, and starting again.
That didn't work, either.  Same alert panel titled "mount" that says: 
"The operation completed successfully."

This happens at the 99% Cygwin Setup stage, Downloading.  Progress bars look
to be about 80% for "Progress:", 99 or 100% for "Total:", and about 5%
for "Disk:".
luke
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Carlo Florendo]

Brian Dessent wrote:
Brian Dessent wrote:
 

cat 

non-interactive cygwin setup

[Rainer Hochreiter]

is there a chance to install cygwin without gui dialog?

my plan is to download all needed packages into a local directory
and then install the packages from that local directory by starting
setup from a command line without further user interaction.

-- rainer


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

Re: other services ok, ftp not (was 1.5.11 - tcp problems)

[Brian Dessent]

Carlo Florendo wrote:

> Here's what I got:
> 
> getservbyname() returned NULL: Operation not permitted

Hmm.  That's the same thing I get if I rename my "services" file to
something else so that it's not found.  But it seems we've already
thoroughly checked that.  If you also get win32 error 11004 ("The
requested name is valid and was found in the database, but it does not
have the correct associated data being resolved for") for the mingw
version then that strongly suggests something is still not right with
the services file.  However, an error when running the mingw version at
least tells us that it's not Cygwin, since the Cygwin DLL is not loaded
for that one.

Perhaps the line endings got screwed up in your services file at some
point?  They should be DOS (\r\n) not unix (\n).

Brian

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

Re: Setup failure: mount error

[luke]

Dave Korn wrote:
>>-Original Message-
>>From: cygwin-owner On Behalf Of luke.kendall
>>Sent: 12 October 2004 09:00
>
>
>>The registry contained the key
>>HKCU->Software->Cygnus Solutions->Cygwin->mounts v2-> with nothing (to
>>be precise: Name (Default), Type REG_SZ, Data (value not set)).
>>
>>But deleting the Cygnus Solutions tree doesn't help.
>
>
>   Sounds like you forgot to delete the same tree under HKLM then?
Well, I did a search on the registry.  But you're quite right: a 2nd 
entry was there.  (The registry "find" doesn't work unless you have the 
HKCU or HKLM root key open for the tree the key appears in.)

Thanks, Dave.
But it hasn't helped.  :-(
>>I just tried again, except not deleting the download directory, and
>>this time it checks the md5 signatures, shows that it had
>>just finished
>>checking MD5 for _update-info-dir-00230-1, the alert panel with the
>>window-title of "mount" pops up and says:
>>
>>"Cannot create a file when that file exists." (Okay).
>>
>>and setup then exits.
BTW, that information I gave was incorrect.  When I left the files in 
the temp download directory, the error message from the mount alert 
window was different.  It said "The operation completed successfully."

This is at the 99% Cygwin Setup stage, Downloading.  Progress bars look 
to be about 80% for "Progress:", 99 or 100% for "Total:", and about 5% 
for "Disk:".

>>I should also add that I've tried a reboot in between.
>
>
>   Well, what went wrong in the first place was presumably a dll-clash
> between the two cygwin dlls, which had the consequence of messing up 
_all_
> of the postinstall scripts that setup.exe usually runs to take care of
> creating some very vital parts of infrastructure.  Although the old 
cygwin
> dll has now gone, what you were left with was a *very* damaged 
fragmentary
> cygwin install.  But as long as you've correctly deleted all trace of it,
> you should have no subsequent trouble.  That means removing the cygwin
> install dir, the setup downloaded files dir, and _both_ registry keys.

That's what I thought.  My problem was in trusting the Registry's search 
command.

Unfortunately, it's still failing.
Are there any other places in the registry that Cygwin data is kept?
Right now I'll try again, this time deleting both known keys, deleting 
all the download files, deleting the 300kb of installed Cygwin files,
rebooting, and starting again.

luke
PS: I'm sending this from Thunderbird, so I hope the fullname is adequate.
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/