Re: How does one change the default shell?

[Andy Koppe]

On 2 September 2010 23:49, RISINGP1 wrote:
> My cygwin.bat:
>
> @echo off
>
> C:
> chdir C:\cygwin\bin
>
> REM bash --login -i
> REM pdksh -l -i
> start mintty -p 70,0 -t Console -e -

Btw, you don't need cygwin.bat to start mintty; you can just put those
parameters into a shortcut (or copy the one in the start menu and edit
it):

Target: C:\cygwin\bin\mintty -p 70,0 -t Console -

That avoids a console window flashing up when starting it.

Andy

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

Re: The un-notified update of gcc4-4.3.4-3 cause setup failed(build date 2009-12-11 to 2010-08-15, caused file size mismatch)

[LiuYan 刘研]

Thank you Davek. Sorry for my poor English and poor expression.

You're right, I'm installing cygwin to a new server from local package cache
on my PC via net share.

It's ok to avoid redownload existing files. Maybe it's better to shown the
'file size mismatch' message or other error messages (which occured in
command line setup mode) too in GUI setup mode. Or, it will take more time
to find out the error. ^_^


Dave Korn-9 wrote:
> 
> On 02/09/2010 05:32, LiuYan 刘研 wrote:
>> Today I try to setup cygwin on a new server, it keeps failed with a
>> "cyggcc_s-1.dll is missed" error in the last post-install phase.
> 
>   I'm sorry it caused you a problem, I'm afraid setup.exe was smarter than
> I
> am and it spotted the difference when I hoped it wouldn't.  I thought that
> it
> would be ok, since cyggcc_s-1.dll would already be installed, so it
> shouldn't
> have been looking to upgrade anything.
> 
>   Are you perhaps sharing a local package cache dir between both these
> machines, on a network shared drive or similar?
> 
>> I rename gcc4 directory to gcc4-old, reinstall gcc4 and libgcc1 package,
>> it
>> works ok finally.
> 
>   Right, that workaround should suffice.  I wanted to avoid everyone who
> already had the package installed from having to redownload it because the
> only thing that changed was a couple of 'x' permission bits on a couple of
> the
> scripts.
> 
> 
> cheers,
>   DaveK
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/The-un-notified-update-of-gcc4-4.3.4-3-cause-setup-failed%28build-date-2009-12-11-to-2010-08-15%2C-caused-file-size-mismatch%29-tp29600561p29610882.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: 1.7.[67]: getting bash prompt takes > 50 seconds

[Reid Thompson]

On 9/2/2010 11:03 PM, Reid Thompson wrote:

On 9/1/2010 8:35 AM, Andrey Repin wrote:
+>

Did you tried to *uninstall* bash-completion?


What changed such that bash-completion, which previously worked fine, no longer 
does?


The biggest change i've seen is in the slowdown of
./configure
and
make

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

Re: 1.7.[67]: getting bash prompt takes > 50 seconds

[Larry Hall (Cygwin)]

On 9/2/2010 11:03 PM, Reid Thompson wrote:

On 9/1/2010 8:35 AM, Andrey Repin wrote:
+>

Did you tried to *uninstall* bash-completion?


What changed such that bash-completion, which previously worked fine, no
longer does?


Upstream changes.  They're working on fixes.  See recent email archives
if you're interested in some details.

--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
216 Dalton Rd. (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: 1.7.[67]: getting bash prompt takes > 50 seconds

[Reid Thompson]

On 9/1/2010 8:35 AM, Andrey Repin wrote:
+>

Did you tried to *uninstall* bash-completion?


What changed such that bash-completion, which previously worked fine, no longer 
does?


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

Re: export DISPLAY={localWorkstationIP} in mintty

[Andrew DeFaria]

 On 09/02/2010 03:37 PM, Jeremy Bopp wrote:

On 9/2/2010 5:12 PM, PaulHR wrote:

I got the standard error.
Error: Can't open display:

I made sure xWin Server was running
Did a -vvv on the ssh and saw nothing for X11

What else can I look at?

It would be really helpful if you included a little context from earlier
bits of the conversation to which you are responding.  I'm going to
assume that you responded to my message suggesting you use the -X option
to ssh. ;-)

It's possible that the corresponding server-side option to allow that
feature is disabled.  If so, you could try to reconfigure the ssh
server.  The option to enable is named X11Forwarding and it should be
set to "yes".  If you are not allowed to do that, then your only option
is to go back to your original idea of figuring out your local IP.  This
will require a bit more effort on your part.

When you connect to the remote machine, there should be an environment
variable named SSH_CLIENT set.  It appears to be a space delimited list
where the first item is your client's IP address.  Given that and
assuming your shell is bash on the server, you can use the following to
set the DISPLAY environment variable after you open your connection:

export DISPLAY=$(echo $SSH_CLIENT | cut -d' ' -f1):0

If that works for you, you may want to put it in your .bashrc or
.bash_profile script on the server side so that it happens automatically
every time you connect.

-Jeremy

It's been my experience that if you do not have DISPLAY set before you 
ssh then you will not have it set after you ssh (usually to 
localhost: where n is usually not 0).


BTW don't put the IP address in DISPLAY - just set it to DISPLAY=:0.

BTW2 X is an awful heavy process to run if your aim is merely to run 
ASCII terminals. Instead use mintty (or rxvt) and -e ssh  
instead.



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

Re: .exe magic in Cygwin

[Charles Wilson]

On 9/2/2010 7:46 PM, Dave Korn wrote:
>   I did once try running cygport on a linux box (with a cross-compiler).  I
> don't remember exactly what went wrong, it didn't work directly out of the
> box, but it shouldn't be hard to fix.

It's only the most recent release of cygport (0.10.0) that has
rudimentary support for usage on other build environments:

0.10.0:
* Added support for building and using cross-compilers.
* Experimental support for running cygport on non-Cygwin hosts.

IIUC, cygport at best can now be used in the following build vs host
situations:

cygwin -> cygwin
other  -> cygwin
cygwin -> other

I've only tried (1) and (3), not (2).

--
Chuck

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

RE: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set

[John Carey]

On Aug 12 01:11, Corinna Vinschen wrote:
> On Aug 12 06:54, Andy Koppe wrote:
> > On 11 August 2010 20:55, John Carey wrote:
> > > So is your idea that if SetCurrentDirectory() fails because
> > > of path length or permissions, then Cygwin would just accept
> > > the failure and keep an internal record the
> > > POSIX current working directory and use that for all
> > > Cygwin calls, not the Win32 notion of current directory?
> >
> > Yes. The question then becomes what to do about the Win32 working
> > directory in that case.
> 
> Actually, Cygwin accepts *any* directory it can open as CWD:
> 
> - Directories which can only be opened under SE_BACKUP_NAME.
> - Directories with a length up to 32768 chars.
> - Virtual directories, which don't exist at all as filesystem-based
>   paths, like /proc, /cygdrive, etc.
> 

In Aug 17 10:15, Corinna Vinschen wrote:
> I just released 1.7.6-1.
...
> What changed since Cygwin 1.7.5:
> 
> 
> - Cygwin handles the current working directory entirely on its own.  The
>   Win32 current working directory is set to an invalid path to be out of
>   the way.  This affects calls to the Win32 file API (CreateFile, etc.).
>   See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api

Thank you very much for the fix!

I've been running tests against Cygwin 1.7.6, and then 1.7.7,
and those sporadic, non-deterministic failures in CreatePipe
did stop after the 1.7.6 upgrade, and are still gone in 1.7.7.
I think it's been long enough to conclude that it is not just
the non-determinism--it really is fixed, as expected.

I understand that this issue opened a can of worms;
thanks again for your efforts to overcome those difficulties.

-- John

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

Re: .exe magic in Cygwin

[Dave Korn]

On 02/09/2010 21:44, Al wrote:
>> Sounds like you didn't run autoreconf (which would have been done
>> automatically via the supported mechanism).
> 
> Right. I applied it the traditional way.

  Ah, you have to understand this about cygport patches: they only contain
patches for the source files, not the autogenerated ones.  So they have
patches for e.g. Makefile.am, configure.ac; but not for configure or even
Makefile.in.  It's vitally necessary to autoreconf after applying a patch that
you get from a cygport-based package.

> As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I
> rather have to figure out one of those hidden ways.

  Well, if you're doing it in a POSIX-compatible environment, you should be
able to run cygport - with maybe a few minor bugs cropping up, but basically
it's just a bunch of shell scripts that invoke the autotools, gcc and
binutils, so they should be relatively easy to port to any similar environment.

  I did once try running cygport on a linux box (with a cross-compiler).  I
don't remember exactly what went wrong, it didn't work directly out of the
box, but it shouldn't be hard to fix.

cheers,
  DaveK

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

Re: The un-notified update of gcc4-4.3.4-3 cause setup failed(build date 2009-12-11 to 2010-08-15, caused file size mismatch)

[Dave Korn]

On 02/09/2010 05:32, LiuYan 刘研 wrote:
> Today I try to setup cygwin on a new server, it keeps failed with a
> "cyggcc_s-1.dll is missed" error in the last post-install phase.

  I'm sorry it caused you a problem, I'm afraid setup.exe was smarter than I
am and it spotted the difference when I hoped it wouldn't.  I thought that it
would be ok, since cyggcc_s-1.dll would already be installed, so it shouldn't
have been looking to upgrade anything.

  Are you perhaps sharing a local package cache dir between both these
machines, on a network shared drive or similar?

> I rename gcc4 directory to gcc4-old, reinstall gcc4 and libgcc1 package, it
> works ok finally.

  Right, that workaround should suffice.  I wanted to avoid everyone who
already had the package installed from having to redownload it because the
only thing that changed was a couple of 'x' permission bits on a couple of the
scripts.


cheers,
  DaveK

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

Re: How does one change the default shell?

[RISINGP1]

> > Ah, so you mean how to change /bin/sh to be pdksh instead of bash. 
Simple:
> >
> > cp /bin/{pdk,}sh
> >
> > But be prepared to redo that every time you upgrade bash via 
setup.exe, 
> > and don't come crying to the list if things break that were expecting 
> > bash when they got pdksh.

Thanks.  I was hoping to effect the change environmentally - not 
have to change exe's.

Should I follow that route, no crying will ensue.

I will probably just continue using the shebang line for safety.

- Phil

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

Re: How does one change the default shell?

[RISINGP1]

[ACK!  I just realized I was continuing my usurping of the thread. Sorry.]

>On 09/02/2010 04:29 PM, risin...@nationwide.com wrote:
>> I use pdksh as my login shell - I have been using the Korn shell 
(thanks
>> Dave!) since 1984 or so, so it is what I am used to and has features I
>> haven't been able to find in bash - at least not yet.  So to expedite
>> script writing, I use the ksh language and features  Every time that I
>> write a script, I have to remember to put in the shebang line
>> (#!/bin/pdksh) or half the time my scripts won't work.
>>
>> Is there a way to change the default shell for cygwin?  I checked the 
user
>> guide and the FAQ, but no joy there.  I tried setting and exporting the
>> SHELL variable, but that did not work.
>
>Assuming you meant the default shell for your particular user id, it is 
>just a matter of changing cygwin.bat or whatever shortcut you are using 
>to start cygwin to call pdksh instead of bash.  You can also edit 
>/etc/passwd to set your preferred shell (some tools, like mintty, honor 
>that setting).

My /etc/passwd entry:

RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh

My cygwin.bat:

@echo off

C:
chdir C:\cygwin\bin

REM bash --login -i
REM pdksh -l -i
start mintty -p 70,0 -t Console -e -

This starts me off in pdksh, but when I execute a shell script, it runs 
under bash.

Any other ideas?

Thanks,

- Phil

P.S.
I did not realize I was commandeering the thread.  My apologies - it won't 
happen again.


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

Re: How does one change the default shell?

[Eric Blake]

On 09/02/2010 04:49 PM, risin...@nationwide.com wrote:

write a script, I have to remember to put in the shebang line
(#!/bin/pdksh) or half the time my scripts won't work.

Is there a way to change the default shell for cygwin?  I checked the

user

guide and the FAQ, but no joy there.  I tried setting and exporting the
SHELL variable, but that did not work.


Assuming you meant the default shell for your particular user id, it is
just a matter of changing cygwin.bat or whatever shortcut you are using
to start cygwin to call pdksh instead of bash.  You can also edit
/etc/passwd to set your preferred shell (some tools, like mintty, honor
that setting).


This starts me off in pdksh, but when I execute a shell script, it runs
under bash.


Ah, so you mean how to change /bin/sh to be pdksh instead of bash.  Simple:

cp /bin/{pdk,}sh

But be prepared to redo that every time you upgrade bash via setup.exe, 
and don't come crying to the list if things break that were expecting 
bash when they got pdksh.



I did not realize I was commandeering the thread.  My apologies - it won't
happen again.


Merely changing a Subject: line does not change the In-Reply-To: headers 
that form threading.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: How does one change the default shell?

[RISINGP1]

>On 09/02/2010 04:29 PM, risin...@nationwide.com wrote:
>> I use pdksh as my login shell - I have been using the Korn shell 
(thanks
>> Dave!) since 1984 or so, so it is what I am used to and has features I
>> haven't been able to find in bash - at least not yet.  So to expedite
>> script writing, I use the ksh language and features  Every time that I
>> write a script, I have to remember to put in the shebang line
>> (#!/bin/pdksh) or half the time my scripts won't work.
>>
>> Is there a way to change the default shell for cygwin?  I checked the 
user
>> guide and the FAQ, but no joy there.  I tried setting and exporting the
>> SHELL variable, but that did not work.
>
>Assuming you meant the default shell for your particular user id, it is 
>just a matter of changing cygwin.bat or whatever shortcut you are using 
>to start cygwin to call pdksh instead of bash.  You can also edit 
>/etc/passwd to set your preferred shell (some tools, like mintty, honor 
>that setting).

My /etc/passwd entry:

RISINGP1:unused_by_nt/2000/xp:287838:10545:RISINGP1,U-NWIE\RISINGP1,S-1-5-21-725345543-616249376-1177238915-277838:/cygdrive/c/cygwin/home/risingp1:/bin/pdksh

My cygwin.bat:

@echo off

C:
chdir C:\cygwin\bin

REM bash --login -i
REM pdksh -l -i
start mintty -p 70,0 -t Console -e -

This starts me off in pdksh, but when I execute a shell script, it runs 
under bash.

Any other ideas?

Thanks,

- Phil

P.S.
I did not realize I was commandeering the thread.  My apologies - it won't 
happen again.


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

Re: [ANNOUNCEMENT] Updated: OpenSSH-5.6p1-1

[Jon TURNEY]

On 23/08/2010 16:15, Corinna Vinschen wrote:

I've just updated the Cygwin version of OpenSSH to 5.6p1-1.

This is a new major upstream release.  The Cygwin release is created
from the vanilla sources.


It looks like this update has reverted the default XAuthLocation from 
/usr/bin/xauth to /usr/X11R6/bin/xauth.


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

Re: export DISPLAY={localWorkstationIP} in mintty

[Jeremy Bopp]

On 9/2/2010 5:12 PM, PaulHR wrote:
> 
> I got the standard error.
> Error: Can't open display:
> 
> I made sure xWin Server was running
> Did a -vvv on the ssh and saw nothing for X11
> 
> What else can I look at?

It would be really helpful if you included a little context from earlier
bits of the conversation to which you are responding.  I'm going to
assume that you responded to my message suggesting you use the -X option
to ssh. ;-)

It's possible that the corresponding server-side option to allow that
feature is disabled.  If so, you could try to reconfigure the ssh
server.  The option to enable is named X11Forwarding and it should be
set to "yes".  If you are not allowed to do that, then your only option
is to go back to your original idea of figuring out your local IP.  This
will require a bit more effort on your part.

When you connect to the remote machine, there should be an environment
variable named SSH_CLIENT set.  It appears to be a space delimited list
where the first item is your client's IP address.  Given that and
assuming your shell is bash on the server, you can use the following to
set the DISPLAY environment variable after you open your connection:

export DISPLAY=$(echo $SSH_CLIENT | cut -d' ' -f1):0

If that works for you, you may want to put it in your .bashrc or
.bash_profile script on the server side so that it happens automatically
every time you connect.

-Jeremy

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

Re: How does one change the default shell?

[Eric Blake]

On 09/02/2010 04:29 PM, risin...@nationwide.com wrote:

I use pdksh as my login shell - I have been using the Korn shell (thanks
Dave!) since 1984 or so, so it is what I am used to and has features I
haven't been able to find in bash - at least not yet.  So to expedite
script writing, I use the ksh language and features  Every time that I
write a script, I have to remember to put in the shebang line
(#!/bin/pdksh) or half the time my scripts won't work.


By the way, please don't commandeer threads.  Start a new thread for a 
new topic.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: How does one change the default shell?

[Eric Blake]

On 09/02/2010 04:29 PM, risin...@nationwide.com wrote:

I use pdksh as my login shell - I have been using the Korn shell (thanks
Dave!) since 1984 or so, so it is what I am used to and has features I
haven't been able to find in bash - at least not yet.  So to expedite
script writing, I use the ksh language and features  Every time that I
write a script, I have to remember to put in the shebang line
(#!/bin/pdksh) or half the time my scripts won't work.

Is there a way to change the default shell for cygwin?  I checked the user
guide and the FAQ, but no joy there.  I tried setting and exporting the
SHELL variable, but that did not work.


Assuming you meant the default shell for your particular user id, it is 
just a matter of changing cygwin.bat or whatever shortcut you are using 
to start cygwin to call pdksh instead of bash.  You can also edit 
/etc/passwd to set your preferred shell (some tools, like mintty, honor 
that setting).


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

How does one change the default shell?

[RISINGP1]

I use pdksh as my login shell - I have been using the Korn shell (thanks 
Dave!) since 1984 or so, so it is what I am used to and has features I 
haven't been able to find in bash - at least not yet.  So to expedite 
script writing, I use the ksh language and features  Every time that I 
write a script, I have to remember to put in the shebang line 
(#!/bin/pdksh) or half the time my scripts won't work.

Is there a way to change the default shell for cygwin?  I checked the user 
guide and the FAQ, but no joy there.  I tried setting and exporting the 
SHELL variable, but that did not work.

Thanks,

- Phil

Phil Rising, Principal Consultant for Sogeti USA, LLC
Contracted to Nationwide, Corporate Internet and Contact Center Solutions 
Team
(Work) (614) 677-7445, (Fax) (614) 677-7046
Alternate email: phil.ris...@us.sogeti.com

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

Re: export DISPLAY={localWorkstationIP} in mintty

[PaulHR]

I got the standard error.
Error: Can't open display:

I made sure xWin Server was running
Did a -vvv on the ssh and saw nothing for X11

What else can I look at?

-- 
View this message in context: 
http://old.nabble.com/export-DISPLAY%3D%7BlocalWorkstationIP%7D-in-mintty-tp29609361p29609623.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Vasya Pupkin]

There we go, a proper patch. It adds two command line parameters:

-f --no-acl-files
-F --no-acl-dirs

I could not figure if that's possible to share single variable between
two source files, so I just used two variables. At least it works as
intended and covers every situation.

On Thu, Sep 2, 2010 at 9:12 AM, Christopher Faylor
 wrote:
> On Thu, Sep 02, 2010 at 06:08:37AM +0400, Vasya Pupkin wrote:
>>Because I prefer to keep things under control. And I don't think it
>>will require a huge amount of work to disable working with permissions
>>in setup.exe with command line switch.
>
> Well, go ahead then.  What are you waiting for?  Send us a patch.
>
> cgf
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>


filemanip.cc.diff
Description: Binary data


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

setup.exe version 2.721 crashes when performing a reinstall

[KJ]

When I try to use reinstall the setup.exe crashes on Windows XP as well
as on Windows 7. The report below is from a crash on Windows 7.

Has someone else experienced the same problem?

TIA
KJ



Version=1
EventType=APPCRASH
EventTime=129279109701574905
ReportType=2
Consent=1
ReportIdentifier=9038edba-b69d-11df-80fc-0023ae583e0a
IntegratorReportIdentifier=9038edb9-b69d-11df-80fc-0023ae583e0a
WOW64=1
Response.type=4
Sig[0].Name=Anwendungsname
Sig[0].Value=setup.exe_unknown
Sig[1].Name=Anwendungsversion
Sig[1].Value=0.0.0.0
Sig[2].Name=Anwendungszeitstempel
Sig[2].Value=4c77e78c
Sig[3].Name=Fehlermodulname
Sig[3].Value=StackHash_0a9e
Sig[4].Name=Fehlermodulversion
Sig[4].Value=0.0.0.0
Sig[5].Name=Fehlermodulzeitstempel
Sig[5].Value=
Sig[6].Name=Ausnahmecode
Sig[6].Value=c005
Sig[7].Name=Ausnahmeoffset
Sig[7].Value=ff7e5263
DynamicSig[1].Name=Betriebsystemversion
DynamicSig[1].Value=6.1.7600.2.0.0.256.4
DynamicSig[2].Name=Gebietsschema-ID
DynamicSig[2].Value=1031
DynamicSig[22].Name=Zusatzinformation 1
DynamicSig[22].Value=0a9e
DynamicSig[23].Name=Zusatzinformation 2
DynamicSig[23].Value=0a9e372d3b4ad19135b953a78882e789
DynamicSig[24].Name=Zusatzinformation 3
DynamicSig[24].Value=0a9e
DynamicSig[25].Name=Zusatzinformation 4
DynamicSig[25].Value=0a9e372d3b4ad19135b953a78882e789
UI[2]=E:\Downloads\CygInstall\setup.exe
UI[3]=setup.exe funktioniert nicht mehr
UI[4]=Windows kann online nach einer Lösung für das Problem suchen.
UI[5]=Online nach einer Lösung suchen und das Programm schließen
UI[6]=Später online nach einer Lösung suchen und das Programm schließen
UI[7]=Programm schließen
LoadedModule[0]=E:\Downloads\CygInstall\setup.exe
LoadedModule[1]=C:\Windows\SysWOW64\ntdll.dll
LoadedModule[2]=C:\Windows\syswow64\kernel32.dll
LoadedModule[3]=C:\Windows\syswow64\KERNELBASE.dll
LoadedModule[4]=C:\Windows\syswow64\ADVAPI32.DLL
LoadedModule[5]=C:\Windows\syswow64\msvcrt.dll
LoadedModule[6]=C:\Windows\SysWOW64\sechost.dll
LoadedModule[7]=C:\Windows\syswow64\RPCRT4.dll
LoadedModule[8]=C:\Windows\syswow64\SspiCli.dll
LoadedModule[9]=C:\Windows\syswow64\CRYPTBASE.dll
LoadedModule[10]=C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.DLL
LoadedModule[11]=C:\Windows\syswow64\GDI32.dll
LoadedModule[12]=C:\Windows\syswow64\USER32.dll
LoadedModule[13]=C:\Windows\syswow64\LPK.dll
LoadedModule[14]=C:\Windows\syswow64\USP10.dll
LoadedModule[15]=C:\Windows\syswow64\SHLWAPI.dll
LoadedModule[16]=C:\Windows\syswow64\OLE32.dll
LoadedModule[17]=C:\Windows\syswow64\SHELL32.DLL
LoadedModule[18]=C:\Windows\system32\WSOCK32.DLL
LoadedModule[19]=C:\Windows\syswow64\WS2_32.dll
LoadedModule[20]=C:\Windows\syswow64\NSI.dll
LoadedModule[21]=C:\Windows\system32\apphelp.dll
LoadedModule[22]=C:\Windows\AppPatch\AcGenral.DLL
LoadedModule[23]=C:\Windows\system32\UxTheme.dll
LoadedModule[24]=C:\Windows\system32\WINMM.dll
LoadedModule[25]=C:\Windows\system32\samcli.dll
LoadedModule[26]=C:\Windows\syswow64\OLEAUT32.dll
LoadedModule[27]=C:\Windows\system32\MSACM32.dll
LoadedModule[28]=C:\Windows\system32\VERSION.dll
LoadedModule[29]=C:\Windows\system32\sfc.dll
LoadedModule[30]=C:\Windows\system32\sfc_os.DLL
LoadedModule[31]=C:\Windows\system32\USERENV.dll
LoadedModule[32]=C:\Windows\system32\profapi.dll
LoadedModule[33]=C:\Windows\system32\dwmapi.dll
LoadedModule[34]=C:\Windows\syswow64\SETUPAPI.dll
LoadedModule[35]=C:\Windows\syswow64\CFGMGR32.dll
LoadedModule[36]=C:\Windows\syswow64\DEVOBJ.dll
LoadedModule[37]=C:\Windows\syswow64\urlmon.dll
LoadedModule[38]=C:\Windows\syswow64\CRYPT32.dll
LoadedModule[39]=C:\Windows\syswow64\MSASN1.dll
LoadedModule[40]=C:\Windows\syswow64\iertutil.dll
LoadedModule[41]=C:\Windows\system32\MPR.dll
LoadedModule[42]=C:\Windows\system32\IMM32.DLL
LoadedModule[43]=C:\Windows\syswow64\MSCTF.dll
LoadedModule[44]=C:\Windows\syswow64\CLBCatQ.DLL
LoadedModule[45]=C:\Windows\syswow64\wininet.dll
LoadedModule[46]=C:\Windows\syswow64\Normaliz.dll
LoadedModule[47]=C:\Windows\system32\dnsapi.DLL
LoadedModule[48]=C:\Windows\system32\iphlpapi.DLL
LoadedModule[49]=C:\Windows\system32\WINNSI.DLL
LoadedModule[50]=C:\Windows\system32\RASAPI32.dll
LoadedModule[51]=C:\Windows\system32\rasman.dll
LoadedModule[52]=C:\Windows\system32\rtutils.dll
LoadedModule[53]=C:\Windows\system32\sensapi.dll
LoadedModule[54]=C:\Windows\system32\peerdist.dll
LoadedModule[55]=C:\Windows\system32\AUTHZ.dll
LoadedModule[56]=C:\Windows\system32\NLAapi.dll
LoadedModule[57]=C:\Windows\System32\mswsock.dll
LoadedModule[58]=C:\Windows\System32\winrnr.dll
LoadedModule[59]=C:\Windows\system32\napinsp.dll
LoadedModule[60]=C:\Windows\system32\pnrpnsp.dll
LoadedModule[61]=C:\Windows\System32\wshtcpip.dll
LoadedModule[62]=C:\Windows\System32\wship6.dll
LoadedModule[63]=C:\Windows\system32\rasadhlp.dll
LoadedModule[64]=C:\Windows\System32\fwpuclnt.dll
LoadedModule[65]=C:\Windows\system32\jsproxy.dll
LoadedModule[66]=C:\Windows\SysWOW64\jscript.dll
LoadedModule[67]=C:\Windows\system32\CRYPTSP.d

Re: export DISPLAY={localWorkstationIP} in mintty

[Jeremy Bopp]

On 9/2/2010 4:34 PM, PaulHR wrote:
> 
> Is there anyway to get the IP address from the local workstation, running
> mintty, and putting the local workstation IP address into the export DISPLAY
> command running on a different mintty shell, running on a server e.g.
> 
> 
> export DISPLAY={localWorkstationIP}
> 
> 
> Or, is there a way to get the local workstation IP address in a mintty
> shell, to a remote server, in such a fashion that it can be used in the
> export command like above?
> 
> 
> I am trying to get my xWindows export setup automatically when I sign on.

If you're still connecting to the remote systems with SSH, you can allow
SSH to tunnel the X connection for you using the -X option to the ssh
client you use to make your connection.  The remote DISPLAY variable
then automatically points to something which does effectively what you need.

-Jeremy

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

export DISPLAY={localWorkstationIP} in mintty

[PaulHR]

Is there anyway to get the IP address from the local workstation, running
mintty, and putting the local workstation IP address into the export DISPLAY
command running on a different mintty shell, running on a server e.g.


export DISPLAY={localWorkstationIP}


Or, is there a way to get the local workstation IP address in a mintty
shell, to a remote server, in such a fashion that it can be used in the
export command like above?


I am trying to get my xWindows export setup automatically when I sign on.
-- 
View this message in context: 
http://old.nabble.com/export-DISPLAY%3D%7BlocalWorkstationIP%7D-in-mintty-tp29609361p29609361.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Inability to delete *or rename* CWD of any program driving me nuts

[Daniel Colascione]

I keep bumping into Cygwin's new inability rename or delete
directories that are the CWD of any program. In particular, Emacs will
often start background processes like aspell in whatever directory
happens to be the default-directory for the current buffer. That
program hangs around even after I kill all buffers visiting files in
that directory, so even hours after I last edit a file in a directory,
I find myself wondering why on earth 'mv' on it hangs. Also, I have
(bad?) habit of leaving old terminal windows around, sometimes sitting
in directories I later delete or rename. I get rid of them eventually,
but having to hunt down and kill them to perform basic filesystem
operations is a nuisance.

Of course, these annoyances can be worked around, but it was less
cumbersome to just allow cwd to be modified.

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

Re: .exe magic in Cygwin

[Jeremy Bopp]

On 9/2/2010 3:44 PM, Al wrote:
>> setup.exe to download the sources and several prerequisite tools (cygport,
>> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'.  Other ways
>> work, but I won't support them on this list.  See also
> 
> As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I
> rather have to figure out one of those hidden ways. If I can't find
> it, I have to fall back from Cygwin to Interix. But that would cut
> half of my target group.

Cygport is rather similar to emerge/ebuild already.  You might find it
worthwhile to give it a look.

>> /usr/share/doc/Cygwin/coreutils.README.
> 
> Yes, it's time to dig a little deeper into the Cygwin scripts. It has
> to be scriptable in the end. Then I can get it into Emerge. A
> graphical setup.exe is the wrong way for my approach. However there
> are scripts below.

If all you need is a way to install existing Cygwin packages from the
command line, you can do that quite well with setup.exe.  It has many
command line options which help automate the installation process.

If you want to build a replacement anyway, you should probably delve
into why nothing like what you want exists already.  This issue comes up
repeatedly on this list, so you should be able to find much in the list
archives.

-Jeremy

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

Re: simulating console input

[Eric Blake]

On 09/02/2010 03:17 PM, risin...@nationwide.com wrote:

How could I simulate the "Y" keypress?

"echo Y | DosProgram.exe" does not work...


Would an inline document work?

DosProgram.exe<

No.  Bash uses a pipe under the hood for here-docs, so it is no 
different than the already-established non-working 'echo Y | program'.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: Windows-style pathname does not work as command - why?

[Christopher Faylor]

On Thu, Sep 02, 2010 at 12:13:12PM -0600, Eric Blake wrote:
>On 09/02/2010 11:45 AM, Daniel Barclay wrote:
>> I don't quite understand this behavior:
>>
>> $ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe
>> C:\tools\emacs-23.2\bin\runemacs.exe
>> $ C:\\tools\\emacs-23.2\\bin\\runemacs.exe
>> bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found
>>
>> In particular, why is it that bash does not understand that Windows
>> pathname when it is used as a command argument, even though bash and
>> Cygwin clearly understand it when it is used as a command argument?
>>
>>
>> Is that behavior a bug (e.g., does bash try to judge whether the command
>> is an absolute vs. relative pathname without either first converting to
>> a Unix-style pathname or otherwise recognizing Windows-style pathname)?
>
>You're not the first to notice this, but it's also not the highest 
>priority on my list to look into, because we already recommend using 
>POSIX style paths in the first place.
>
>> Or is it some known irregularity (resulting from trying to handle both
>> Windows- and Unix-style pathnames) that couldn't be resolved?
>
>Oh, I'm sure that bash could be patched to be smarter about DOS-style 
>pathnames.  But no one has been bothered by it enough to write a patch yet.

And, trying hard to make MS-DOS stuff work is sorta counter to the
whole reason for Cygwin.

cgf

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

Re: simulating console input

[RISINGP1]

>On 9/2/2010 3:47 AM, Peter Münster wrote:
>> Hello,
>>
>> I would like to run a Dos program, that needs keyboard input (just one 
"Y"),
>> automatically via "make" in an ssh-session.
>>
>> How could I simulate the "Y" keypress?
>>
>> "echo Y | DosProgram.exe" does not work...
>>
>> The keypress is accepted only in a dos-console.
>
>Read <
http://cygwin.com/cygwin-ug-net/using-effectively.html#using-console>.
>Then add this fact - the SSH server uses ptys.  So your program will not
>work with a single character put in the input buffer.  One could
>envision using 'yes' to fill the buffer of the pipe that the Windows 
program
>interprets the pty to be.  Perhaps a nicer alternative is to build the
>problematic program with Cygwin, if that's an option, so that it will
>understand the pty.

Would an inline document work?

DosProgram.exe 

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Vasya Pupkin]

On Fri, Sep 3, 2010 at 12:49 AM, Andy Koppe  wrote:
> How did you find the problematic permissions? By looking at the
> security tab of the file properties? Did you confirm that users really
> were able to modify files they weren't supposed to? Could the
> offending privileges have been inherited from the directory Cygwin was
> installed in?

If only I could remember all the details. I didn't have much time to
figure out what happened. Easy solution for me was to disable acl in
cygwin, which I did, and was happy until I used setup.exe and found
out it destroyed my permissions.

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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Charles Wilson]

On 9/2/2010 4:49 PM, Andy Koppe wrote:
> How did you find the problematic permissions? By looking at the
> security tab of the file properties?

Remember that the security tab has the very bad habit of re-ordering the
ACLs -- but the effect of ACLs is order dependent. Hence, just looking
at the permissions of a cygwin-managed directory or file, using the
security tab, can introduce a Heisenbug: there was no bug until you
observed the permissions.  Use getfacl/setfacl to manipulate the
permissions/ACLs of cygwin-managed files.

--
Chuck

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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Andy Koppe]

On 2 September 2010 16:05, Vasya Pupkin wrote:
> In my case, these additional permissions were allowing everyone to
> modify files. Not harmful at all, indeed. I do not remember all the
> details, I remember these permissions were everywhere. So I just
> replaced everything with proper permissions and disabled acl support
> in cygwin. The only problem was setup.exe but now I compiled it with a
> modification and this last problem gone.
>
> I understand that I do not have all the details required for a bug
> report. And it wasn't an attempt to report a bug.

Intended or not, this is a bug report, and a rather serious one at
that. Any further details might be useful.

When was it that you saw that problem? Still during the beta phase or
after 1.7.1 was released?

How did you find the problematic permissions? By looking at the
security tab of the file properties? Did you confirm that users really
were able to modify files they weren't supposed to? Could the
offending privileges have been inherited from the directory Cygwin was
installed in?

Andy

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

Re: .exe magic in Cygwin

[Al]

> Sounds like you didn't run autoreconf (which would have been done
> automatically via the supported mechanism).

Right. I applied it the traditional way.

> setup.exe to download the sources and several prerequisite tools (cygport,
> autoconf, ...), then using 'cygport coreutils-8.5-1 prep make'.  Other ways
> work, but I won't support them on this list.  See also

As a want to come a hybrid of Cygwin and Gentoos Emerge installer, I
rather have to figure out one of those hidden ways. If I can't find
it, I have to fall back from Cygwin to Interix. But that would cut
half of my target group.

> /usr/share/doc/Cygwin/coreutils.README.

Yes, it's time to dig a little deeper into the Cygwin scripts. It has
to be scriptable in the end. Then I can get it into Emerge. A
graphical setup.exe is the wrong way for my approach. However there
are scripts below.

Al

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

Re: How to get a script file to use bash and ssh

[Jeremy Bopp]

On 9/2/2010 3:31 PM, Andy Koppe wrote:
> On 2 September 2010 20:52, Jeremy Bopp wrote:
>>> That's all more complicated than it needs to be. Just make windows
>>> shortcuts to c:\cygwin\bin\ssh.exe, where "Start in:" is set to
>>> c:\cygwin\bin, and modify "Target:" to contain "C:\cygwin\bin\ssh.exe
>>> usern...@hostname" (without the quotes of course).
>>>
>>> Better yet, install mintty if you don't already have it, and set the
>>> shortcuts' target to: "C:\cygwin\bin\mintty.exe -e /bin/ssh
>>> usern...@hostname"
>>>
>>> (Mintty is a much better term window than cmd.)
>>
>> I was going to suggest much the same things to start; however, there
>> could be issues with home directory settings (necessary for locating the
>> private ssh keys).  It might also be good to eventually work in the ssh
>> agent so that the need for passwords can be reduced.
> 
> That shouldn't be an issue, because HOME, if not set already, is set
> automatically based on the user's /etc/passwd entry or the Windows
> HOMEDRIVE and HOMEPATH variables when the initial Cygwin process is
> started.

Assuming, of course, that the necessary entry in /etc/passwd is set
correctly.  The OP sounds pretty green and may have a different idea of
his home directory's location than Cygwin deduces, so a little extra
hand holding may be in order. :-)

-Jeremy

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

Re: How to get a script file to use bash and ssh

[Andy Koppe]

On 2 September 2010 20:52, Jeremy Bopp wrote:
>> That's all more complicated than it needs to be. Just make windows
>> shortcuts to c:\cygwin\bin\ssh.exe, where "Start in:" is set to
>> c:\cygwin\bin, and modify "Target:" to contain "C:\cygwin\bin\ssh.exe
>> usern...@hostname" (without the quotes of course).
>>
>> Better yet, install mintty if you don't already have it, and set the
>> shortcuts' target to: "C:\cygwin\bin\mintty.exe -e /bin/ssh
>> usern...@hostname"
>>
>> (Mintty is a much better term window than cmd.)
>
> I was going to suggest much the same things to start; however, there
> could be issues with home directory settings (necessary for locating the
> private ssh keys).  It might also be good to eventually work in the ssh
> agent so that the need for passwords can be reduced.

That shouldn't be an issue, because HOME, if not set already, is set
automatically based on the user's /etc/passwd entry or the Windows
HOMEDRIVE and HOMEPATH variables when the initial Cygwin process is
started.

Andy

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

Re: .exe magic in Cygwin

[Eric Blake]

On 09/02/2010 02:06 PM, Al wrote:

I first compiled coreutils without the cygwin patch. It did compile
but afterwards the compilation of findutils, etc. was broken. For
example configure.status of wget was truncated at the top and out of
order at the bottom. That stopped all further efforts of mine.

Now I applied that big patch.


How?  The only supported way of building coreutils for cygwin is by 
using setup.exe to download the sources and several prerequisite tools 
(cygport, autoconf, ...), then using 'cygport coreutils-8.5-1 prep 
make'.  Other ways work, but I won't support them on this list.  See 
also /usr/share/doc/Cygwin/coreutils.README.




copy.c complaints an error of an undefined reference ot
'cygwin_spelling'. Guess that is a library I have to install.


Sounds like you didn't run autoreconf (which would have been done 
automatically via the supported mechanism).


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: .exe magic in Cygwin

[Al]

>
> Coreutils tends to be an exception, because it is so core to the system.
>  Other tools that I also maintain, like m4 or findutils, port with 0
> patches.
>

Thank you. That gives me back some optimism.

I first compiled coreutils without the cygwin patch. It did compile
but afterwards the compilation of findutils, etc. was broken. For
example configure.status of wget was truncated at the top and out of
order at the bottom. That stopped all further efforts of mine.

Now I applied that big patch.

copy.c complaints an error of an undefined reference ot
'cygwin_spelling'. Guess that is a library I have to install.

But some optimism is back

Al

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

Re: How to get a script file to use bash and ssh

[Jeremy Bopp]

On 9/2/2010 2:36 PM, Heath Kehoe wrote:
>  On 9/2/2010 2:10 PM, PaulHR wrote:
> That's all more complicated than it needs to be. Just make windows
> shortcuts to c:\cygwin\bin\ssh.exe, where "Start in:" is set to
> c:\cygwin\bin, and modify "Target:" to contain "C:\cygwin\bin\ssh.exe
> usern...@hostname" (without the quotes of course).
> 
> Better yet, install mintty if you don't already have it, and set the
> shortcuts' target to: "C:\cygwin\bin\mintty.exe -e /bin/ssh
> usern...@hostname"
> 
> (Mintty is a much better term window than cmd.)

I was going to suggest much the same things to start; however, there
could be issues with home directory settings (necessary for locating the
private ssh keys).  It might also be good to eventually work in the ssh
agent so that the need for passwords can be reduced.

BTW, if you only need Cygwin for connecting to remote hosts with SSH,
you might find Putty to be a better fit for your needs.

-Jeremy

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

Re: .exe magic in Cygwin

[Eric Blake]

On 09/02/2010 01:25 PM, Al wrote:

Hello,

I would like to estimate theexpenses to port general linux sources to 
Cygwin.

I did look into Cygwins patch for coreutils. It has 1231 lines of diff
code. A lot of the stuff is related to the ".exe" magic done by
cygwin.

Do I have to implement that magic in this extend into every package
that I would like to run on Cygwin or is this rather special in the
case of coreutils?


Coreutils tends to be an exception, because it is so core to the system. 
 Other tools that I also maintain, like m4 or findutils, port with 0 
patches.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: How to get a script file to use bash and ssh

[Heath Kehoe]

 On 9/2/2010 2:10 PM, PaulHR wrote:

I want to create script files that are not bound to my user id.  I want to
create over 20 different scripts files, one for each server I manage.  I
have uploaded keys to each server.  So all I should have to is enter is the
ssh command


I have put in a file called MyOpenUp.bat the following...



ssh {myserve...@myserverhostname}




I have put that command in a file called MyOpenUp.init


I have created a MyOpenUp.bat file with the following



@echo off


C:

chdir C:\cygwin\bin

bash --init-file MyOpenUp.init -i -l





That's all more complicated than it needs to be. Just make windows 
shortcuts to c:\cygwin\bin\ssh.exe, where "Start in:" is set to 
c:\cygwin\bin, and modify "Target:" to contain "C:\cygwin\bin\ssh.exe 
usern...@hostname" (without the quotes of course).


Better yet, install mintty if you don't already have it, and set the 
shortcuts' target to: "C:\cygwin\bin\mintty.exe -e /bin/ssh 
usern...@hostname"


(Mintty is a much better term window than cmd.)

-heath


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


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

Re: How to get a script file to use bash and ssh

[PaulHR]

Yes, that is correct.



Jeremy Bopp-3 wrote:
> 
> On 9/2/2010 2:10 PM, PaulHR wrote:
>> 
>> I want to create script files that are not bound to my user id.  I want
>> to
>> create over 20 different scripts files, one for each server I manage.  I
>> have uploaded keys to each server.  So all I should have to is enter is
>> the
>> ssh command 
>> 
>> 
>> I have put in a file called MyOpenUp.bat the following... 
>> 
>> 
>> 
>> ssh {myserve...@myserverhostname}
>> 
>> 
>> 
>> 
>> I have put that command in a file called MyOpenUp.init
>> 
>> 
>> I have created a MyOpenUp.bat file with the following
>> 
>> 
>> 
>> @echo off
>> 
>> 
>> C:
>> 
>> chdir C:\cygwin\bin
>> 
>> bash --init-file MyOpenUp.init -i -l
>> 
>> 
>> 
>> 
>> While the shell opens up all I get is
>> 
>> cygwi...@localhostname ~
>> 
>> $
> 
> It looks like you are trying to effectively create one shortcut per
> remote host which you can run and automatically have it open an ssh
> session to that host using a particular user specific to that host.  Is
> that a correct assessment?
> 
> -Jeremy
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/How-to-get-a-script-file-to-use-bash-and-ssh-tp29608117p29608244.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

.exe magic in Cygwin

[Al]

Hello,

I would like to estimate theexpenses to port general linux sources to 
Cygwin.

I did look into Cygwins patch for coreutils. It has 1231 lines of diff
code. A lot of the stuff is related to the ".exe" magic done by
cygwin.

Do I have to implement that magic in this extend into every package
that I would like to run on Cygwin or is this rather special in the
case of coreutils?

Thank you for advice

Al

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

Re: How to get a script file to use bash and ssh

[Jeremy Bopp]

On 9/2/2010 2:10 PM, PaulHR wrote:
> 
> I want to create script files that are not bound to my user id.  I want to
> create over 20 different scripts files, one for each server I manage.  I
> have uploaded keys to each server.  So all I should have to is enter is the
> ssh command 
> 
> 
> I have put in a file called MyOpenUp.bat the following... 
> 
> 
> 
> ssh {myserve...@myserverhostname}
> 
> 
> 
> 
> I have put that command in a file called MyOpenUp.init
> 
> 
> I have created a MyOpenUp.bat file with the following
> 
> 
> 
> @echo off
> 
> 
> C:
> 
> chdir C:\cygwin\bin
> 
> bash --init-file MyOpenUp.init -i -l
> 
> 
> 
> 
> While the shell opens up all I get is
> 
> cygwi...@localhostname ~
> 
> $

It looks like you are trying to effectively create one shortcut per
remote host which you can run and automatically have it open an ssh
session to that host using a particular user specific to that host.  Is
that a correct assessment?

-Jeremy

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

How to get a script file to use bash and ssh

[PaulHR]

I want to create script files that are not bound to my user id.  I want to
create over 20 different scripts files, one for each server I manage.  I
have uploaded keys to each server.  So all I should have to is enter is the
ssh command 


I have put in a file called MyOpenUp.bat the following... 



ssh {myserve...@myserverhostname}




I have put that command in a file called MyOpenUp.init


I have created a MyOpenUp.bat file with the following



@echo off


C:

chdir C:\cygwin\bin

bash --init-file MyOpenUp.init -i -l




While the shell opens up all I get is

cygwi...@localhostname ~

$



I am a cygwin newbie.  I am sure it is me not understanding the man page
correctly.  What am I doing wrong?  The Documentation did not help either.

TIA



-- 
View this message in context: 
http://old.nabble.com/How-to-get-a-script-file-to-use-bash-and-ssh-tp29608117p29608117.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

re: Windows-style pathname does not work as command - why?

[neal s]

I suggest for your convenience, you try making a symbolic link  ...
Perhaps something like ...

$ ln -s /cygdrive/c/tools/emacs-23.2/bin/runemacs.exe /usr/local/bin/runemacs

Then open up a fresh shell and see if 'runemacs' now works for you.
(the shell you made the symbolic link in, will likely NOT be able to
use the new link)

new-shell$ runemacs



When I tried something similar to your situation, but with VIM I got
the following
--
$ C:\\PROGRA~1\\vim\\vim72\\gvim.exe
cygwin warning:
  MS-DOS style path detected: /usr/local/bin/C:\PROGRA~1\vim\vim72\gvim.exe
  Preferred POSIX equivalent is: /usr/local/bin/C:/PROGRA~1/vim/vim72/gvim.exe
  CYGWIN environment variable option "nodosfilewarning" turns off this warning.
  Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
bash: C:\PROGRA~1\vim\vim72\gvim.exe: command not found
-

While it may not be easy to make bash properly handle dos style paths
for executeables,
I do believe that you can make your life much easier with well chosen
symbolic links.

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

Re: Windows-style pathname does not work as command - why?

[Eric Blake]

On 09/02/2010 11:45 AM, Daniel Barclay wrote:

I don't quite understand this behavior:

$ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe
C:\tools\emacs-23.2\bin\runemacs.exe
$ C:\\tools\\emacs-23.2\\bin\\runemacs.exe
bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found

In particular, why is it that bash does not understand that Windows
pathname when it is used as a command argument, even though bash and
Cygwin clearly understand it when it is used as a command argument?


Is that behavior a bug (e.g., does bash try to judge whether the command
is an absolute vs. relative pathname without either first converting to
a Unix-style pathname or otherwise recognizing Windows-style pathname)?


You're not the first to notice this, but it's also not the highest 
priority on my list to look into, because we already recommend using 
POSIX style paths in the first place.



Or is it some known irregularity (resulting from trying to handle both
Windows- and Unix-style pathnames) that couldn't be resolved?


Oh, I'm sure that bash could be patched to be smarter about DOS-style 
pathnames.  But no one has been bothered by it enough to write a patch yet.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Windows-style pathname does not work as command - why?

[Daniel Barclay]

I don't quite understand this behavior:

$ ls C:\\tools\\emacs-23.2\\bin\\runemacs.exe
C:\tools\emacs-23.2\bin\runemacs.exe
$ C:\\tools\\emacs-23.2\\bin\\runemacs.exe
bash: C:\tools\emacs-23.2\bin\runemacs.exe: command not found

In particular, why is it that bash does not understand that Windows
pathname when it is used as a command argument, even though bash and
Cygwin clearly understand it when it is used as a command argument?


Is that behavior a bug (e.g., does bash try to judge whether the command
is an absolute vs. relative pathname without either first converting to
a Unix-style pathname or otherwise recognizing Windows-style pathname)?

Or is it some known irregularity (resulting from trying to handle both
Windows- and Unix-style pathnames) that couldn't be resolved?

Thanks,
Daniel




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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Vasya Pupkin]

On Thu, Sep 2, 2010 at 8:25 PM, Jeremy Bopp  wrote:
> Your answer was simply an assertion that there possibly was and may
> still be something wrong with the permissions handling under Cygwin, but
> that you also haven't confirmed that recently.  The details really would
> be helpful and likely necessary if you would like to have your patch
> accepted by the maintainers of setup.exe.

No, my patch can't be accepted as it removes permissions handling
completely. It wasn't me who started the thread and I believe, my
patch can be of interest for anyone else who will search for a
solution for this specific problem.

Anyway, I don't see how an option to switch off permissions handling
by setup.exe can harm while there is similar functionality in cygwin
itself. My very limited understanding of C is not enough to do this,
and I never worked with GUI applications. But I will see if it can be
done via command line switch and if I succeed, I will submit a proper
patch.

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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Jeremy Bopp]

On 9/2/2010 10:05 AM, Vasya Pupkin wrote:
> If you read again very carefully, you will see that I modified
> permissions AFTER I noticed they were messed up. Ok?

I tried to point out that your definition of "messed up" is the opposite
of Andy's.  To you, the default permissions provided by setup.exe are
messed up.  To Andy, the permissions you created are messed up.  I hope
that clarifies things.

> In my case, these additional permissions were allowing everyone to
> modify files. Not harmful at all, indeed. I do not remember all the
> details, I remember these permissions were everywhere. So I just
> replaced everything with proper permissions and disabled acl support
> in cygwin. The only problem was setup.exe but now I compiled it with a
> modification and this last problem gone.

Yes, the more I read, the more I come to believe that the disconnect
here is in the definition of correct and acceptable permissions.  Your
definition differs from that of the Cygwin developers.  It's good that
your permissions changes worked for you, but it's possible that they
won't work for everyone.  A better description of your original problem
as well as how your proposed solution addresses that problem would allow
for a more productive discussion.

> I understand that I do not have all the details required for a bug
> report. And it wasn't an attempt to report a bug. I was asked why I
> care about permissions, so I answered. Anyway, the problem is solved
> now, I also submitted an easy patch to setup.exe source for everyone
> who want to get rid of this problem as well.
> 
> If I ever get into a problem with permissions again, I will try to
> make a proper bug report instead of just fixing permissions.

Your answer was simply an assertion that there possibly was and may
still be something wrong with the permissions handling under Cygwin, but
that you also haven't confirmed that recently.  The details really would
be helpful and likely necessary if you would like to have your patch
accepted by the maintainers of setup.exe.

The only other option is to independently maintain your patch and
rebuild your version of setup.exe any time the upstream version changes.
 This won't help most users, though, because they will either not know
about your patch or not care to build their own setup.exe without having
any evidence of an existing problem and assurance that your change
doesn't introduce other problems.

If you're satisfied with your solution, so be it, but you could pretty
quickly gather the necessary details for a bug report by performing a
second installation of Cygwin into a new directory and reporting the
flawed permissions.  That could lead to the acceptance of your patch or
something similar to the benefit of everyone.

-Jeremy

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

Re: simulating console input

[Larry Hall (Cygwin)]

On 9/2/2010 3:47 AM, Peter Münster wrote:

Hello,

I would like to run a Dos program, that needs keyboard input (just one "Y"),
automatically via "make" in an ssh-session.

How could I simulate the "Y" keypress?

"echo Y | DosProgram.exe" does not work...

The keypress is accepted only in a dos-console.


Read .
Then add this fact - the SSH server uses ptys.  So your program will not
work with a single character put in the input buffer.  One could
envision using 'yes' to fill the buffer of the pipe that the Windows program
interprets the pty to be.  Perhaps a nicer alternative is to build the
problematic program with Cygwin, if that's an option, so that it will
understand the pty.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Vasya Pupkin]

If you read again very carefully, you will see that I modified
permissions AFTER I noticed they were messed up. Ok?

In my case, these additional permissions were allowing everyone to
modify files. Not harmful at all, indeed. I do not remember all the
details, I remember these permissions were everywhere. So I just
replaced everything with proper permissions and disabled acl support
in cygwin. The only problem was setup.exe but now I compiled it with a
modification and this last problem gone.

I understand that I do not have all the details required for a bug
report. And it wasn't an attempt to report a bug. I was asked why I
care about permissions, so I answered. Anyway, the problem is solved
now, I also submitted an easy patch to setup.exe source for everyone
who want to get rid of this problem as well.

If I ever get into a problem with permissions again, I will try to
make a proper bug report instead of just fixing permissions.

On Thu, Sep 2, 2010 at 6:28 PM, Jeremy Bopp  wrote:
> On 9/2/2010 12:49 AM, Vasya Pupkin wrote:
>> No, it wasn't a mess of my own making. I did not ever touch
>> permissions, and it was a clean install. I don't know where these
>> permissions came from, but ls -l displayed something like that for
>> most files:
>
> I read Andy's comment to mean that the mess of your own making is the
> result of you changing the permissions, not the existing permissions as
> left by setup.exe.  You made the mess (or correction as you see it) and
> are now fighting with setup.exe to maintain it.
>
>> drwxr-xr-x+ 1 user group      0 2010-09-02 09:32 tests
>>
>> This "+" sign after permissions string indicated non-cygwin
>> permissions which was impossible to remove using cygwin's chmod. And
>> since permissions are not inherited, it was not possible to mass
>> remove them using windows either. So, I just removed all permissions
>> and forced their inheritance. That solved all problems, until I
>> updated installation using setup.exe.
>
> The "+" indicates that there are further permissions specified as ACLs
> for which the getfacl and setfacl commands should be used to view and
> manipulate, respectively.  You would see the same behavior from ls on a
> Linux system which had ACL support and extra ACLs applied to a similar
> file or directory.  There, too, chmod would not be able to modify those
> ACLs.
>
> What your example does not indicate is that anything unintentional
> happened with the application of permissions on that example directory.
>  Nor does it indicate that the given permissions are in any way harmful
> to the maintenance of your system or the use of the files and
> directories in question.
>
> Where was that directory located?  Did you create it, or did setup.exe
> create it?  What problems do those permissions cause?
>
>> Believe me or not, but I really did not touch any permissions until I
>> noticed that strange behaviour. And I am the only administrator.
>> Machine is not a part of any domains. So, unless it's a kind of black
>> magic, there was (and maybe still is) some issue with permissions in
>> cygwin. That is why I don't want to use them.
>
> I'm sure the Cygwin developers would be more than willing to patch any
> defect surrounding the incorrect application of permissions to files
> which is the result of Cygwin itself or setup.exe.  Unfortunately, you
> have not demonstrated any such erroneous behavior yet.  It seems more
> likely that you have a small misunderstanding about how the permissions
> you see work and how they are represented under Cygwin.  Have you read
> the section of the user guide which discusses permissions under Cygwin?
>
> Perhaps, you have found a genuine defect.  If so, you need to provide
> more data so that someone else can reproduce the problem.  You could
> start by installing another instance of Cygwin into a fresh directory
> (this won't affect your primary installation) and then demonstrate the
> specific files that have faulty permissions and explain how those
> permissions will lead to further problems.
>
> With luck, someone will be able to explain why things are the way you
> see them such that you are comfortable accepting how Cygwin does things. :-)
>
> -Jeremy
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>

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

Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7

[Jeremy Bopp]

On 9/2/2010 12:49 AM, Vasya Pupkin wrote:
> No, it wasn't a mess of my own making. I did not ever touch
> permissions, and it was a clean install. I don't know where these
> permissions came from, but ls -l displayed something like that for
> most files:

I read Andy's comment to mean that the mess of your own making is the
result of you changing the permissions, not the existing permissions as
left by setup.exe.  You made the mess (or correction as you see it) and
are now fighting with setup.exe to maintain it.

> drwxr-xr-x+ 1 user group  0 2010-09-02 09:32 tests
> 
> This "+" sign after permissions string indicated non-cygwin
> permissions which was impossible to remove using cygwin's chmod. And
> since permissions are not inherited, it was not possible to mass
> remove them using windows either. So, I just removed all permissions
> and forced their inheritance. That solved all problems, until I
> updated installation using setup.exe.

The "+" indicates that there are further permissions specified as ACLs
for which the getfacl and setfacl commands should be used to view and
manipulate, respectively.  You would see the same behavior from ls on a
Linux system which had ACL support and extra ACLs applied to a similar
file or directory.  There, too, chmod would not be able to modify those
ACLs.

What your example does not indicate is that anything unintentional
happened with the application of permissions on that example directory.
 Nor does it indicate that the given permissions are in any way harmful
to the maintenance of your system or the use of the files and
directories in question.

Where was that directory located?  Did you create it, or did setup.exe
create it?  What problems do those permissions cause?

> Believe me or not, but I really did not touch any permissions until I
> noticed that strange behaviour. And I am the only administrator.
> Machine is not a part of any domains. So, unless it's a kind of black
> magic, there was (and maybe still is) some issue with permissions in
> cygwin. That is why I don't want to use them.

I'm sure the Cygwin developers would be more than willing to patch any
defect surrounding the incorrect application of permissions to files
which is the result of Cygwin itself or setup.exe.  Unfortunately, you
have not demonstrated any such erroneous behavior yet.  It seems more
likely that you have a small misunderstanding about how the permissions
you see work and how they are represented under Cygwin.  Have you read
the section of the user guide which discusses permissions under Cygwin?

Perhaps, you have found a genuine defect.  If so, you need to provide
more data so that someone else can reproduce the problem.  You could
start by installing another instance of Cygwin into a fresh directory
(this won't affect your primary installation) and then demonstrate the
specific files that have faulty permissions and explain how those
permissions will lead to further problems.

With luck, someone will be able to explain why things are the way you
see them such that you are comfortable accepting how Cygwin does things. :-)

-Jeremy

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

Re: can't compile setup.exe

[Eric Blake]

On 09/02/2010 07:38 AM, Jon TURNEY wrote:


This was broken by the recent w32api-3.15 update, which seems to have
made those PropSheet macros C++ aware, so the global scoping operator is
no longer needed.

Patch attached to fix it, but I couldn't work out how to also get it to
build with w32api-3.14.


Would an appropriate set of 'using' directives help?

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

Re: scp and cygwin randomly and automatically converts text files from utf-8 to windows encoding (cp1251)

[rPman]

I found the reason - it is the combination Far2 and plug-in "Call Command". I
use this plugin for run commands to synchronize the current list of editable
files to the server with ssh, it is clear that both rsync and scp to copy
files already modified encoding.

While running from command plug-in "Call Command" current edited file from
utf-8 automatically converted (and stored on disk) in encoding cp1251, and
to complete the re-encoded back. Perhaps this feature of the implementation
of unicode in Far2, but it was very difficult to expect such behavior from
these applications.

Sorry, that turned up the wrong. Thanks.


Andy Koppe wrote:
> 
> On 31 August 2010 20:23, rPman wrote:
>> It happens when files are copied from cygwin windows machines to any
>> linux
>> (tried different versions of ubuntu and gentoo with utf-8 locale).
> 
> Cygwin does not change the encoding of file content when copying
> files. Cygwin 1.7 does translate file names between the UTF-16
> encoding used by Windows and the encoding you have configured in
> Cygwin via the LC_ALL, LC_CTYPE or LANG variables.
> 
> Please try to desribe in more detail what you were trying to do and
> how it went wrong. Also, what version of Cygwin are you using?
> 
> 
>> As it is not possible to understand in what cases are re-encoding,
>> sometimes
>> enough to add one blank line in a text file that, when the transfer
>> encoding
>> has not happened. Just changing the format of a newline (in the source
>> files
>> are unix-style \n, but on the linux machine has come to win-style \r\n)
> 
> Line endings are a separate issue from character encodings. By
> default, directories are mounted in binary mode, where file content is
> left alone. Alternatively, they can be mounted in text mode, were line
> endings are automatically translated between Windows and Unix style.
> See http://www.cygwin.com/cygwin-ug-net/using-textbinary.html for lots
> more on that.
> 
> Andy
> 
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 
-- 
View this message in context: 
http://old.nabble.com/scp-and-cygwin-randomly-and-automatically-converts-text-files-from-utf-8-to-windows-encoding-%28cp1251%29-tp29586716p29604628.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: can't compile setup.exe

[Chris Sutcliffe]

On 2 September 2010 09:38, Jon TURNEY wrote:
> This was broken by the recent w32api-3.15 update, which seems to have made
> those PropSheet macros C++ aware, so the global scoping operator is no
> longer needed.
>
> Patch attached to fix it, but I couldn't work out how to also get it to
> build with w32api-3.14.

#if (__W32API_MAJOR_VERSION == 3 && __W32API_MINOR_VERSION < 15)

should do the trick.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

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

Re: simulating console input

[Bengt-Arne Fjellner]

 On 2010-09-02 9:47 AM, Peter Münster wrote:

Hello,

I would like to run a Dos program, that needs keyboard input (just one "Y"),
automatically via "make" in an ssh-session.

How could I simulate the "Y" keypress?

"echo Y | DosProgram.exe"
  does not work...

The keypress is accepted only in a dos-console.

TIA for any help!
Peter


Does "echo Y | DosProgram.exe" work in a cmd window?
If so it should be possible to do something like (untested)
cmd /c echo Y | pgm


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

Re: can't compile setup.exe

[Jon TURNEY]

On 02/09/2010 06:42, Andy Koppe wrote:

On 2 September 2010 05:18, Vasya Pupkin wrote:

I'm trying to compile setup.exe from source code I got from CVS.


Great!


For some reason, I am getting an error:

propsheet.cc: In member function `bool PropSheet::SetActivePage(int)':
propsheet.cc:444: error: expected id-expression before '::' token
propsheet.cc:444: error: expected `)' before '::' token
propsheet.cc:444: error: expected `;' before '::' token
propsheet.cc:444: error: expected `;' before ')' token
propsheet.cc: In member function `bool PropSheet::SetActivePageByID(int)':
propsheet.cc:452: error: expected id-expression before '::' token
propsheet.cc:452: error: expected `)' before '::' token
propsheet.cc:452: error: expected `;' before '::' token
propsheet.cc:452: error: expected `;' before ')' token
propsheet.cc: In member function `void PropSheet::SetButtons(DWORD)':
propsheet.cc:459: error: expected id-expression before '::' token
propsheet.cc:459: error: expected `;' before '::' token
propsheet.cc: In member function `void PropSheet::PressButton(int)':
propsheet.cc:465: error: expected id-expression before '::' token
propsheet.cc:465: error: expected `;' before '::' token
make[2]: *** [propsheet.o] Error 1

I did not touch this file. I installed all required packages and
followed instruction in README file.


Hmm, newly fails for me too, and I can't work out why, given that the
line in question is ancient code. I configured thusly:

./configure -C --disable-shared --host=i686-pc-mingw32
--build=i686-pc-cygwin CC="gcc-3 -mno-cygwin" CXX="g++-3 -mno-cygwin"


This was broken by the recent w32api-3.15 update, which seems to have made 
those PropSheet macros C++ aware, so the global scoping operator is no longer 
needed.


Patch attached to fix it, but I couldn't work out how to also get it to build 
with w32api-3.14.
Index: propsheet.cc
===
RCS file: /cvs/cygwin-apps/setup/propsheet.cc,v
retrieving revision 2.15
diff -u -r2.15 propsheet.cc
--- propsheet.cc30 Jun 2009 04:14:29 -  2.15
+++ propsheet.cc29 Aug 2010 09:51:13 -
@@ -441,7 +441,7 @@
 PropSheet::SetActivePage (int i)
 {
   // Posts a message to the message queue, so this won't block
-  return static_cast < bool > (::PropSheet_SetCurSel (GetHWND (), NULL, i));
+  return static_cast < bool > (PropSheet_SetCurSel (GetHWND (), NULL, i));
 }
 
 bool
@@ -449,18 +449,18 @@
 {
   // Posts a message to the message queue, so this won't block
   return static_cast < bool >
-(::PropSheet_SetCurSelByID (GetHWND (), resource_id));
+(PropSheet_SetCurSelByID (GetHWND (), resource_id));
 }
 
 void
 PropSheet::SetButtons (DWORD flags)
 {
   // Posts a message to the message queue, so this won't block
-  ::PropSheet_SetWizButtons (GetHWND (), flags);
+  PropSheet_SetWizButtons (GetHWND (), flags);
 }
 
 void
 PropSheet::PressButton (int button)
 {
-  ::PropSheet_PressButton (GetHWND (), button);
+  PropSheet_PressButton (GetHWND (), button);
 }
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: simulating console input

[Andrey Repin]

Greetings, Peter Munster!

> I would like to run a Dos program, that needs keyboard input (just one "Y"),
> automatically via "make" in an ssh-session.

> How could I simulate the "Y" keypress?

> "echo Y | DosProgram.exe" does not work...

> The keypress is accepted only in a dos-console.

If the program reading keyboard directly, you can't do it through IO
redirection.
Look for alternatives or write a replacement, that don't block execution.


--
WBR,
 Andrey Repin (anrdae...@freemail.ru) 02.09.2010, <15:06>

Sorry for my terrible english...


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

Re: difference running from cmd vs. bash?

[Csaba Raduly]

On Thu, Sep 2, 2010 at 2:14 AM, Linda Walsh  wrote:
> In Bash:
>>
>> winmgmt /verifyrepository
>
> WMI repository verification failed
> Error code:  0x8007007E

That is the COM error code for "The specified module could not be found".
Perhaps bash has altered the PATH.

Do you get the same error when running winmgmt without any parameters?
If yes, here's how to find out which DLL is not found:

cugcheck 'c:\Windows\System32\Wbem\winmgmt.exe'

This will give you a list of which DLLs are loaded and which ones are missing.


-- 
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

simulating console input

[Peter Münster]

Hello,

I would like to run a Dos program, that needs keyboard input (just one "Y"),
automatically via "make" in an ssh-session.

How could I simulate the "Y" keypress?

"echo Y | DosProgram.exe" does not work...

The keypress is accepted only in a dos-console.

TIA for any help!
Peter

-- 
Contact information: http://pmrb.free.fr/contact/



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

Re: chere not working with zsh version 4.3.10 but worked for 4.3.9

[Csaba Raduly]

Hi Reckoner,

"Does not work" is insufficient information about your problem. How
did it work before? What happens now? Did you get an error message? If
yes, what was it?

You should follow the procedure described in:

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

Also, you may want to read
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html


-- 
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Re: 1.7.[67]: getting bash prompt takes > 50 seconds

[Matthias Andree]

Am 02.09.2010, 04:30 Uhr, schrieb Mark Callow:




Hi Andrey,


Did you tried to *uninstall* bash-completion?

I have now. Surprisingly (to me) it worked. The time-to-prompt has
dropped to ~5 seconds on one of the machines and ~8 seconds on the
other. Both are still too long but a vast improvement over 50 seconds.


You can open a cmd.exe terminal window and type "bash --login -x" (or -xv)  
to figure if it spends a particularly long time in a certain area of the  
.bashrc execution, however, Cygwin is indeed a lot slower than Unix when  
shell scripting, because creating Unix processes is very costly in Cygwin,  
and that is an operation that happens a lot in shell scripts...


--
Matthias Andree

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