Re: Timestamp not preserved by Cygwin sshd

[Alex Luso]

  Alright, so the simplest solution was indeed to
switch to WinSCP client which does indeed preserve the
timestamp of the copied file correctly (and not a bad
GUI interface to boot). This resolved the
incompatibility between the -p switch from non-OpenSSH
clients and cygwin's OpenSSHD.

Thanks for the help Chris.
-Alex

P.S. Just as an aside - it turns out, however, that
now the timestamp of the folders are not preserved.
This is not a big deal but def. strange as the use of
non-OpenSSH clients preserved the folder's timestamp
(although not the files within). Odd, odd, but not a
big deal. I will direct the question to WinSCP as this
has likely nothing to do with cygwin. 

--- Chris Taylor <[EMAIL PROTECTED]> wrote:

> Alex Luso wrote:
> >   Perhaps you are right and it doesn't have to do
> with
> > cygwin. I found this to happen when I tried to scp
> to
> > cygwin with two different clients from 2 different
> > machines (both non-OpenSSH, I believe). On the
> other
> > hand, when I scp in between these 2 clients, there
> was
> > no error. So I suppose this is an incompatibility
> > between different flavors of SSH?
> >   Can someone suggest a workaround - i.e. settings
> on
> > the server side (cygwin/OpenSSH) - that would
> resolve
> > the failure of the -p switch from a non-OpenSSH
> > client? I am using a nice gui for SCPing files
> between
> > windows machines (SSH Secure Shell 3.2) and would
> like
> > to be able to continue to use it.
> > 
> 
> Please don't top-post!
> 
> Anyway, a possible solution would be to use WinSCP -
> afaik this doesn't
> have any trouble preserving the timestamp. I know it
> doesn't with
> OpenSSH on debian, so I would assume this is also
> the case on cygwin -
> unfortunately I can't test this just now.
> It's also a very nice tool.. ;-)
> 
> 
> Chris
> 
> -- 
> 
> Spinning complacently in the darkness, covered and
> blinded by a blanket
> of little lives, false security has lulled the
> madness of this world
> into a slumber. Wake up! An eye is upon you, staring
> straight down and
> keenly through, seeing all that you are and
> everything that you will
> never be. Yes, an eye is upon you, an eye ready to
> blink. So face
> forward, with arms wide open and mind reeling. Your
> future has
> arrived... Are you ready to go?
> 
> --
> 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/
> 
> 





__ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.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/

SSH + rsync hangs

[Dan Horne]

I'm attempting to sync files over ssh from a Linux server to a cygwin
client. The command I issue is

rsync -avz -e ssh  [EMAIL PROTECTED]:/remote_dir .

but the request hangs. I can ssh directrly to the server from the cygwin
shell. If I increase the logging level, I get:

$ rsync -az -e ssh  [EMAIL PROTECTED]:/remote_dir .
cmd=ssh machine=host user=user path=/remote_dir
cmd=ssh -l root host rsync --server --sender -logDtprz . /remote_dir 
opening connection using ssh -l user host rsync --server --sender
-logDtprz . /remote_dir

and then it hangs. On ctrl-c:

_exit_cleanup(code=20, file=/home/lapo/packaging/tmp/rsync-2.6.6/rsync.c,
line=163): entered
rsync error: received SIGUSR1 or SIGINT (code 20) at
/home/lapo/packaging/tmp/rsync-2.6.6/rsync.c(163)
_exit_cleanup(code=20, file=/home/lapo/packaging/tmp/rsync-2.6.6/rsync.c,
line=163): about to call exit(20)


It works if I issue the same request from a RedHat 8 client to the same
server.

Cygwin Software versions:

openssh: 4.2p1-1
rsync: 2.6.6

I have also installed the latest version of cygwin

regards

Dan Horne



--
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: Problems opening files from run menu

[Larry Hall (Cygwin)]

Paminu wrote:
"Christopher Faylor" <[EMAIL PROTECTED]> skrev i en 
meddelelse ...



On Wed, Oct 19, 2005 at 04:38:43PM +0200, Paminu wrote:


I have a xfig file in:

c:\cygwin\home\test\test.fig

I can open this xfig file from the run menu like:
bash --login -e startxprog xfig c:/cygwin/home/test/test.fig

I also have a .dvi file in:
c:\cygwin\home\test\test.dvi

But when I type:
bash --login -e startxprog xdvi c:/cygwin/home/test/test.dvi

Nothing happens. Why is it possible to open a file like this with xfig but
not with xdvi???


How about using UNIX-like paths rather than Windows paths, that being
one the main reasons for Cygwin's existence?

bash --login -e startxprog xdvi /home/test/test.dvi




That works fine. But the problem is when I execute xdvi from emacs. Then 
this gets inserted:

c:/cygwin/home/test/test.dvi

if I could just get emacs to only type /home/test/test.dvi it would work.

But I think it is wierd that xfig accepts the full path while xdvi only 
accept the path excluding c:/cygwin, but maybe its a bug in xdvi. 



Hm.  If only there were some Cygwin utility that could do something
amazing like... I know!  It could take a DOS/Windows path and turn it
into a POSIX one for Cygwin.  Wouldn't that be neat?  I hope someone
someday makes just such a program.  Then things like emacs could use it
and the world would be right again.  And if someone ever did write such
a utility, I would suggest it be called some snazzy name like 'cygpath'.
Yeah, that has quite a ring to it.  Boy it will be a great day when we
have such a utility!*



* 'cygpath' already exists. :-)
--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
838 Washington Street   (508) 893-9889 - FAX
Holliston, MA 01746

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

nftw() [Was: "Unusual" contribution licensing problems]

[Érsek László]

On Thu, 20 Oct 2005, Brian Dessent wrote:

> Érsek László wrote:
>
> > after grepping the cygwin mailing list and my up-to-date cygwin
> > installation for "nftw" and "fts_open", I thought that it could make sense
> > (and fun) to implement nftw().
>
> Unfortunately (or perhaps fortunately) the whole discussion is moot
> because these functions were added to Cygwin several months ago by
> Corinna: .

Thank you for the information.

I looked at "fts.c" (1.1) and "nftw.c" (1.2). Since nftw() is handled as a
special case of fts_*(),

/* XXX - nfds is currently unused */

And currently,

/* Logical walks turn on NOCHDIR; symbolic links are too hard. */

I took care to support these features of nftw().

Furthermore, fts_*() is nonstandard, nftw() is standard. Of course, it is
possible that fts_*(), as specified, is superior to nftw(), as specified.

http://www.opengroup.org/austin/mailarchives/ag/msg01024.html
http://www.opengroup.org/austin/mailarchives/ag/msg01074.html

It is also possible that barely any application uses FTW_CHDIR without
FTW_PHYS, while many applications use fts_*(). Finally, PTC.

Apart from some grouching that I missed the "deadline" in August (which
actually is fortunate for everyone, I admit), I'm happy that cygwin
provides nftw(). I suppose it will appear in cygwin-1.5.19-1.

Thanks again! (And sorry for crossposting, I hope it's not forbidden.)

lacos

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

openssh connection multiplexing with cygwin

[Brian Dessent]

I've been trying to get the connection multiplexing feature of openssh
to work with Cygwin without success.

I set "ControlPath /tmp/ssh_%h_%r" in ~/.ssh/config.  Then I do

$ ssh -M -N -vvv host

which works fine, and there is a socket in /tmp:

$ ls -l /tmp/ssh*
srw---  1 brian None 53 Oct 20 16:30 /tmp/ssh_host_brian=

Then in another window I try:

$ ssh -vvv host
OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005
debug1: Reading configuration data /home/brian/.ssh/config
debug1: Applying options for *
debug1: Applying options for host
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 1
mm_send_fd: sendmsg(2): Software caused connection abort

The first ssh (master) has now died, with the following messages being
printed after the above command was executed:

debug1: fd 5 clearing O_NONBLOCK
debug3: ssh_msg_recv entering
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: client_process_control: receiving 0 env vars
debug2: client_process_control: accepted tty 1, subsys 0, cmd 
mm_receive_fd: no fd

Is this a limitation of Cygwin's unix socket emulation, openssh bug, or
something else?  Below is some information about the installed versions:

The local ssh is the packaged 4.2p1-1:
$ ssh -v 
OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005

The remote ssh is:
$ ssh -v   
OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8 05 Jul 2005

I am running cygwin1.dll and cygserver.exe from CVS as of an hour ago:

$ uname -a
CYGWIN_NT-5.1 booch 1.5.19(0.141/4/2) 2005-10-20 16:11 i686 unknown
unknown Cygwin

$ cygserver -v
cygserver: (cygwin) 1.12
API version 1.5.19(0.141/4/1)-(3.0.0.2) 2005-10-20 16:11
Copyright 2001, 2002, 2003, 2004, 2005 Red Hat, Inc.
Compiled on Oct 20 2005
Default configuration file is /usr/local/etc/cygserver.conf

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: making .so files...

[Jason Pyeron]

On Thu, 20 Oct 2005, Yaakov S (Cygwin Ports) wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Pyeron wrote:

I am working with the Asterisk application, it uses "modules" these are
.so files which are linked against the main executable.

Asterisk will load a module, which may or may not make use of code
exported by the main executable.


If I understand you correctly, then it's not so difficult; I've done it
myself with bmp, gedit, gthumb, liferea, and xmms.

I don't know Asterisk, but it doesn't appear to use autotools; this
makes things more difficult, especially if you want to make a portable
patch.

First, make sure that the asterisk executable is built *first*; you may
need to precede '.' to the SUBDIRS variable (i.e. SUBDIRS = . subdir1
subdir2 etc.)

Add the following to the asterisk executable's LDFLAGS:
'-Wl,--export-all-symbols,--out-implib,libasterisk.dll.a'

Then, add the following to all the modules LDFLAGS, specifying the
correct location: '-Wl,/path/to/libasterisk.dll.a'.

Of course, make sure that all requisite link libraries are specified in
LIBS for both the executable and the modules.

You'll still need to find some way of making all this dependent on
Cygwin in the Makefiles in order to make this portable.




I will try it this weekend, this is good to know.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-   -
- Jason Pyeron  PD Inc. http://www.pdinc.us -
- Partner & Sr. Manager 7 West 24th Street #100 -
- +1 (443) 921-0381 Baltimore, Maryland 21218   -
-   -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you 
have received it in error, purge the message from your system and 
notify the sender immediately.  Any other use of the email by you 
is prohibited.


--
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: making .so files...

[Yaakov S (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jason Pyeron wrote:
> I am working with the Asterisk application, it uses "modules" these are
> .so files which are linked against the main executable.
> 
> Asterisk will load a module, which may or may not make use of code
> exported by the main executable.

If I understand you correctly, then it's not so difficult; I've done it
myself with bmp, gedit, gthumb, liferea, and xmms.

I don't know Asterisk, but it doesn't appear to use autotools; this
makes things more difficult, especially if you want to make a portable
patch.

First, make sure that the asterisk executable is built *first*; you may
need to precede '.' to the SUBDIRS variable (i.e. SUBDIRS = . subdir1
subdir2 etc.)

Add the following to the asterisk executable's LDFLAGS:
'-Wl,--export-all-symbols,--out-implib,libasterisk.dll.a'

Then, add the following to all the modules LDFLAGS, specifying the
correct location: '-Wl,/path/to/libasterisk.dll.a'.

Of course, make sure that all requisite link libraries are specified in
LIBS for both the executable and the modules.

You'll still need to find some way of making all this dependent on
Cygwin in the Makefiles in order to make this portable.


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

iD8DBQFDWBmQpiWmPGlmQSMRAmL3AKDsK1MMNFSvPA4GLcvC5NJ0ZqOpAACg+uWe
lS4WeqeOxgs5yMCDG/r1Dms=
=ievK
-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: BASH version 3.00.16(11)-release (i686-pc-cygwin)

[Brian Dessent]

Christoph Jeksa wrote:

> the command-line completion doesn't work properly in a case-insensitive
> fashion regardless of the setting:
> 
> set completion-ignore-case On
> 
> in ~/.inputrc. That issue is every time reproducible on both 32 and
> 64-bit Windows systems.

You'll have to be more specific than it "doesn't work."  Tell us what
precisely you tried, what you expected, and what happened.  And attach
cygcheck output as directed in .

I have had that option in my ~/.inputrc literally for years and it has
always worked as expected.

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: Restart cygrunsrv service on failure

[René Berber]

Glen Burson wrote:
[snip]
> I'm having real trouble getting my service to restart on failure, using the
> Windows service "Recovery" options. I have set: -
> 
> First Failure "Restart the Service"
[snip]
> Windows logs in the Event Viewer that the service terminated (gracefully,
> error code 0) but doesn't restart it.
> 
> I have tried exiting from the script using a non-zero code (I've tried lots
> of different ones) but although the non-zero exit code is logged in the
> Event Viewer, it still doesn't restart it.
> 
> I've also tried the install option "-n" which tells Windows that the service
> should never terminate but, although I now get an error in the Event Viewer,
> it still doesn't restart it!
> 
> The ONLY way I've managed to get Windows to restart the service is to kill
> the cygrunsrv process before the child script terminates. Killing the child
> script does not work either.
> 
> It seems to be related to how the process terminates but I seem to crack it!
> 
> Thanks in advance for any suggestions. I've seen some postings that imply
> that people have this working but no examples.

I never tried exactly what you want, it looks like Windows doesn't cooperate so
its good to know not to waste time trying that.

One way I have a server set up is by installing a script (that watches the real
server) as the service, the interesing part of the script is this:

# Keep checking that it is working every TIME secs
trap '$DAEMON stop; exit' SIGTERM SIGQUIT SIGKILL
while true; do
  sleep $TIME
  $CLAMDWATCH -q -s $SOCKET &&
  ( $DAEMON stop
sleep 1
rm -f $SOCKET
$DAEMON start
  )
done

I know this is not what you asked, here I have a program that tests to see if
the daemon is not responding and the script restarts the daemon in that case.

Back to your test, I think you are using the wrong exit codes.  Windows does not
use the Unix like codes 0, 1, etc.   I don't remember Windows codes but they
where something like (exit_code << 8 | windows_flags) that means 256 instead of 
1.

HTH
-- 
René Berber


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

Re: sshd refuses ssh connections

[Eliah Kagan]

On 10/20/05, Albert Lunde <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 19, 2005 at 03:27:40PM -0700, Brian Dessent wrote:
> > > No, it's a red herring.  The host keys should be readable only by the
> > > process that runs sshd.  This must be SYSTEM in order for impersonation
> > > to work.  Thus they should be readable only by SYSTEM, and that is how
> > > ssh-host-config sets things up, correctly.  So if you try to run sshd as
> > > your normal user account, it will not work.  That's why it's a bad idea
> > > to mess around with running sshd from a regular prompt, because you will
> > > run into all kinds of permissions/ownership issues unless you know
> > > precisely what you're doing.
> >
> > The footnote to this is that if you obtain a shell as the SYSTEM user,
> > you can run sshd from a prompt in debugging mode without any issues.
> > There is a script somewhere in the mailing list archives, I think it's
> > called "sysbash", that achieves this.
>
> One can also do this with the commercial product "Firedaemon"
>
> http://www.firedaemon.com/
>
> which is a generic service control GUI.

Or with srvany.exe from Microsoft. See the Microsoft Knowledge Base
article "How To Create a User-Defined Service":

http://support.microsoft.com/default.aspx?scid=kb;en-us;137890

That article is written for NT and 2000, but if you're running XP or
Server 2003 it works just as well--just get srvany.exe and instsrv.exe
from the free Windows Server 2003 Resource Kit Tools:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd

(You may have to paste that link together.)

You could also use Sysinternals' psexec to execute an application as
SYSTEM on your own computer (if you have the File and Printer Sharing
service installed). This also works by installing a service that runs
the application.

http://www.sysinternals.com/Utilities/PsExec.html

-Eliah

--
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 - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Shankar Unni]

Christopher Faylor wrote:

On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote:



Supposed, you have a file X.sh ( exactly in this spelling ).  If you
enter:

vim x.sh ( also exactly in this spelling )

and write it back after any modification, the file will be renamed even
to x.sh.  



This isn't a vim problem.  Windows filename handling is case-insensitive.


But I think it's worth mentioning that 6.3 doesn't do this (change the 
case of the name when writing back). It overwrites the old file when 
writing back, thus preserving its case.


I'm guessing 6.4 has been fixed to move the old file out of the way 
before writing the new file, and you thus end up with the file name in 
the same case as the command line.


Anyway, the use case is illegitimate, so basically, there is no *bug* in 
Vim behaving either way - it's just undocumented behavior that has changed.


Don't mix cases like this ..

(P.S. The other way that certain other editors (e.g. Emacs) deal with 
this, is that they normalize the file name case when they load a file 
into a buffer, by getting the "real path name" of the file - that way, 
even if the rename the old file and create a new one, it'll be created 
in the right case.)



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

Bug in rxvt.bat (Was: rxvt malfunctioning with us-laptop keyboard)

[Rodrigo Medina]

Hi,
In a previous message I reported that rxvt was converting Shift-h to
Ctrl-h. It was not so. The problem is due to a bug in rxvt.bat and to
the peculiar way rxvt handles the BackSpace key.
In rxvt without options the BackSpace key yields "^?" and Crtl-BackSpace
yields "^H". In the shell `stty -a'  says `erase = ^?', BUT ALSO ^H erases.
Giving `stty sane' sets `erase = ^H', then only ^H erases (Crl-h or
Ctrl-BackSpace). If one sets `stty erase ^?', then only BackSpace, that
yields "^?", erases.
In rxvt.bat there is the option `-backspacekey ^H', but actually the
Windows cmd-shell filters the "^" symbol and one gets that the BackSpace key
and the Ctrl-BackSpace key actually yield "H", but rxvt also modifies stty,
so `stty -a' says `erase = H', but as in the original case also Ctrl-h
erases.
If one gives `stty sane' one sets `erase = ^H', one can verify that
Shift-h, BackSpace and Ctrl-Backspace yield "H". One may erase with Ctrl-H.

Solution: Put in rxvt.bat `-backspacekey "^H"'

Bye
R.M.


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

Restart cygrunsrv service on failure

[Glen Burson]

Hi everyone,

I posted this a few days ago with no responses. If anyone out there has
managed to get cygrunsrv to restart using the XP/2000 recovery I would be
really interested - I'm getting desperate! Details of my problem are
below...

cygrunsrv V1.10
Windows XP

I'm having real trouble getting my service to restart on failure, using the
Windows service "Recovery" options. I have set: -

First Failure "Restart the Service"
Second Failure "Restart the Service"
Subsequence Failures "Restart the Service"

I have installed my process like: -

cygrunsrv -I test -p /tmp/test.sh

"test.sh" just goes to sleep for 10 seconds then terminates.

Windows logs in the Event Viewer that the service terminated (gracefully,
error code 0) but doesn't restart it.

I have tried exiting from the script using a non-zero code (I've tried lots
of different ones) but although the non-zero exit code is logged in the
Event Viewer, it still doesn't restart it.

I've also tried the install option "-n" which tells Windows that the service
should never terminate but, although I now get an error in the Event Viewer,
it still doesn't restart it!

The ONLY way I've managed to get Windows to restart the service is to kill
the cygrunsrv process before the child script terminates. Killing the child
script does not work either.

It seems to be related to how the process terminates but I seem to crack it!

Thanks in advance for any suggestions. I've seen some postings that imply
that people have this working but no examples.

Thanks,
Glen.



**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**



This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.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: perl's exec fails with 20051019 snapshot in windows shell

[Krzysztof Duleba]

Krzysztof Duleba wrote:
> 
> After upgrading to 20051019, perl doesn't work as it used to in the
> windows shell.

20051020 looks better, thanks.

Krzysztof Duleba


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

RE: 1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Jason Fritz (CO/EWU)]

On Thu, 20 Oct 2005, Igor Pechtchanski wrote:
> 
> Hmm, very weird.  According to a couple of Google searches, the above
> looks like a message from UWin startup files -- Cygwin does 
> *not* have a
> profile.global, and the Cygwin bash won't look for anything in
> /usr/local/etc by default.  Do you, perhaps, have a c:\.bashrc or
> c:\.bash_profile or c:\.profile left over from a prior installation of
> UWin?

Aha!  Your response led me to the answer for this problem.  Within my company 
(Ericsson), we have our Unix home directories mounted as the H:\ drive on our 
PCs.  The H:\ dir just happens to contain a .profile, which just happens to 
execute /usr/local/etc/profile.global.  And, for whatever reason, when I start 
a DOS prompt, it defaults to the H:\ drive.  Also, after installing Cygwin, 
/etc/passwd sets my home dir to /cygdrive/h by default.

So, the answer to the problem is that Cygwin's bash was finding and executing 
.profile from an unrelated Unix environment.  I'm CCing Chloe, since I'm 
curious if they have a similar setup within Qualcomm.

> Just for reference, the way it *should* set $HOME is described in your
> /etc/passwd (if you don't have the latest, copy it from
> /etc/defaults/etc/passwd).
> 
> ...
> 
> Hmm, it would be interesting to see what "echo $HOME" says in a bash
> session that you start using "c:\cygwin\bin\bash --norc"...

Here's that output:
-
C:\cygwin\bin>bash --norc
bash-3.00$ echo $HOME
/cygdrive/h
-

Again, that shows the root of the problem.

In the end, I changed /etc/passwd to point to my My Documents dir instead of 
/cygdrive/h and now everything works fine.  Also, concerning the other post I 
sent about rxvt setting the font size/spacing to something funny, after 
changing /etc/passwd, rxvt acts fine as well.

> > Thank you for your help so far, Igor.
> 
> You're welcome -- it's a curious problem, and I'd like to get to the
> bottom of this.  Also, I don't think you've ever posted the output of
> "cygcheck -svr" on your system (in its non-working configuration), as
> requested in .  Please make sure you
> *attach* the output as an uncompressed text attachment, rather than
> include it inline.

Thanks again!  And just to nail the coffin shut on this, I've attached the 
output of cygcheck.
- Jason Fritz



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

Re: please test: coreutils-5.90-3

[Corinna Vinschen]

On Oct 20 06:17, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Corinna Vinschen on 10/19/2005 11:11 AM:
> >>utimes(dest,...);  // at this point, timestamp is correct
> >>fchmod(dest_desc,...);
> >>close(dest_desc);  // oops, timestamp changed
> > 
> > 
> > Apparently NT overwrites the mtime timestamp on close, as long as write
> > buffers are not written to disk at that time.  Chris had an idea how to
> > work around that in Cygwin so that it should work in most cases now.
> > Please try the latest snapshot from http://cygwin.com/snapshots/
> 
> Slick trick of searching for an open write descriptor visiting the same
> file.  But it begs the question - why not go one step further and
> create/export futimes(), so that the application can inform cygwin which
> descriptor to use, bypassing the search?

I've implemented futimes and lutimes today.  For testing futimes I
recompiled coreutils 5.90 which happily jumped to use futimes now.
Give it a try.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
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: 1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Jason Fritz (CO/EWU)]

> On Thu, 20 Oct 2005, Jason Fritz wrote:
> 
> I don't know much about the implementation of Cygwin bash, 
> but perhaps it has a bug and it's not setting HOME like it 
> should?  I think from the info I posted above that it's 
> clearly not working as intended.

Some more (possibly) interesting information:
I installed rxvt, and running rxvt -without- setting HOME does the right thing. 
 That is, it starts up a console window and bash runs without any errors.

On the other hand, I'm exaggerating by saying it "does the right thing."  If 
HOME isn't set, rxvt sets the font size and spacing to something very big, and 
the text onscreen looks ridiculous.  If HOME -is- set, on the other hand, 
rxvt's font size/spacing looks neat and small.  I wish I could provide details 
on what the font size actually is in both cases, but I don't know how to find 
that info.

Let me try to illustrate w/i the confines of ASCII :)
I f   H O M E   i s   n o t   s e t ,   i t   l o o k s   l i k e   t h i s 
If HOME is set, it looks normal

Anyway, I'm a relative Cygwin newbie, but it seems to me that Cygwin tools 
might not behave nicely without manually setting HOME and PATH.

Take care and thanks for your help,
Jason

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

RE: 1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Igor Pechtchanski]

On Thu, 20 Oct 2005, Jason Fritz (CO/EWU) wrote:

> > On Thu, 20 Oct 2005, Igor Pechtchanski wrote:
> >
> > Yes, but that doesn't guarantee that you would *run* that version.
> > Again, the Cygwin version of bash will *not* look for
> > /usr/local/etc/profile.global -- that message comes from some other
> > bash. The analysis is correct, AFAICS.
> >
> > One thing to try is to change the last line of your cygwin.bat to
> >
> > c:\cygwin\bin\bash --login -i
> >
> > and see if that solves your problem (with the original config)...
>
> I did as you suggested and the problem still happens.  I backed out my
> environment variables changes (to HOME and PATH), and ran cygwin.bat
> as-is and reverified that the problem happened again.  Then I edited
> cygwin.bat as you suggested and reran the script with the same result.
> Here's the shell output for reference:
> -
> C:\cygwin>type cygwin.bat
> @echo off
>
> C:
> chdir C:\cygwin\bin
>
> C:\cygwin\bin\bash --login -i
>
> C:\cygwin>cygwin.bat

> /usr/bin/bash: can't find configuration file /usr/local/etc/profile.global; 
> exiting.
> -

Hmm, very weird.  According to a couple of Google searches, the above
looks like a message from UWin startup files -- Cygwin does *not* have a
profile.global, and the Cygwin bash won't look for anything in
/usr/local/etc by default.  Do you, perhaps, have a c:\.bashrc or
c:\.bash_profile or c:\.profile left over from a prior installation of
UWin?

> As a side note, I've never installed bash in another form on my PC and
> running "bash" from C:\ in a DOS prompt does not work.
>
> > > After contacting Chloe directly,
> >
> > Ugh.  She was way too polite.  Unsolicited private emails to
> > random list
> > posters are highly discouraged -- the Cygwin mailing list is
> > the place to
> > ask for help.
>
> Well, with all due respect, I can see that contacting Cygwin maintainers
> and developers is a Bad Thing (tm), but contacting ordinary users is no
> mortal sin.  I was polite to her and she was polite in return.  I
> followed up by posting to the mailing list so the info would not be
> lost.

Fair enough.  But sending email directly to the list lets you skip a step
in the above process...

> > I suspect you're still not running the official Cygwin bash -- it
> > should set HOME automatically.  As I said above, try forcing the
> > Cygwin bash by specifying the path to it explicitly.
>
> I don't know much about the implementation of Cygwin bash, but perhaps
> it has a bug and it's not setting HOME like it should?

Just for reference, the way it *should* set $HOME is described in your
/etc/passwd (if you don't have the latest, copy it from
/etc/defaults/etc/passwd).

> I think from the info I posted above that it's clearly not working as
> intended.

Hmm, it would be interesting to see what "echo $HOME" says in a bash
session that you start using "c:\cygwin\bin\bash --norc"...

> Thank you for your help so far, Igor.

You're welcome -- it's a curious problem, and I'd like to get to the
bottom of this.  Also, I don't think you've ever posted the output of
"cygcheck -svr" on your system (in its non-working configuration), as
requested in .  Please make sure you
*attach* the output as an uncompressed text attachment, rather than
include it inline.
HTH,
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!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

RE: 1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Jason Fritz (CO/EWU)]

> On Thu, 20 Oct 2005, Igor Pechtchanski wrote:
> 
> Yes, but that doesn't guarantee that you would *run* that 
> version.  Again,
> the Cygwin version of bash will *not* look for
> /usr/local/etc/profile.global -- that message comes from some 
> other bash.
> The analysis is correct, AFAICS.
> 
> One thing to try is to change the last line of your cygwin.bat to
> 
> c:\cygwin\bin\bash --login -i
> 
> and see if that solves your problem (with the original config)...

I did as you suggested and the problem still happens.  I backed out my 
environment variables changes (to HOME and PATH), and ran cygwin.bat as-is and 
reverified that the problem happened again.  Then I edited cygwin.bat as you 
suggested and reran the script with the same result.  Here's the shell output 
for reference:
-
C:\cygwin>type cygwin.bat
@echo off

C:
chdir C:\cygwin\bin

C:\cygwin\bin\bash --login -i

C:\cygwin>cygwin.bat
/usr/bin/bash: can't find configuration file /usr/local/etc/profile.global; 
exiting.
-

As a side note, I've never installed bash in another form on my PC and running 
"bash" from C:\ in a DOS prompt does not work.

> > After contacting Chloe directly,
> 
> Ugh.  She was way too polite.  Unsolicited private emails to 
> random list
> posters are highly discouraged -- the Cygwin mailing list is 
> the place to
> ask for help.

Well, with all due respect, I can see that contacting Cygwin maintainers and 
developers is a Bad Thing (tm), but contacting ordinary users is no mortal sin. 
 I was polite to her and she was polite in return.  I followed up by posting to 
the mailing list so the info would not be lost.

> I suspect you're still not running the official Cygwin bash 
> -- it should
> set HOME automatically.  As I said above, try forcing the 
> Cygwin bash by
> specifying the path to it explicitly.

I don't know much about the implementation of Cygwin bash, but perhaps it has a 
bug and it's not setting HOME like it should?  I think from the info I posted 
above that it's clearly not working as intended.

Thank you for your help so far, Igor.
- Jason Fritz

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

Re: 1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Igor Pechtchanski]

On Thu, 20 Oct 2005, Jason Fritz (CO/EWU) wrote:

> Hi all,
>
> I began typing this mail as a problem report, but thanks to a gracious
> reply from Chloe Chang, it turned out that I had not yet set my HOME
> environment variable to complete the installation.  I'll describe the
> problem anyway to help steer future Cygwin-er's clear of this issue.
>
> I had just installed Cygwin 1.5.18-1 plus default base packages for the
> first time on my Windows 2000 laptop.  After installation, running
> cygwin.bat (or the Cygwin shortcut on the desktop) gave the following
> error:
> C:\cygwin>cygwin.bat
> bash: can't find configuration file /usr/local/etc/profile.global; exiting.
>
> Searching the Cygwin mail archive, I found that Chloe had seen this
> problem back in June 2005.  See:
> http://www.cygwin.com/ml/cygwin/2005-06/msg00759.html
>
> There was a reply from Igor Pechtchanski that said she was "not running
> the Cygwin version of bash".  I believe this analysis was wrong,
> however, since the bash package was installed by Cygwin's setup.exe,
> which presumably should only download a Cygwin version of bash.

Yes, but that doesn't guarantee that you would *run* that version.  Again,
the Cygwin version of bash will *not* look for
/usr/local/etc/profile.global -- that message comes from some other bash.
The analysis is correct, AFAICS.

One thing to try is to change the last line of your cygwin.bat to

c:\cygwin\bin\bash --login -i

and see if that solves your problem (with the original config)...

> After contacting Chloe directly,

Ugh.  She was way too polite.  Unsolicited private emails to random list
posters are highly discouraged -- the Cygwin mailing list is the place to
ask for help.

> she pointed me to the environment variable webpage for Cygwin:
> http://www.cygwin.com/cygwin-ug-net/setup-env.html
>
> It turns out that I needed to set my HOME environment variable to
> something.  I set it to my My Documents directory:
> set HOME=C:\Documents and Settings\ewujafr\My Documents
>
> After that, cygwin.bat worked fine.  Note that a more permanent way to
> set HOME is via Control Panel->System then Advanced tab->Environment
> Variables.

I suspect you're still not running the official Cygwin bash -- it should
set HOME automatically.  As I said above, try forcing the Cygwin bash by
specifying the path to it explicitly.

> *** plea for change ***
> I think the main page for Cygwin, http://cygwin.com/, is misleading
> because it leads new users to believe that running setup.exe is all that
> you need to do.  There's no link to the setup instructions:
> http://www.cygwin.com/cygwin-ug-net/setup-net.html.

This probably makes sense (though I believe setup itself should also have
a link to that page in the start pane).

> Can someone update the main page?  Better yet, setup.exe could set the
> HOME variable for the user, perhaps by adding an extra page to the setup
> wizard.

No.  Setup has no business mucking with the environment.  The HOME
variable should already be set automatically by the Cygwin version of
bash.
HTH,
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!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

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

1.5.18-1: cygwin.bat/bash fails after installing Cygwin

[Jason Fritz (CO/EWU)]

Hi all,

I began typing this mail as a problem report, but thanks to a gracious reply 
from Chloe Chang, it turned out that I had not yet set my HOME environment 
variable to complete the installation.  I'll describe the problem anyway to 
help steer future Cygwin-er's clear of this issue.

I had just installed Cygwin 1.5.18-1 plus default base packages for the first 
time on my Windows 2000 laptop.  After installation, running cygwin.bat (or the 
Cygwin shortcut on the desktop) gave the following error:
C:\cygwin>cygwin.bat
bash: can't find configuration file /usr/local/etc/profile.global; exiting.

Searching the Cygwin mail archive, I found that Chloe had seen this problem 
back in June 2005.  See:
http://www.cygwin.com/ml/cygwin/2005-06/msg00759.html

There was a reply from Igor Pechtchanski that said she was "not running the 
Cygwin version of bash".  I believe this analysis was wrong, however, since the 
bash package was installed by Cygwin's setup.exe, which presumably should only 
download a Cygwin version of bash.

After contacting Chloe directly, she pointed me to the environment variable 
webpage for Cygwin: http://www.cygwin.com/cygwin-ug-net/setup-env.html

It turns out that I needed to set my HOME environment variable to something.  I 
set it to my My Documents directory:
set HOME=C:\Documents and Settings\ewujafr\My Documents

After that, cygwin.bat worked fine.  Note that a more permanent way to set HOME 
is via Control Panel->System then Advanced tab->Environment Variables.

*** plea for change ***
I think the main page for Cygwin, http://cygwin.com/, is misleading because it 
leads new users to believe that running setup.exe is all that you need to do.  
There's no link to the setup instructions: 
http://www.cygwin.com/cygwin-ug-net/setup-net.html.  Can someone update the 
main page?  Better yet, setup.exe could set the HOME variable for the user, 
perhaps by adding an extra page to the setup wizard.

Sorry for the long-winded post.
Jason Fritz



--
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 - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Christopher Faylor]

On Thu, Oct 20, 2005 at 12:26:58PM -0400, Igor Pechtchanski wrote:
>On Thu, 20 Oct 2005, Christopher Faylor wrote:
>>On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote:
>>>there is a bug in this version:
>>>
>>>Supposed, you have a file X.sh ( exactly in this spelling ).  If you
>>>enter:
>>>
>>>vim x.sh ( also exactly in this spelling )
>>>
>>>and write it back after any modification, the file will be renamed even
>>>to x.sh.  This behavior is very nasty if such file is used by programs
>>>which are case-sensitive for file names, example: SCM program perforce.
>>
>>This isn't a vim problem.  Windows filename handling is
>>case-insensitive.
>>
>>I suppose that there could be a vim option to deal with this case but
>>that would require modifying vim, i.e., PTC* by the upstream vim
>>developers.
>
>Chris, I suppose there's another bet between you and Corinna floaing
>around in the cygwin-developers land somewhere, but I'll bite.

What's the euro/dollar exchange rate these days?

>No need to patch vim.  This is *exactly* the kind of situation where
>check_case:strict is useful.  With CYGWIN=check_case:strict, vim won't
>even edit the file "x.sh" if the file is actually named "X.sh".
>Incidentally, "check_case:adjust" might also help.

You're right, I didn't consider recommending an option that Corinna and
I consider to be deprecated.  Using this option is *guaranteed* to slow
Cygwin down and, given that both Corinna and I detest the complications
and slow down this option entails, it is entirely possible that it will
be broken from time to time.

At the risk of being self-indulgent and winning some more bets, I also
didn't mention the overkill option of using managed mounts.

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: VIM - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Igor Pechtchanski]

On Thu, 20 Oct 2005, Christopher Faylor wrote:

> On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote:
> >there is a bug in this version:
> >
> >Supposed, you have a file X.sh ( exactly in this spelling ).  If you
> >enter:
> >
> >vim x.sh ( also exactly in this spelling )
> >
> >and write it back after any modification, the file will be renamed even
> >to x.sh.  This behavior is very nasty if such file is used by programs
> >which are case-sensitive for file names, example: SCM program perforce.
>
> This isn't a vim problem.  Windows filename handling is case-insensitive.
>
> I suppose that there could be a vim option to deal with this case but
> that would require modifying vim, i.e., PTC* by the upstream vim
> developers.

Chris, I suppose there's another bet between you and Corinna floaing
around in the cygwin-developers land somewhere, but I'll bite.

No need to patch vim.  This is *exactly* the kind of situation where
check_case:strict is useful.  With CYGWIN=check_case:strict, vim won't
even edit the file "x.sh" if the file is actually named "X.sh".
Incidentally, "check_case:adjust" might also help.
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!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
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: sshd refuses ssh connections

[Albert Lunde]

On Wed, Oct 19, 2005 at 03:27:40PM -0700, Brian Dessent wrote:
> Brian Dessent wrote:
> 
> > No, it's a red herring.  The host keys should be readable only by the
> > process that runs sshd.  This must be SYSTEM in order for impersonation
> > to work.  Thus they should be readable only by SYSTEM, and that is how
> > ssh-host-config sets things up, correctly.  So if you try to run sshd as
> > your normal user account, it will not work.  That's why it's a bad idea
> > to mess around with running sshd from a regular prompt, because you will
> > run into all kinds of permissions/ownership issues unless you know
> > precisely what you're doing.
> 
> The footnote to this is that if you obtain a shell as the SYSTEM user,
> you can run sshd from a prompt in debugging mode without any issues. 
> There is a script somewhere in the mailing list archives, I think it's
> called "sysbash", that achieves this.

One can also do this with the commercial product "Firedaemon"

http://www.firedaemon.com/

which is a generic service control GUI.

-- 
Albert Lunde 

--
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 - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Christopher Faylor]

On Thu, Oct 20, 2005 at 04:15:34PM +0200, Christoph Jeksa wrote:
>there is a bug in this version:
>
>Supposed, you have a file X.sh ( exactly in this spelling ).  If you
>enter:
>
>vim x.sh ( also exactly in this spelling )
>
>and write it back after any modification, the file will be renamed even
>to x.sh.  This behavior is very nasty if such file is used by programs
>which are case-sensitive for file names, example: SCM program perforce.

This isn't a vim problem.  Windows filename handling is case-insensitive.

I suppose that there could be a vim option to deal with this case but
that would require modifying vim, i.e., PTC* by the upstream vim
developers.

cgf

* http://cygwin.com/acronyms/#PTC

--
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 - Vi IMproved 6.4 (2005 Oct 15, compiled Oct 17 2005 11:54:34

[Christoph Jeksa]

Hi all,

there is a bug in this version:

Supposed, you have a file X.sh ( exactly in this spelling ).
If you enter:

vim x.sh ( also exactly in this spelling ) 

and write it back after any modification, the file will be 
renamed even to x.sh. This behavior is very nasty if such
file is used by programs which are case-sensitive for file
names, example: SCM program perforce.  

Thanks,
--
Christoph Jeksa, CoCreate Software GmbH & Co. KG
Posener Str. 1, D-71065 Sindelfingen, Germany
E-Mail: [EMAIL PROTECTED]
Phone:  ( +49 7031 ) 951-2149
Fax:( +49 7031 ) 951-2320

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

BASH version 3.00.16(11)-release (i686-pc-cygwin)

[Christoph Jeksa]

Hi all,

the command-line completion doesn't work properly in a case-insensitive 
fashion regardless of the setting:

set completion-ignore-case On

in ~/.inputrc. That issue is every time reproducible on both 32 and 
64-bit Windows systems.

Is there something to work around that?

Regards,
--
Christoph Jeksa, CoCreate Software GmbH & Co. KG
Posener Str. 1, D-71065 Sindelfingen, Germany
E-Mail: [EMAIL PROTECTED]
Phone:  ( +49 7031 ) 951-2149
Fax:( +49 7031 ) 951-2320

--
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 g++ on cygwin

[community help]

Hi,

I'm sorry. After your answer i realised that my
message should be posted on a c/c++ mailing list not
in this one.

Sorry again

--- Eric Blake <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to community help on 10/20/2005 7:06 AM:
> > Hi,
> > 
> > I'm using g++ on cygwin for developping some c++
> > programs.
> > 
> > I noticed that everytime i manipulate pointers i
> have
> > an error saying:
> > "Segmentation Fault ".
> 
> Well, it's because you are trying to modify
> read-only memory.  Fix the bug
> in your code.  Your problem is not cygwin-specific,
> although cygwin is a
> little less forgiving of memory usage errors, and
> more likely to core dump
> when your code is buggy.
> 
> > --
> > #include 
> > #include 
> > 
> > int main()
> > {
> > char * str;
> > str = "hello";
> 
> The type of "hello" is const char*, because it lives
> in read-only memory.
>  You are (silently) casting away the const, and that
> is your bug; compile
> with -Wall and you should be getting a warning.
> 
> > *(str+1) = 'a';
> 
> Oops - now you are trying to change a read-only
> location.
> 
> Now, had you declared this instead:
> char str[] = "hello";
> 
> Then *(str+1) = 'a' is legal, because C++ allows a
> char[] initializer to
> copy the contents of a string literal, without
> putting it in read-only memory.
> 
> - --
> Life is short - so eat dessert first!
> 
> Eric Blake [EMAIL PROTECTED]
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (Cygwin)
> Comment: Public key at
> home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Thunderbird -
> http://enigmail.mozdev.org
> 
>
iD8DBQFDV5vv84KuGfSFAYARAg+yAJwIbqTkFDH5j9+a3Mmn2ON7KL8rwgCfTALA
> v2bKNT8djHRvcVBHSSuFQ7g=
> =/+gu
> -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/
> 
> 




__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

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

Re: please test: coreutils-5.90-3

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>
> It's not POSIX!
>
> But I must admit that it exists on Linux, even though they didn't bother
> to create a man page for it.


> Corinna, I think I win the bet, right?
> 

Ooh, having fun on the closed -developers list at my expense, are we? ;)
At least MacOS X and FreeBSD man pages mention futimes, per a quick google
search.  And I've never argued that cygwin can't go beyond POSIX,
especially not where precedence exists.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDV51U84KuGfSFAYARAg7EAKC8/MqC5hS0ZNk2uGEQ3pDwNIMyQwCfdbLp
oSJ0RIbnmbu9WWSRvG11m4s=
=JQOk
-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: problem with g++ on cygwin

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to community help on 10/20/2005 7:06 AM:
> Hi,
> 
> I'm using g++ on cygwin for developping some c++
> programs.
> 
> I noticed that everytime i manipulate pointers i have
> an error saying:
> "Segmentation Fault ".

Well, it's because you are trying to modify read-only memory.  Fix the bug
in your code.  Your problem is not cygwin-specific, although cygwin is a
little less forgiving of memory usage errors, and more likely to core dump
when your code is buggy.

> --
> #include 
> #include 
> 
> int main()
> {
>   char * str;
>   str = "hello";

The type of "hello" is const char*, because it lives in read-only memory.
 You are (silently) casting away the const, and that is your bug; compile
with -Wall and you should be getting a warning.

>   *(str+1) = 'a';

Oops - now you are trying to change a read-only location.

Now, had you declared this instead:
char str[] = "hello";

Then *(str+1) = 'a' is legal, because C++ allows a char[] initializer to
copy the contents of a string literal, without putting it in read-only memory.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDV5vv84KuGfSFAYARAg+yAJwIbqTkFDH5j9+a3Mmn2ON7KL8rwgCfTALA
v2bKNT8djHRvcVBHSSuFQ7g=
=/+gu
-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: please test: coreutils-5.90-3

[Christopher Faylor]

On Thu, Oct 20, 2005 at 06:17:17AM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Corinna Vinschen on 10/19/2005 11:11 AM:
>>>utimes(dest,...);  // at this point, timestamp is correct
>>>fchmod(dest_desc,...);
>>>close(dest_desc);  // oops, timestamp changed
>> 
>> 
>> Apparently NT overwrites the mtime timestamp on close, as long as write
>> buffers are not written to disk at that time.  Chris had an idea how to
>> work around that in Cygwin so that it should work in most cases now.
>> Please try the latest snapshot from http://cygwin.com/snapshots/
>
>Slick trick of searching for an open write descriptor visiting the same
>file.  But it begs the question - why not go one step further and
>create/export futimes(), so that the application can inform cygwin which
>descriptor to use, bypassing the search?

Corinna, I think I win the bet, right?

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: Hang with 20051018 (3rd version) snapshot while building OOo

[Christopher Faylor]

On Thu, Oct 20, 2005 at 08:48:05AM -0400, Volker Quetschke wrote:
>Volker Quetschke wrote:
>>Christopher Faylor wrote:
>>>On Wed, Oct 19, 2005 at 03:45:30PM -0400, Volker Quetschke wrote:
>>>(snip)
>>>Given the number of changes that have been made to cygwin, particularly
>>>in /proc handling, it's very difficult for me to believe that you are
>>>not seeing *any* differences in behavior and
>Well, there are differences in the frequency of occurrence of the hangs.
>
>>>I'm wondering if you're
>>>actually seeing what you think you're seeing, i.e., I'm wondering if the
>>>process is just timing out and you are attributing it coming "unstuck"
>>>to the fact that you're doing "ls /proc/*/fd".  I can't see any reason
>>>why inspecting /proc should cause any kind of special behavior in the
>>>latest snapshots since /proc handling now occurs in its own thread.
>>
>>I can completely understand your worries. My problem is that I cannot
>>reproduce the problem myself and all I can do is ask the people who
>>have this problem to try get some debug information.
>>
>>I just asked for a confirmation that it really is the "ls /proc/*/fd"
>>that "unstucks" the process. I don't believe that "/usr/bin/tcsh -fc pwd"
>>needs a long time to finish so that we're getting a coincidence there.
>I got some information back:
>It is done like this, the build is running/hanging in one shell (1).
>
>When it hangs, start a new tcsh shell (2) and get the ps and cygcheck
>information. Then open a new bash (3) and start "strace -p "
>Now in (2) start
>   while 1
>   ls /proc//fd
>   end
>until the strace is ready.

I wonder what would happen if the strace was just allowed to sit.  I
don't see anything in the strace would indicate that the process is
stalled and that looking at /proc/...  is fixing it.

>He wrote that 20051019 also produced a hang and that I'll get the next ;)
>strace.

I wouldn't expect 20051019 to be any different.

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: please test: coreutils-5.90-3

[Corinna Vinschen]

On Oct 20 06:17, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> According to Corinna Vinschen on 10/19/2005 11:11 AM:
> >>utimes(dest,...);  // at this point, timestamp is correct
> >>fchmod(dest_desc,...);
> >>close(dest_desc);  // oops, timestamp changed
> > 
> > 
> > Apparently NT overwrites the mtime timestamp on close, as long as write
> > buffers are not written to disk at that time.  Chris had an idea how to
> > work around that in Cygwin so that it should work in most cases now.
> > Please try the latest snapshot from http://cygwin.com/snapshots/
> 
> Slick trick of searching for an open write descriptor visiting the same
> file.  But it begs the question - why not go one step further and
> create/export futimes(), so that the application can inform cygwin which
> descriptor to use, bypassing the search?

It's not POSIX!

But I must admit that it exists on Linux, even though they didn't bother
to create a man page for it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
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/

problem with g++ on cygwin

[community help]

Hi,

I'm using g++ on cygwin for developping some c++
programs.

I noticed that everytime i manipulate pointers i have
an error saying:
"Segmentation Fault ".

An other file is added to the working directory. If i
compile with the following:
g++ -o file_name file_name.cc
i have a file_name.exe but also a
file_name.exe.stackdump.

i wrote a very simple example for testing:
--
#include 
#include 

int main()
{
char * str;
str = "hello";
*(str+1) = 'a';
return 0;
}
-
This simple example also gave me the same error.

I hope somebody can help me with this.

Thank you



__ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

--
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: Hang with 20051018 (3rd version) snapshot while building OOo

[Volker Quetschke]

Volker Quetschke wrote:

Christopher Faylor wrote:

On Wed, Oct 19, 2005 at 03:45:30PM -0400, Volker Quetschke wrote:
(snip)
Given the number of changes that have been made to cygwin, particularly
in /proc handling, it's very difficult for me to believe that you are
not seeing *any* differences in behavior and

Well, there are differences in the frequency of occurrence of the hangs.


I'm wondering if you're
actually seeing what you think you're seeing, i.e., I'm wondering if the
process is just timing out and you are attributing it coming "unstuck"
to the fact that you're doing "ls /proc/*/fd".  I can't see any reason
why inspecting /proc should cause any kind of special behavior in the
latest snapshots since /proc handling now occurs in its own thread.


I can completely understand your worries. My problem is that I cannot
reproduce the problem myself and all I can do is ask the people who
have this problem to try get some debug information.

I just asked for a confirmation that it really is the "ls /proc/*/fd"
that "unstucks" the process. I don't believe that "/usr/bin/tcsh -fc pwd"
needs a long time to finish so that we're getting a coincidence there.

I got some information back:
It is done like this, the build is running/hanging in one shell (1).

When it hangs, start a new tcsh shell (2) and get the ps and cygcheck
information. Then open a new bash (3) and start "strace -p "
Now in (2) start
while 1
ls /proc//fd
end
until the strace is ready.

Some details: The build is running on a local NTFS drive. It's a dedicated
machine, not much is running beside the build.

He wrote that 20051019 also produced a hang and that I'll get the next ;)
strace.

Clueless

 Volker



Having said that, I never realized that before, maybe the problem really
lies in this special command. I mean due to some historic quirks every
makefile in the OOo tree has a line that sets a macro to the current path
using that command, but there are still lots of other commands (also executed
in a tcsh shell) in these makefiles that I never heard of to hang.
(I'll also verify that what I just said is really true, it's just an idea.)



I could almost convince myself that there was a race in /proc handling
before but I could never convince myself that doing something like "ls 
/proc/*/fd"
would have any effect on it.  Nevertheless, I did make some changes to
eliminate the potential source of hangs in this code.  So, I can't
understand why you wouldn't see something different.



I have no clue either, especially as I also cannot reproduce and therefore
cannot pinpoint the problem. :(

Anyway, thanks for all your efforts!

   Volker




--
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


signature.asc
Description: OpenPGP digital signature

Re: info bash - Bash Features: No such file or directory

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lennart Borgman on 10/19/2005 4:40 PM:
> If I do
> 
>  info bash
> 
> from the bash prompt and try to open "*Bash Features::" I get the error
> message in the subject line.
> 
> Is this expected or a known bug?

It works for me.  You'll have to help by giving me a better formula for
reproducing the problem.  What does "info -w bash" print?  Also, could you
please follow the problem-reporting directions below, and attach cygcheck.out?

> Problem reports:   http://cygwin.com/problems.html

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
volunteer cygwin bash maintainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDV43384KuGfSFAYARAguMAJ9EwLBLmPqgSaGanJZFyryg397+CACfRoyM
AKivvMFOdPIHVATI78hjLMg=
=iRML
-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: please test: coreutils-5.90-3

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Corinna Vinschen on 10/19/2005 11:11 AM:
>>utimes(dest,...);  // at this point, timestamp is correct
>>fchmod(dest_desc,...);
>>close(dest_desc);  // oops, timestamp changed
> 
> 
> Apparently NT overwrites the mtime timestamp on close, as long as write
> buffers are not written to disk at that time.  Chris had an idea how to
> work around that in Cygwin so that it should work in most cases now.
> Please try the latest snapshot from http://cygwin.com/snapshots/

Slick trick of searching for an open write descriptor visiting the same
file.  But it begs the question - why not go one step further and
create/export futimes(), so that the application can inform cygwin which
descriptor to use, bypassing the search?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDV4rN84KuGfSFAYARAoLKAJ46dvlPPUImPM544Eu0Ym7lJ2yTWQCgy1t5
X5nNwEDWFp529YvxecUSgA0=
=WYeh
-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: exiting vim changes background colour of console

[Brian Dessent]

Lennart Borgman wrote:

> Thanks very much this! However I still have problem with long commands.
> I start Cygwin with
> 
>  ** cygwin.cmd:
> @echo off
> set chere_invoking=1
> D:\cygwin\bin\bash --login -i
> 
> When the command wraps into the next line then I can not edit the
> command any more. Is there something I can do about this?

Can you elaborate on what you mean by "can not edit the command any
more"?  The expected behavior is that it should spill (wrap) onto the
next line, but you should still be able to use backspace/arrow keys/etc
to manipulate the command.  I tried the above setting of PS1 and it
worked fine.

If you'd rather that the line scroll and not wrap, you can add the
following to your ~/.inputrc:

set horizontal-scroll-mode On

If you still have problems with editing a command that exceeds the
screen width, then it sounds like bash is not aware of the correct
screen width for some reason.  We'd probably need more information about
your setup in order to figure it out, such as cygcheck -svr output.  Are
you using the current version of bash?  Are you using CMD.EXE or rxvt or
something else?   What's the value of $TERM?  Does it work correctly if
you resize the console after it's been started (by dragging the edges
with the mouse)?  Do you have anything nonstandard in your startup
files?

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: exiting vim changes background colour of console

[Lennart Borgman]

Brian Dessent wrote:


Lennart Borgman wrote:

 


I do not remember anything about this now, but comparing to my current
PS1 I can see that I has a \] after the last m. I have

   PS1=\[\033[32;47m\w >\033[0m\]
   



That's incorrect.  The \[ and \] are to be used only to delineate
nonprinting sequences.  If you include "\w >" inside them you will
really muck up your prompt if you type a command wider than one screen.

PS1="\[\033[32;47m\]\w >\[\033[0m\]"

Brian
 

Thanks very much this! However I still have problem with long commands. 
I start Cygwin with


** cygwin.cmd:
   @echo off
   set chere_invoking=1
   D:\cygwin\bin\bash --login -i

When the command wraps into the next line then I can not edit the 
command any more. Is there something I can do about this?


Kind regards,
Lennart

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