[ANNOUNCEMENT] Updated: sqlite3-3.8.3-2 for Cygwin/Cygwin64

[Jan Nijtmans]

SQLite is a software library that implements a self-contained,
serverless, zero-configuration, transactional SQL database engine

Changes since 3.8.2-3
=
* Updated to upstream 3.8.3 release. Main feature:
Added support for CTE (Common Table Expressions) and
Recursive Queries. For a complete list, see:
 
* Is compiled with SQLITE_ENABLE_SQLLOG enabled. See:
 
* New sub-package "sqlite3-tcl", containing the language
  bindings for Tcl 8.5/8.6

--
Jan Nijtmans

--
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: Maintainer for git?

[Corinna Vinschen]

On Feb  4 16:10, David Conrad wrote:
> On Wed, Jan 29, 2014 at 1:10 PM, Corinna Vinschen wrote:
> > On Jan 29 12:13, David Conrad wrote:
> >> On Wed, Jan 29, 2014 at 10:35 AM, Adam Dinwoodie wrote:
> >> > On Tue, Jan 28, 2014 at 12:11:02PM +0100, Corinna Vinschen wrote:
> >> >> Chris and I discussed this problem further and we applied a patch to the
> >> >> Cygwin DLL which saves and restores the FPU state and XMM registers on
> >> >> 32 bit as well when a thread gets interrupted for signal handling.
> >> >> . . .
> >> >> I'd be grateful if you could do some more testing as well.  Please
> >> >> revert your OpenSSL package to 1.0.1f-1 via setup, and then fetch the
> >> >> latest 2014-01-28 Cygwin snapshot DLL from http://cygwin.com/snapshots/,
> >> >> . . .
> >> >
> >> > I've just tested this -- the clone is failing ... with the current cygwin
> >> > package ... and working just fine with the 2014-01-28 snapshot. ...
> 
> Well, one way to test with the new Cygwin snapshot DLL is just to wait
> until it becomes the new release. :)
> 
> I just tested git cloning ffmpeg and linux, with Adam's git 1.8.5.2,
> on 32-bit Cygwin 1.7.28, and using the prior version of the OpenSSL
> package, 1.0.1f-1. It worked like a charm. 

Thanks for testing!

> I'm guessing the plan is to
> roll out a "new" OpenSSL package that is compiled with SSE2 enabled
> again, and to release the updated build of git?

Yes, that's the idea.  I'll do that in the next couple of days.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpI_aScwM3hc.pgp
Description: PGP signature

RE: cygwin64 - installation problem - installed by administrator account

[Flower, Martin]

Thank you Larry.

I have uninstalled GIT. I have deleted C:\cygwin64. I have rerun 
setup-x86_64.exe as admflma. In the start menu I click on the Cygwin icon and 
continue to have the same symptoms.

Windows cannot find mintty. I can browse for mintty.exe, and then nothing 
happens.

I open a command window and type C:\cygwin64\bin\mintty.exe and a shell window 
appears with prompt sh-4.15$

I have rebooted and there is no difference.

If the post-install scripts ran successfully, how would I know? I don't see any 
changes to my windows PATH environment.

Thanks for your help.

/Martin


-Original Message-
From: cygwin-owner
Sent: Tuesday, February 04, 2014 3:25 PM
To: cygwin 
Subject: Re: cygwin64 - installation problem - installed by administrator 
account

On 2/4/2014 2:43 AM, Flower, Martin wrote:
> C:\cygwin64\bin>cygcheck -srv > cygcheck.text
>
> C:\cygwin64>Cygwin.bat
> $ id
> uid=400(netflma) gid=401(mkpasswd) grupper=401(mkpasswd),555(Remote 
> Desktop Users),545(Users),10513(Domain Users)
>
> Hope this is what you have asked for.

Yes, thank you.  Looks like all the packages are installed OK.  My guess is 
that the post-install scripts didn't run properly because the GIT tools you 
have in your path took precedence over the Cygwin ones.  I'd suggest 
temporarily removing C:\Tools\Git\bin and C:\Tools\Git\cmd from your path, 
deleting C:\cygwin64, and rerunning setup.  See if that helps.

--
Larry

_

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


--
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 remount hotplugged USB drive as noacl (for use with rsync)?

[Corinna Vinschen]

On Feb  4 22:47, Marco Atzeri wrote:
> On 04/02/2014 22:41, carolus wrote:
> 
> >
> >>You're not remounting the Cygwin root.
> >
> >I'm confused by this statement. Isn't /cygdrive/c/cygwin/ the same as
> >Cygwin root?
> 
> YES

Uhm... no?

You have to look at this from the POSIX path angle.

"/" is not the same as "/cygdrive/c/cygwin", even if, under the hood,
they resolve to the same Windows path.  For every POSIX path, the mount
flags are taken from the matching fstab entry.  So, take two fstab
entries:

  C:/foo /bar some_fs binary 0 0
  C:/foo /baz some_fs text 0 0 

If you write to a file under /bar, it will be written in binary mode,
if you write to the exact same file under /baz, it will be written in
text mode:

  $ cd /bar
  $ echo Hallo > blub
  $ od -c blub
  000   H   e   l   l   o  \n
  006
  [~]$ cd /baz
  [~]$ echo Hello > blub
  [~]$ od -c blub
  000   H   e   l   l   o  \r  \n
  007

Does this example make it clearer?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpHXhiDsDnG_.pgp
Description: PGP signature

Re: How to remount hotplugged USB drive as noacl (for use with rsync)?

[Marco Atzeri]

On 05/02/2014 10:45, Corinna Vinschen wrote:

On Feb  4 22:47, Marco Atzeri wrote:

On 04/02/2014 22:41, carolus wrote:




You're not remounting the Cygwin root.


I'm confused by this statement. Isn't /cygdrive/c/cygwin/ the same as
Cygwin root?


YES


Uhm... no?

You have to look at this from the POSIX path angle.


so :
YES, it is the same content but it has a different
 view/access way than "/"

Better ?

Ciao
Marco


--
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 remount hotplugged USB drive as noacl (for use with rsync)?

[Corinna Vinschen]

On Feb  5 11:22, Marco Atzeri wrote:
> On 05/02/2014 10:45, Corinna Vinschen wrote:
> >On Feb  4 22:47, Marco Atzeri wrote:
> >>On 04/02/2014 22:41, carolus wrote:
> >>
> >>>
> You're not remounting the Cygwin root.
> >>>
> >>>I'm confused by this statement. Isn't /cygdrive/c/cygwin/ the same as
> >>>Cygwin root?
> >>
> >>YES
> >
> >Uhm... no?
> >
> >You have to look at this from the POSIX path angle.
> 
> so :
> YES, it is the same content but it has a different
>  view/access way than "/"
> 
> Better ?

We could agree on "it depends" ;)


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpm2uW4SEJ9B.pgp
Description: PGP signature

[ANNOUNCEMENT] Updated: postgresql-9.3.2-2

[Marco Atzeri]

Version 9.3.2-2  of packages

  libecpg-compat3
  libecpg-devel
  libecpg6
  libpgtypes3
  libpq-devel
  libpq5
  postgresql
  postgresql-client
  postgresql-contrib
  postgresql-devel
  postgresql-doc
  postgresql-plperl
  postgresql-plpython

are available in the Cygwin distribution:

CYGWIN CHANGES
- First Release of 9.3.x series.
- Patch for
  BUG #8970: ts_parse incorrectly split numbers in digit token
  http://www.postgresql.org/message-id/52ed7b2a.4010...@gmail.com
  is included. tsearch now works also for UTF8.

KNOWN BUG
- "set statement_timeout" does not work. See
   BUG #9074: prepared_xacts test freezes

http://www.postgresql.org/message-id/20140202181323.8089.65...@wrigleys.postgresql.org
   Investigation running, but is seems never worked for long time
   (Cygwin 1.7.7 time..)

CHANGES
Full upstream changes:
- http://www.postgresql.org/docs/9.3/static/release-9-3-2.html
- http://www.postgresql.org/about/news/1492/

ADVISE for major version UPGRADE
http://www.postgresql.org/support/versioning/

Major releases usually change the internal format of system tables
and data files. These changes are often complex, so we do not maintain
backward compatibility of all stored data. A dump/reload of the
database or use of the pg_upgrade module is required for major upgrades.


DESCRIPTION
PostgreSQL is a powerful, open source object-relational database system.
It has a proven architecture that has earned it a strong reputation for
reliability, data integrity, and correctness.
It is fully ACID compliant, has full support for foreign keys, joins, views,
triggers, and stored procedures (in multiple languages).
It includes most SQL:2008 data types

HOMEPAGE
http://www.postgresql.org

Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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


cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

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

http://sourceware.org/lists.html#unsubscribe-simple

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

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

[ANNOUNCEMENT] Updated: openssl-1.0.1f-3

[Corinna Vinschen]

I've updated the version of OpenSSL to 1.0.1f-3.


This reverts the SSE2 patch applied to 1.0.1f-2.  It's advisable to
update to 1.0.1f-3 only when also updating to Cygwin 1.7.28 which
contains a required patch to handle SSE2 in signal handing.

See http://cygwin.com/ml/cygwin-announce/2014-02/msg1.html


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: cygwin64 - installation problem - installed by administrator account

[Larry Hall (Cygwin)]

On 2/5/2014 4:38 AM, Flower, Martin wrote:

Thank you Larry.

I have uninstalled GIT. I have deleted C:\cygwin64. I have rerun
setup-x86_64.exe as admflma. In the start menu I click on the Cygwin icon
and continue to have the same symptoms.

Windows cannot find mintty. I can browse for mintty.exe, and then nothing
happens.

I open a command window and type C:\cygwin64\bin\mintty.exe and a shell
window appears with prompt sh-4.15$

I have rebooted and there is no difference.

If the post-install scripts ran successfully, how would I know? I don't
see any changes to my windows PATH environment.


The scripts live in /etc/postinstall.  Any that have run will have a
".done" suffix.  More importantly, any that haven't won't.  If you see
ones that haven't run, you can try running them manually from a bash
shell and see if that helps.  But really, even if some or all the
scripts have the ".done" suffix, it doesn't mean that they ran correctly.
It just means that they ran.  To determine if there were any problems
during the run, you need to find and look at the setup.log.full and/or
setup.log files.  These should reside in the directory you ran setup
from.  If there are complaints there about any post-install scripts,
then that's where you should focus your investigation.  setup should
have reported any post-install complaints to you at the end of the
install too.

You may also find that you're a victim of BLODA -
.  You can investigate this avenue as
well as something is clearly getting in the way of the post-install
script process.

--
Larry

_

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: using spawn functions to avoid fork() errors

[Larry Hall (Cygwin)]

On 2/5/2014 7:07 AM, Steven Bardwell wrote:

From reading the Cygwin FAQ ("In most cases, you are better off using the

spawn family of calls if possible.") and
the Cygwin Highlights ("Fortunately, in most circumstances the spawn family
of calls provided by Cygwin can be substituted for a fork/exec pair with
only a little effort."), it sounds like there exists a family of API calls
that may help me avoid the 'Resource temporarily unavailable' errors from 
calling
fork().

However, I can't find any documentation on these spawn functions. I recoded
my application to use
posix_spawn() but I am getting the same 'Resource temporarily unavailable'
error so I suspect that it
is using fork() as well.


posix_spawn() comes from newlib and uses vfork.  You can take a look
at the code on-line for more info:



An alternative that doesn't use fork was discussed here:



The code referenced isn't part of Cygwin and may or may not work.  I have
no experience with it.  If you choose to use it, forward your comments and
questions directly to the author.


I did try the 'rebaseall' process to remove the error, but without any
success. I also checked the BLODA list.

I have no problem doing some recoding of my application to reliably solve my
issues with fork() -- can you all
point me in the direction of the 'spawn family of calls'?


See spawn.cc -> 




--
Larry

_

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

A device driver as BLODA?

[Richard]

Hello All,

For weeks I've been pondering all the troubles I've had with setup, 
spurred by all the conversations that have happened recently about 
packaging, etc, and the occasional comments about BLODA. I have sometimes 
figured Cygwin's setup program is a member of BLODA - it certainly has 
been anything but reliable in my personal experience. And all too often 
it's between me and my enjoyment of Cygwin. (I maintain a fleet of Windows 
boxes with Cygwin, no two of which are identical.)


I've forgotten who wrote it, but I especially appreciated the email in my 
in-box this morning about how to tell when Cygwin installation scripts go 
wrong, where the list of scripts is, etc, because, frankly, when a Cygwin 
installation goes wrong (and when doesn't it?) I seldom have time to track 
down exactly why - I just try, try again, with different versions until it 
works or I give up and try another day. (One MAJOR headache here is the 
download process, no fixed starting point to know you got everything.) 
...And so it was this morning I decided to re-convince myself I didn't 
have any BLODA problems... MAYBE all those issues "weren't Cygwin's 
fault?"


I was surprised to find "ATI Catalyst", and even MORE surprised to find 
"NVIDIA GeForce" on the list, both as "some versions".


I haven't any idea why the Catalyst product would want to hook into things 
that would interfere with Cygwin, but I did have problems with it - it 
would crash the machine sometimes! - so I deleted it.


But the description, "NVIDIA GeForce" has me a bit confused because I 
thought that was the maker's name for a series of video cards (hardware) 
and possibly the device drivers that enable them to do magic things, like 
provide a display consisting of six monitors as my "desktop." ...I use 
this hardware! And, certainly, I use the NVIDIA drivers for it.


This raises two primary questions (and a few related ones):

1) How can I confirm I do or don't have an NVIDIA GeForce BLODA issue? (Is 
there really a device driver level issue?) And;


2) Might "we, the community" develop a BLODA-checker to help the 
installation process? I'm thinking that whenever a new item is discovered 
to put on the BLODA list, a small "here's how you know you have this 
software" script is written that could become a part of the Cygwin install 
process. There's already a script walker for scripts in a directory - 
maybe it could be harnessed to run a list of BLODA-checkers. Sure, there's 
a back-log of already known BLODA, most of which I have never even heard 
of before (probably not alone on that!), but if we can have scripts 
created on an on-going basis - say, when new BLODA are discovered and put 
on the list - eventually the backlog would get caught up...


Given all the complaints out there about the installation / setup process, 
I have to believe that I'm far from alone in thinking that there's likely 
a strong link between installation troubles and BLODA.


Regards,
Richard

--
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: A device driver as BLODA?

[Larry Hall (Cygwin)]

On 2/5/2014 12:39 PM, rich...@karmannghia.org wrote:


Hello All,

For weeks I've been pondering all the troubles I've had with setup, spurred
by all the conversations that have happened recently about packaging, etc,
and the occasional comments about BLODA. I have sometimes figured Cygwin's
setup program is a member of BLODA - it certainly has been anything but
reliable in my personal experience. And all too often it's between me and my
enjoyment of Cygwin. (I maintain a fleet of Windows boxes with Cygwin, no
two of which are identical.)

I've forgotten who wrote it, but I especially appreciated the email in my
in-box this morning about how to tell when Cygwin installation scripts go
wrong, where the list of scripts is, etc, because, frankly, when a Cygwin
installation goes wrong (and when doesn't it?) I seldom have time to track
down exactly why - I just try, try again, with different versions until it
works or I give up and try another day. (One MAJOR headache here is the
download process, no fixed starting point to know you got everything.)
...And so it was this morning I decided to re-convince myself I didn't have
any BLODA problems... MAYBE all those issues "weren't Cygwin's fault?"


Toiling in obscurity and the occasional vent here and at other outlets
is fine but if you're having some problems you can't figure out,
it could be worth your while to post specifics of your problem
and/or search the email archives for similar problems/solutions, ideas,
etc.  In addition, if you have allot of machines on which you've installed
Cygwin, you may have some interesting observations to report about the
kinds of problems you see on which OSs, mirrors, software versions, etc.
Your observations and details may be useful input for someone else searching
for a solution to the same problem.


I was surprised to find "ATI Catalyst", and even MORE surprised to find
"NVIDIA GeForce" on the list, both as "some versions".

I haven't any idea why the Catalyst product would want to hook into things
that would interfere with Cygwin, but I did have problems with it - it would
crash the machine sometimes! - so I deleted it.


Yes, this can be cranky and isn't a required install so it's often better
to just avoid it.


But the description, "NVIDIA GeForce" has me a bit confused because I
thought that was the maker's name for a series of video cards (hardware) and
possibly the device drivers that enable them to do magic things, like
provide a display consisting of six monitors as my "desktop." ...I use this
hardware! And, certainly, I use the NVIDIA drivers for it.

This raises two primary questions (and a few related ones):

1) How can I confirm I do or don't have an NVIDIA GeForce BLODA issue? (Is
there really a device driver level issue?) And;


If Cygwin is running and you're not seeing complaints (generally
fork-related) while you're using it, then it's a pretty good indication
that you don't have BLODA.  For more information on BLODA symptoms,
see the FAQ - .


2) Might "we, the community" develop a BLODA-checker to help the
installation process? I'm thinking that whenever a new item is discovered to
put on the BLODA list, a small "here's how you know you have this software"
script is written that could become a part of the Cygwin install process.
There's already a script walker for scripts in a directory - maybe it could
be harnessed to run a list of BLODA-checkers. Sure, there's a back-log of
already known BLODA, most of which I have never even heard of before
(probably not alone on that!), but if we can have scripts created on an
on-going basis - say, when new BLODA are discovered and put on the list -
eventually the backlog would get caught up...


This is a very fluid area as the list of software that can cause these
problems varies over time.  Generally speaking, the list contains apps
that are installed on the system and show up in the Windows list of
installed apps (i.e. "Add/Remove Programs" or "Programs and Features").
But I'm certain no one would object to someone supplementing the current
list with more information and/or utilities to make this all easier for
users that run across this issue.  Ideally, we'd really like it if this
list would shrink and disappear but I doubt we're going to see that.


Given all the complaints out there about the installation / setup process, I
have to believe that I'm far from alone in thinking that there's likely a
strong link between installation troubles and BLODA.


Certainly if there is BLODA on your system, the installation process has the
potential to trip over it because there are scripts run as part of the
process that use Cygwin utilities.  In addition, there's the potential
problem of DLL address-space collisions which becomes more noticeable as
the number of packages you install grows.  The symptoms of this are similar
(see ),
particularly in an instal

Re: Newbie Questions

[Mike Rushton]

Thanks for all the help.

What I am trying to do is convert some Korn Shell scripts to bash to run 
under Cygwin.


I am wondering,  does cygwin have a preferred extension for scripts ?  
It  probably does not matter.   Some of the scripts had .ksh on the end 
of them.

I want to make everything uniform now that I am moving to Cygwin.






On 2/4/2014 3:55 PM, Marco Atzeri wrote:



On 04/02/2014 20:19, mrushton wrote:

I am loving Cygwin.

I have been reading the manuals and documentation and have some 
newbie questions.



1)  When I go to execute a script, do I just type the name of it or 
do i have to do a ./NameOfScript ?


just the name if it is located in one of the PATH directories as any 
other command. instead "./NameOfScript" if you want to execute a 
script or a command not in the PATH


For your own script " ~/bin" is a nice location

This is a generic Unix FAQ.


2)  I am trying to do an Alias of the Clear Command ... in my bashrc 
I has an alias for clear to do a printf "\033c".   Well it does not 
seem to work from my scripts, but works from shell prompt.

Is this a path issue ?


How you call the script ?

See on "info bash" at "6.2 Bash Startup Files"


3)  I am still trying to figure out how to open a termial window and 
have a menu script always run.

Should I put this in my .profile or is there a better way to do this ?


Do you need a standalone run, so the terminal close after, or you need 
to drop to bash after the script ?


Your solution is fine for the second case, while on the first
you need to adapt the

"mintty.exe /bin/bash -l" to "mintty.exe /bin/bash -C yourscript"



Thanks for all the work of the Cygwin team.



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

[Larry Hall (Cygwin)]

On 2/5/2014 1:25 PM, Mike Rushton wrote:

Thanks for all the help.

What I am trying to do is convert some Korn Shell scripts to bash to run
under Cygwin.

I am wondering,  does cygwin have a preferred extension for scripts ? It
probably does not matter.   Some of the scripts had .ksh on the end of them.
I want to make everything uniform now that I am moving to Cygwin.


No, the extension can be whatever you like.  By convention, bash/sh scripts
with extensions use ".sh".


--
Larry

_

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

Cygwin SSH and msysGit

[Someone Somebody]

I managed to get cygwin SSH working configured to run as SYSTEM and
cyglsa installed. And now I want to setup so I can use Git push/pull
over ssh.

The problem is that to use msysGit I would have to add it's "bin" and
"libexec/git" directories to the PATH. But this also adds various
command binaries which override the native cygwin one's, which are
obviously much more up-to-date and work better inside cygwin.

I can try and use Cygwin's Git but I'm not sure if it will inter
operate correctly with msysGit clones.

So my questions are:
1. Can Cygwin's Git inter operate with a clone from msysGit? at least
for push/pull purposes?
2. Is there a way so that msysGit can be integrated into a Cygwin
environment without disturbing Cygwin's command binaries or Cygwin's
binaries interfering with msysGit?

Thanks.

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

[Warren Young]

On 2/5/2014 11:30, Larry Hall (Cygwin) wrote:

On 2/5/2014 1:25 PM, Mike Rushton wrote:

does cygwin have a preferred extension for scripts ?


No, the extension can be whatever you like.  By convention, bash/sh scripts
with extensions use ".sh".


I'd bet there are more Bourne shell scripts in the world with no 
extension at all than .sh.


For the most part, Mike, POSIXy systems like Cygwin and Linux use magic 
bytes[1] and the shebang line[2] to figure out what is contained in a 
given file, rather than the file name.



[1] http://goo.gl/5F9P33
[2] http://goo.gl/XjINSi


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

[Warren Young]

On 2/5/2014 14:17, Warren Young wrote:


I'd bet there are more Bourne shell scripts in the world with no
extension at all than .sh.


That said, if you're wanting to be able to double-click on a shell 
script icon in Windows and associate that with Cygwin's bash.exe, you 
*will* need to pick a file name extension, since that's how Windows 
determines what's in a file.


.sh is indeed the standard choice when you must use a file extension for 
a Bourne shell script, for whatever reason.


These two features can interact in odd ways.

Say you have a Perl script, which you have misleadingly named foo.sh. 
From a bash shell, you type:


$ ./foo.sh

The Perl script will run as intended, despite the name.

But if you associate .sh with bash.exe, then double-click that script 
from Windows Explorer, it won't work right, since bash.exe will try to 
run it as a shell script.  Perl isn't close enough in syntax to Bourne 
shell for this to work for anything but trivial (or very tricky!) scripts.


What you've done here is substitute Windows Explorer for exec(), so you 
don't get the shebang handling built into exec().


--
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 big are your /etc/passwd and /etc/group files?

[Andrey Repin]

Greetings, Linda Walsh!

> 11612288(High Mandatory Level)
>> 
>>> The security levels are mostly for informational / interest  purposes...
>> 
>>> Maybe they might be added to cygwin if it is going to substitute it's own
>>> internal DB?
>> 
>> As I understand it, these groups/names will be retrieved directly from system
>> as the need arise.
> ---

> Sorta -- If you don't have them listed in your group file then
> they won't be listed when you type 'id'.

> They'll still be part of your credential -- just not listed...

> that's why I said it was mostly for informational/interest purposes...

> That way I can know what 'trust' level I am logged in with.

I was talking the case of NOT using groups/passwd files.
Also look at Corinna's answer http://cygwin.com/ml/cygwin/2014-02/msg00038.html


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <01:25>

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

[Mike Rushton]

Right ... the extension is a windows thing.

Most of the bourne shell scripts i have come across have no extension.
Some have the Shebang line ... while others don't have it.

I am still in the planing stages ... I am not sure if I am going to use 
an extension or not.


It might be a good idea to use .sh and then you would know that it is a 
script.






On 2/5/2014 4:17 PM, Warren Young wrote:

On 2/5/2014 11:30, Larry Hall (Cygwin) wrote:

On 2/5/2014 1:25 PM, Mike Rushton wrote:

does cygwin have a preferred extension for scripts ?


No, the extension can be whatever you like.  By convention, bash/sh 
scripts

with extensions use ".sh".


I'd bet there are more Bourne shell scripts in the world with no 
extension at all than .sh.


For the most part, Mike, POSIXy systems like Cygwin and Linux use 
magic bytes[1] and the shebang line[2] to figure out what is contained 
in a given file, rather than the file name.



[1] http://goo.gl/5F9P33
[2] http://goo.gl/XjINSi


--
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: Cygwin SSH and msysGit

[Andrey Repin]

Greetings, Someone Somebody!

> I managed to get cygwin SSH working configured to run as SYSTEM and
> cyglsa installed. And now I want to setup so I can use Git push/pull
> over ssh.

> The problem is that to use msysGit I would have to add it's "bin" and
> "libexec/git" directories to the PATH. But this also adds various
> command binaries which override the native cygwin one's, which are
> obviously much more up-to-date and work better inside cygwin.

> I can try and use Cygwin's Git but I'm not sure if it will inter
> operate correctly with msysGit clones.

> So my questions are:
> 1. Can Cygwin's Git inter operate with a clone from msysGit? at least
> for push/pull purposes?

I have no extensive knowledge of git, but assuming it doesn't do retarded
things, like writing OS-dependent text files in service areas, I don't see,
why not.

> 2. Is there a way so that msysGit can be integrated into a Cygwin
> environment without disturbing Cygwin's command binaries or Cygwin's
> binaries interfering with msysGit?

Assuming, you do NOT have Cygwin git installed, you can add MSYS's dirs after
cygwin in $PATH.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <01:37>

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

[Andrey Repin]

Greetings, Warren Young!

>>> does cygwin have a preferred extension for scripts ?
>>
>> No, the extension can be whatever you like.  By convention, bash/sh scripts
>> with extensions use ".sh".

> I'd bet there are more Bourne shell scripts in the world with no 
> extension at all than .sh.

If you read his reply carefully, you will notice he explicitly stated "with
extension"...

> For the most part, Mike, POSIXy systems like Cygwin and Linux use magic 
> bytes[1] and the shebang line[2] to figure out what is contained in a 
> given file, rather than the file name.


> [1] http://goo.gl/5F9P33
> [2] http://goo.gl/XjINSi


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <02:01>

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

[Andrey Repin]

Greetings, Mike Rushton!

> Right ... the extension is a windows thing.

Not really. It's a human thing, that let you tell the intended meaning of the
file at a glance.

> Most of the bourne shell scripts i have come across have no extension.
> Some have the Shebang line ... while others don't have it.

Ones that not have it are scripts not intended for direct invocation (like
these normally residing in /etc/default/*)

> I am still in the planing stages ... I am not sure if I am going to use 
> an extension or not.

> It might be a good idea to use .sh and then you would know that it is a 
> script.

I'm using this little wrapper to start scripts by shebang line.

-->8>8>8>8>8>8>8--
C:\Programs\CygWin\bin\cygwrap.sh
#! /bin/sh
if [ -z "$1" ]; then
  echo "No command given, breaking off." 1>&2
  exit 1
fi

CMDNAME="$( cygpath -au "$1")"
shift

env "$CMDNAME" $*
-->8>8>8>8>8>8>8--

along with association

$ assoc .pl
.pl=unixshell.script

$ assoc .sh
.sh=unixshell.script

(etc.)

$ ftype unixshell.script
unixshell.script="C:\Programs\Cygwin\bin\env.exe" /bin/cygwrap.sh "%1" %*


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <02:08>

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

[Andrey Repin]

Greetings, Warren Young!

> On 2/5/2014 14:17, Warren Young wrote:
>>
>> I'd bet there are more Bourne shell scripts in the world with no
>> extension at all than .sh.

> That said, if you're wanting to be able to double-click on a shell 
> script icon in Windows and associate that with Cygwin's bash.exe, you 
> *will* need to pick a file name extension, since that's how Windows 
> determines what's in a file.

Not necessarily. Especially not, when using ShellExecute(Ex)?...

> .sh is indeed the standard choice when you must use a file extension for 
> a Bourne shell script, for whatever reason.

> These two features can interact in odd ways.

> Say you have a Perl script, which you have misleadingly named foo.sh. 
>  From a bash shell, you type:

> $ ./foo.sh

> The Perl script will run as intended, despite the name.

> But if you associate .sh with bash.exe, then double-click that script 
> from Windows Explorer, it won't work right, since bash.exe will try to 
> run it as a shell script.

Have you actually tried that?
Try it, you'll be surprised.

> Perl isn't close enough in syntax to Bourne shell for this to work for
> anything but trivial (or very tricky!) scripts. 

> What you've done here is substitute Windows Explorer for exec(), so you
> don't get the shebang handling built into exec().

Try it yourself... you'll be surprised.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <02:02>

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

[Andrey Repin]

Greetings, Andrey Repin!

>>> I'd bet there are more Bourne shell scripts in the world with no
>>> extension at all than .sh.

>> That said, if you're wanting to be able to double-click on a shell 
>> script icon in Windows and associate that with Cygwin's bash.exe, you 
>> *will* need to pick a file name extension, since that's how Windows 
>> determines what's in a file.

> Not necessarily. Especially not, when using ShellExecute(Ex)?...

-ShellExecute
+CreateProcess

Sorry.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <02:21>

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

[Warren Young]

On 2/5/2014 15:07, Andrey Repin wrote:



But if you associate .sh with bash.exe, then double-click that script
from Windows Explorer, it won't work right, since bash.exe will try to
run it as a shell script.


Have you actually tried that?


Yep.


Try it, you'll be surprised.


I did try it, before sending the previous message pair.

Save the attached file as foo.sh, then run it with "bash foo.sh", rather 
than "./foo.sh".  This is what happens when you associate *.sh with 
bash.exe in Windows Explorer.


Bash tries to interpret the file as a shell script, despite the shebang 
line.  This is because Bash doesn't do the shebang handling, exec() 
does, and Bash treats passed file names as names of shell scripts.  It 
runs them directly, not through exec().


When you say "bash foo.sh" on the attached file, it complains:

foo.sh: line 2: use: command not found
Unable to initialize device PRN

Then it sleeps for 2 seconds, since Bash and Perl both interpret line 4 
the same way, if you ignore the minor semantic difference ";\n" makes to 
Bash.


There is one small but critical difference in behavior when you do this 
by double-clicking foo.sh from Windows Explorer, with *.sh associated 
with Cygwin's bash.exe.  That is, it only pauses on line 4 if your 
Cygwin bin directory is in the Windows system PATH, since otherwise, 
bash.exe can't find sleep.exe.


Instead of adding Cygwin's bin directory to the Windows PATH, you can 
fix this with a minor registry hack.  Open


HKCU\Software\Classes\sh_auto_file\shell\open\command

Change the default value to something like:

"C:\cygwin32\bin\bash.exe" -l "%1"

Adjust c:\cygwin32 as needed.

This makes bash.exe a login shell, which forces it to run its startup 
scripts before running the script passed to it, so PATH gets set the 
same way it does for an interactive shell.


This doesn't make bash.exe send foo.sh to perl.exe, though.  To do that, 
you have to change the key's default value to:


"C:\cygwin32\bin\bash.exe" -l -c 'exec `cygpath -u "%1"`'

A registry hack that involves triply-nested quotes seems like a long way 
to go to make Windows Explorer run files the same way Bash would 
interactively.


Plus, it only helps when you're attempting to deceive Bash.

My motto: Don't lie to computers; they find ways to get even.


foo.sh
Description: application/shellscript
--
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: Newbie Questions

[Andrey Repin]

Greetings, Warren Young!

> On 2/5/2014 15:07, Andrey Repin wrote:
>>
>>> But if you associate .sh with bash.exe, then double-click that script
>>> from Windows Explorer, it won't work right, since bash.exe will try to
>>> run it as a shell script.
>>
>> Have you actually tried that?

> Yep.

>> Try it, you'll be surprised.

> I did try it, before sending the previous message pair.

> Save the attached file as foo.sh, then run it with "bash foo.sh", rather 
> than "./foo.sh".  This is what happens when you associate *.sh with 
> bash.exe in Windows Explorer.

[C:\home\Daemon]$ bash -c ./foo.sh
Hello from Perl!

[C:\home\Daemon]$

> Bash tries to interpret the file as a shell script, despite the shebang 
> line.  This is because Bash doesn't do the shebang handling, exec() 
> does, and Bash treats passed file names as names of shell scripts.  It 
> runs them directly, not through exec().

Perhaps, we have different bash'es...


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 06.02.2014, <04:54>

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

[Warren Young]

On 2/5/2014 18:00, Andrey Repin wrote:


[C:\home\Daemon]$ bash -c ./foo.sh


That's not the same command I gave you.  -c changes how bash.exe 
interprets the following parameter.


It matters, because when you right-click a *.sh file in Windows 
Explorer, say Open With, then tell Explorer to use bash.exe to open such 
files now and in the future, it isn't going to stick -c in the command 
for you.


If you did change the file association in the registry, adding -c, that 
still isn't going to help because Windows Explorer is going to pass the 
full Windows-style path to bash.exe in place of the %1.  Plus you still 
have the PATH issues I brought up in my previous 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: cygwin64 - installation problem - installed by administrator account

[Flower, Martin]

The scripts live in /etc/postinstall.  Any that have run will have a ".done" 
suffix.  More importantly, any that haven't won't.  If you see ones that 
haven't run, you can try running them manually from a bash shell and see if 
that helps.  But really, even if some or all the scripts have the ".done" 
suffix, it doesn't mean that they ran correctly.
It just means that they ran.  To determine if there were any problems during 
the run, you need to find and look at the setup.log.full and/or setup.log 
files.  These should reside in the directory you ran setup from.  If there are 
complaints there about any post-install scripts, then that's where you should 
focus your investigation.  setup should have reported any post-install 
complaints to you at the end of the install too.

You may also find that you're a victim of BLODA - 
.  You can investigate this avenue as well 
as something is clearly getting in the way of the post-install script process.

--
Larry

===

Thank you Larry

All scripts have .done.

Setup.log.full shows an error. I see the word McShield, and I link it to BLODA. 
File C:\cygwin64\etc\setup\setup.rc exists - although I assume it didn't exist 
when setup was started.

2014/02/05 10:05:28 Starting cygwin install, version 2.831
2014/02/05 10:05:28 User has backup/restore rights
2014/02/05 10:05:28 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed 2 No 
such file or directory
2014/02/05 10:05:28 Current Directory: C:\Users\netflma\Downloads
2014/02/05 10:05:28 Could not open service McShield for query, start and stop. 
McAfee may not be installed, or we don't have access.
2014/02/05 10:05:38 source: network install
2014/02/05 10:05:42 source: download
2014/02/05 10:05:51 source: download
2014/02/05 10:05:52 Selected local directory: C:\Users\netflma\Downloads
2014/02/05 10:06:20 net: Proxy
Cached mirror list unavailable
get_url_to_membuf http://cygwin.com/mirrors.lst
getUrlToStream http://cygwin.com/mirrors.lst
2014/02/05 10:06:22 Ending cygwin install

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

cygwin-1.7.28 getpwent header declaration changes ?

[Marco Atzeri]

on cygwin-1.7.28 64 bit but not on cygwin-1.7.27,
(only system difference) compiling octave I see:


/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
:114:25: error: '::getpwent' has not been declared
   return octave_passwd (::getpwent (), msg);
 ^
/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
: In static member function 'static int 
octave_passwd::setpwent(std::string&)':

/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
:171:3: error: '::setpwent' has not been declared
   ::setpwent ();
   ^
/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
: In static member function 'static int 
octave_passwd::endpwent(std::string&)':

/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
:191:3: error: '::endpwent' has not been declared
   ::endpwent ();
   ^
/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
: In static member function 'static octave_passwd 
octave_passwd::getpwent(std::s

tring&)':
/pub/devel/octave/octave-3.8.0-2/src/octave-3.8.0/liboctave/system/oct-passwd.cc
:119:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
Makefile:8702: recipe for target 
'system/system_libsystem_la-oct-passwd.lo' fail

ed
make[4]: *** [system/system_libsystem_la-oct-passwd.lo] Error 1



the piece of code is a very simple:
---
octave_passwd
octave_passwd::getpwent (std::string& msg)
{
#if defined HAVE_GETPWENT
  msg = std::string ();
  return octave_passwd (::getpwent (), msg);
#else
  msg = NOT_SUPPORTED ("getpwent");
  return octave_passwd ();
#endif
}



Is something slightly changed in the  relative system headers ?

Regards
Marco


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