Re: GIT

[Christopher Faylor]

Everyone:
Maybe it isn't clear but, with the exception of newlib, the rest of the
repository in which Cygwin used to reside has moved to git.  Cygwin is
moving too, soon.  I actually had planned on doing this last year before
Corinna asked me to stop (it was apparently going to impact the x86_64
port).  I can't use the git repo that I had built then because I had
changed the configury in a way that is now incompatible with what's in
CVS.

So, I already have a little experience using git and making the
conversion.  And, given the number of people who are not contributing to
the project (see previous discussion) I don't think we have to worry too
much about Cygwin CVS diehards besides Corinna.

Please don't get carried away with offering alternatives to git,
expressing dislike of git, or telling stories about your use of git.  I
don't see how any of that is really useful until Cygwin makes the move.

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

[Achim Gratz]

Andrey Repin writes:
> This is exactly what makes me dislike it strongly. This, and idiotic model of
> copying whole repository to my machine, when I only want to glance at the
> source code, and find the culprit of my current issues.
[…]

You might want to learn about shallow clones, but unless you really have
a slow or metered internet connection it's usually not worth the
trouble.  By the time you found the culprit of your current issues you
are asking yourself "how did it get there?" and at that point you'll
want the history anyway.

> And "fine control" doesn't mix with "project consistency" at all.

Eh?

> Subversion is aimed at versioning of a whole project, in a supposedly
> consistent state at each version. What can be more "fine" than this, is beyond
> my understanding.
> You can still commit separate files from working copy, though, but this
> practice is discouraged for the greater good of the project you develop.

I don't think you can comment on things you don't seem to have tried in
earnest.  Yes, Git doesn't come with a canned workflow in the same way
that SVN does.  That's a good thing in my book, but there's no shortage
of writeups on how to mimic different workflows in Git if you want to do
that.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: GIT (was: Coverity Scan)

[Duncan Roe]

On Sat, Apr 26, 2014 at 08:42:34AM +0800, JonY wrote:
> On 4/26/2014 07:27, Andrey Repin wrote:
> > This is exactly what makes me dislike it strongly. This, and idiotic model 
> > of
> > copying whole repository to my machine, when I only want to glance at the
> > source code, and find the culprit of my current issues.
> > I've spent 3 hours downloading a 200Mb repo of a project, where the 
> > Subversion
> > client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what 
> > an
> > idiotic weight I pulled and went to google to see if it can be done better.
> > And "fine control" doesn't mix with "project consistency" at all.
> > Subversion is aimed at versioning of a whole project, in a supposedly
> > consistent state at each version. What can be more "fine" than this, is 
> > beyond
> > my understanding.
>
> git clone --depth 1 if you don't care about history.
>
> > You can still commit separate files from working copy, though, but this
> > practice is discouraged for the greater good of the project you develop.
> >
>
> Don't you need to git add individual files to mark for commit? Won't you
> get into the same problems if you forgot to commit files in SVN?
>
>
>
"git commit -a" commits modified files without the need to add them first.
You always have to add new files.

--
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: GIT (was: Coverity Scan)

[JonY]

On 4/26/2014 07:27, Andrey Repin wrote:
> This is exactly what makes me dislike it strongly. This, and idiotic model of
> copying whole repository to my machine, when I only want to glance at the
> source code, and find the culprit of my current issues.
> I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
> client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
> idiotic weight I pulled and went to google to see if it can be done better.
> And "fine control" doesn't mix with "project consistency" at all.
> Subversion is aimed at versioning of a whole project, in a supposedly
> consistent state at each version. What can be more "fine" than this, is beyond
> my understanding.

git clone --depth 1 if you don't care about history.

> You can still commit separate files from working copy, though, but this
> practice is discouraged for the greater good of the project you develop.
> 

Don't you need to git add individual files to mark for commit? Won't you
get into the same problems if you forgot to commit files in SVN?





signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: vim-7.4.264-1

[Yaakov (Cygwin/X)]

The following packages have been updated in the Cygwin distribution:

*** vim-7.4.264-1
*** vim-common-7.4.264-1
*** vim-minimal-7.4.264-1
*** xxd-7.4.264-1
*** gvim-7.4.264-1

Vim is an advanced text editor that seeks to provide the power of the 
de-facto Unix editor 'Vi', with a more complete feature set and a choice 
of terminal and GTK+ interfaces.


This is an update to the most recent upstream patchset.

--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then 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: curl-7.36.0-1

[Yaakov (Cygwin/X)]

The following packages have been updated for both arches:

* curl-7.36.0-1
* libcurl4-7.36.0-1
* libcurl-devel-7.36.0-1
* libcurl-doc-7.36.0-1

cURL is a library and command line tool for transferring data with URL 
syntax, supporting numerous protocols, SSL certificates, HTTP POST, HTTP 
PUT, FTP uploading, HTTP form based upload, proxies, cookies, 
user+password authentication, file transfer resume, proxy tunneling and 
more.


This is an update to the latest upstream release, which includes fixes 
for CVE-2014-0138 and CVE-2014-0139.


--

Yaakov
Cygwin/X


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then 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: check-0.9.12-1

[Yaakov (Cygwin/X)]

The following package has been updated for the Cygwin distribution:

* check-0.9.12-1

Check is a unit test framework for C.

This is an update to the latest upstream version.


Yaakov


CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


If you want to unsubscribe from the cygwin-announce mailing list, please
use the automated form at:

http://cygwin.com/lists.html#subscribe-unsubscribe

If this does not work, then 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

Re: GIT (was: Coverity Scan)

[Andrey Repin]

Greetings, Jim Garrison!

>> -Original Message-
>> Corinna Vinschen
>> Sent: Friday, April 25, 2014 6:33 AM
>> > >>  There have been a few hints on this list about a possible move
>> > >> from CVS  to git. If such a move were on the cards then that should
>> > >> probably  happen first - I wouldn't want the nugatory effort of
>> > >> getting this  working from CVS only to have to change it almost
>> immediately.
>> > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
>> > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > >Teeth-gnashingly.

> I recently went through the same reluctant switch to Git from SVN.

> I can tell you from personal experience that there's a period of
> disorientation when even the simplest tasks require a quick trip to Google.
> And Git requires a major shift in your mental model of how things work.
> Instead of 2 places where stuff is (local and remote) there are now 4
> (workspace, stage, local repo, remote repo).

> HOWEVER... once you get over the learning hump you see that Git is MUCH
> better and allows much finer control over what's happening.

This is exactly what makes me dislike it strongly. This, and idiotic model of
copying whole repository to my machine, when I only want to glance at the
source code, and find the culprit of my current issues.
I've spent 3 hours downloading a 200Mb repo of a project, where the Subversion
client pulled 4 or 5Mb HEAD of it in like 10 minutes, once I realized what an
idiotic weight I pulled and went to google to see if it can be done better.
And "fine control" doesn't mix with "project consistency" at all.
Subversion is aimed at versioning of a whole project, in a supposedly
consistent state at each version. What can be more "fine" than this, is beyond
my understanding.
You can still commit separate files from working copy, though, but this
practice is discouraged for the greater good of the project you develop.

> Plus, the online documentation is very good, and questions have been asked
> enough times that Google serves up good answers to just about any question.
> If you have Cygwin/X installed, the "git gui" and "gitk" tools will make the
> transition easier.

> I started learning Git in earnest back in December, and really started
> "thinking in Git" soon after.  Now, if I had to go back I would be
> disappointed.  


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 26.04.2014, <03:19>

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: How LANG environment variable is set?

[Andrey Repin]

Greetings, Larry Hall (Cygwin)!

>> It looks like /etc/profile sets LC_ALL=C before running the scripts
>> in /etc/profile.d, then restores it to its original setting. This
>> prevents LANG getting set by lang.sh.
>>

> Good catch.  Yes, the latest version of base_files makes this change to
> the profile_d() function.  Looks like the easiest interim solution is to
> downgrade to base_files-4.1-2.

Actually, it might help to set LANG in user's profile instead.
I have this bit of code, working quite well:

case "$TERM" in
  xterm*)
LANG=ru_RU.UTF-8
;;
  *)
LANG=ru_RU.CP866
;;
esac

(mintty sets "xterm", so does xterm itself and other shells I connect to this
system with.)


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 26.04.2014, <03:11>

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: default shell

[Andrey Repin]

Greetings, Dawid Ferenczy!

>it's not a big deal, I just wonder what to execute, if I would like to
> execute user's default shell (defined in /etc/passwd). For example in 
> cmd.exe, 
> ConEmu or Console2. I don't want to hardcode a shell anywhere (in console 
> emulator configuration, some batch file etc.), I just want to auto detect 
> user's default shell and execute it. If it's possible :) Exactly the same 
> what 
> does mintty.

The answer depends on what you actually trying to do.
Else, there's no simple answer. Default "default" shell is bash, but user can
pick any other, and mintty does some trickery to find it out.
You can try something like

USERSHELL=$( XXX=$( getent passwd $USER ) echo ${XXX##*:} )

but there's no easy equivalent for *NIX scripting in CMD, that does this.
Soo back to the original question. What you are trying to do, for what
mintty isn't sufficient?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 26.04.2014, <03:00>

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: 64-bit vs. 32-bit

[Chris J. Breisch]

Warren Young wrote:

On 4/25/2014 11:26, Tom Szczesny wrote:


CYGWIN_NT-6.1-WOW64


"WOW64" means 32-bit Windows emulated on top of 64-bit Windows.[1] This
tells you that Cygwin is running inside that 32-bit environment.


[snip]

You don't have to guess and hope, though. From 32-bit Cygwin:

$ file /bin/ls
/bin/ls: PE32 executable (console) Intel 80386 (stripped to external
PDB), for MS Windows

$ file /cygdrive/c/cygwin64/bin/ls
/cygdrive/c/cygwin64/bin/ls: PE32+ executable (console) x86-64, for MS
Windows

file(1) saith sooth what what form of executable thou hast wrought.

You might also find this piece enlightening: http://goo.gl/qv5ki7




That is enlightening. I have a rather different, and very non-standard 
setup, making use of $PROCESSOR_ARCHITECTURE. This environment variable 
is set in both 32-bit and 64-bit Cygwin. In the former, it's set to 
"x86" and in the latter, it's set to "AMD64".


So, I have my 64-bit Cygwin root set to C:/cygwin/AMD64, and my 32-bit 
Cygwin root set to C:/cygwin/x86. My package root for both is 
C:\cygwin\packages, and I have /home in both environments mounted on 
C:/cygwin/home.


I script all my builds, and the script I use sets the build directory 
always to build_${PROCESSOR_ARCHITECTURE}. In a similar way, my output 
files are named things like configure_${PROCESSOR_ARCHITECTURE}.out, 
make_${PROCESSOR_ARCHITECTURE}.out, etc.


But, as you mention in your SO response, I'd never dream of sharing 
/usr/local this way.


Oh, finally, I set the title of my mintty or xterm to contain 
${PROCESSOR_ARCHITECTURE} as well, so I don't forget where I am.


--
Chris J. Breisch

--
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: perl-Text-CSV_XS-1.06-1

[David Stacey]

Version 1.06-1 of perl-Text-CSV_XS has been uploaded.

CHANGE LOG
==

1.06- 2014-04-20, H.Merijn Brand
- Fix possible fail in tests on Windows (Thanks Mithaldu for
explaing)
- Only close file handles in csv () for files
- new callbacks for csv ()


DESCRIPTION
===

Text::CSV_XS provides facilities for the composition and decomposition
of comma-separated values. An instance of the Text::CSV_XS class will
combine fields into a CSV string and parse a CSV string into fields.

The module accepts either strings or files as input and support the use
of user-specified characters for delimiters, separators, and escapes.


CPAN


http://search.cpan.org/~hmbrand/Text-CSV_XS/CSV_XS.pm


Cheers,

Dave.



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

Re: 64-bit vs. 32-bit

[Warren Young]

On 4/25/2014 11:26, Tom Szczesny wrote:


CYGWIN_NT-6.1-WOW64


"WOW64" means 32-bit Windows emulated on top of 64-bit Windows.[1]  This 
tells you that Cygwin is running inside that 32-bit environment.



If I did install the 64-bit version, when I rebuild my Linux app on
Cygwin, do I automatically get a 64-bit executable (that will not run
on a 32-bit Windows computer)?


You actually have to go out of your way to get a 32-bit executable when 
running 64-bit Cygwin, and vice versa.  So yes, if you install 64-bit 
Cygwin, you don't have to worry about accidentally getting 32-bit 
executables.


You don't have to guess and hope, though.  From 32-bit Cygwin:

$ file /bin/ls
/bin/ls: PE32 executable (console) Intel 80386 (stripped to 
external PDB), for MS Windows


$ file /cygdrive/c/cygwin64/bin/ls
/cygdrive/c/cygwin64/bin/ls: PE32+ executable (console) x86-64, for 
MS Windows


file(1) saith sooth what what form of executable thou hast wrought.

You might also find this piece enlightening: http://goo.gl/qv5ki7



[1] http://goo.gl/uGmKYv

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

[Achim Gratz]

Corinna Vinschen writes:
>> > > >Yeah, I'm not exactly looking forward to it since I'm very familiar
>> > > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > > >Teeth-gnashingly.
>
> Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/

My recommendation for newcomers to Git would be to take any
not-too-large Git repository(*) and work out a few dozen ways of
breaking it; then freshly clone it to start over once you've thoroughly
messed it up.  Once you've done that a few times and maybe know how to
recover from a few less catastrophic sins (like resetting to where you
didn't want to be and then finding out where the former branch head
was), you should have a good base for deciding what kind of workflow
works for you and Git alike.  The thing that Git gets right is that it's
incredibly cheap to make yet another clone or branch for when you want
to try something even remotely risky.


(*) http://repo.or.cz/r/cygwin-setup.git perhaps?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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: GIT (was: Coverity Scan)

[Reini Urban]

On Fri, Apr 25, 2014 at 11:22 AM, Corinna Vinschen wrote:
> On Apr 25 15:24, Jim Garrison wrote:
>> > Corinna Vinschen
>> > > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
>> > > >with CVS or SVN, but have nothing but trouble with git.  But since
>> > > >everybody else is so very happy with git, I guess I'll have to adapt.
>> > > >Teeth-gnashingly.
>>
>> I recently went through the same reluctant switch to Git from SVN.
>>
>> I can tell you from personal experience that there's a period of 
>> disorientation when even the simplest tasks require a quick trip to Google.  
>> And Git requires a major shift in your mental model of how things work. 
>> Instead of 2 places where stuff is (local and remote) there are now 4 
>> (workspace, stage, local repo, remote repo).
...
> Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/

Only experience helps.
I needed about a year to not loose too much changes after the switch
from svn to git, but feeling very happy now.
It helps having backups for the beginning if you try out rebase or
reset --hard or
git pull --force.

--
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: rm -f behavior

[Corinna Vinschen]

On Apr 25 15:51, Douglas Coup wrote:
> On 4/25/2014 3:16 PM, Corinna Vinschen wrote:
> >  Can you please try something else?  I'm wondering if
> >that's not a problem analogue of the one described in
> >http://support.microsoft.com/kb/948252.
> >
> >The "fix" from that KB applied to your case:
> >
> >- Revert to the release Cygwin DLL.
> >
> >- Delete the .blf files and the .regtrans-ms files from your
> >   %Windir%\System32\SMI\Store\Machine folder.
> >
> >- Try the failing rm -f scenario again.
> >
> >Does that fix the problem, too?  If not, I'm back to blaming Perforce.
> I tried these steps, but the rm -f command still fails with the
> original cygwin1.dll in place.

Ok, thanks for testing,
Corinna

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


pgp8ylTKBhblR.pgp
Description: PGP signature

Re: Was ploticus package removed from Cygwin?

[Andrew Schulman]

> On 24/04/2014 03:45, Bill Border wrote:
> > When I first installed Cygwin about 2 years ago, in the setup program I was 
> > able to search for and install the ploticus package.
> >
> > I just re-downloaded the Cygwin setup program and when I search for 
> > ploticus it is not found.
> >
> > Was it removed? If so, is there a way to add it to my cygwin installation?
> >
> > TIA.
> >
> >
> > Thanks,
> > Bill
> >
> 
> only available for 32bit
> http://cygwin.com/packages/x86/ploticus/
> 
> http://www.cygwin.com/cygwin-64bit-missing

Hi.  Yes, I haven't gotten around to rebuilding it for 64-bit.  The
package hasn't been updated in quite a while - I seem to remember
running into some packaging trouble the last time I tried.

Frankly I wasn't sure that anyone still wanted it.  I haven't used it in
a while myself.  But if it's still useful, I can give it another go.

Andrew


--
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: rm -f behavior

[Douglas Coup]

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 4/25/2014 3:16 PM, Corinna Vinschen wrote:

On Apr 25 14:11, Douglas Coup wrote:

On 4/25/2014 11:47 AM, Corinna Vinschen wrote:

On Apr 25 11:30, Douglas Coup wrote:

I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all
I need to do is run tar xvf against this file?  From the output it
certainly looked like it installed the files.

No.  Just download the DLL and only install the DLL in place of the old
DLL.  Installing the tar inst file under Cygwin doesn't effectively
replace the Cygwin DLL.  You should exit all(!) Cygwin processes, mopve
the release DLL out of the way, and move the new DLL in place.

Good shooting, Corinna.  The problem has gone away with the new DLL.

Good to know.  Can you please try something else?  I'm wondering if
that's not a problem analogue of the one described in
http://support.microsoft.com/kb/948252.

The "fix" from that KB applied to your case:

- Revert to the release Cygwin DLL.

- Delete the .blf files and the .regtrans-ms files from your
   %Windir%\System32\SMI\Store\Machine folder.

- Try the failing rm -f scenario again.

Does that fix the problem, too?  If not, I'm back to blaming Perforce.
I tried these steps, but the rm -f command still fails with the original 
cygwin1.dll in place.



Thanks,
Corinna




--
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: rm -f behavior

[Corinna Vinschen]

On Apr 25 14:11, Douglas Coup wrote:
> On 4/25/2014 11:47 AM, Corinna Vinschen wrote:
> >On Apr 25 11:30, Douglas Coup wrote:
> >>I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all
> >>I need to do is run tar xvf against this file?  From the output it
> >>certainly looked like it installed the files.
> >No.  Just download the DLL and only install the DLL in place of the old
> >DLL.  Installing the tar inst file under Cygwin doesn't effectively
> >replace the Cygwin DLL.  You should exit all(!) Cygwin processes, mopve
> >the release DLL out of the way, and move the new DLL in place.
> Good shooting, Corinna.  The problem has gone away with the new DLL.

Good to know.  Can you please try something else?  I'm wondering if
that's not a problem analogue of the one described in
http://support.microsoft.com/kb/948252.

The "fix" from that KB applied to your case:

- Revert to the release Cygwin DLL.

- Delete the .blf files and the .regtrans-ms files from your
  %Windir%\System32\SMI\Store\Machine folder. 

- Try the failing rm -f scenario again.

Does that fix the problem, too?  If not, I'm back to blaming Perforce.


Thanks,
Corinna

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


pgphFxtZ4SQAV.pgp
Description: PGP signature

Re: 64-bit vs. 32-bit

[Christopher Faylor]

On Fri, Apr 25, 2014 at 08:21:57PM +0200, Erwin Waterlander wrote:
>Op 25-4-2014 20:13 Tom Szczesny schreef:
>> result from uname -a
>> CYGWIN_NT-6.1-WOW64 Toshiba 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
>
>uname -a on 64 bit cygwin should say something like:
>
>CYGWIN_NT-6.1 PC2 1.7.28(0.271/5/3) 2014-02-09 21:06 x86_64 Cygwin
>
>Note there is no "WOW64", and there is a "x86_64".
>
>>Sorry that I was not clear.  I have an open source app (hosted on
>>github.com) that was developed for Linux.  It compiles and works on
>>Windows-64 using my current version of Cygwin, but I suspect that I am
>>getting a 32-bit executable as a result.
>>
>>I wish to get a 64-bit executable, which I intend to redistribute to
>>other Windows users.
>>
>>Do I need to uninstall my 32-bit version of Cygwin from my laptop
>>before I install the 64-bit version of Cygwin?
>>
>No, you can have both 32 and 64 bit Cygwin installed.

Right.  Just install the 64-bit Cygwin in a different location.

Note that if you distribute your executable you will have to pay
attention to the terms of the GPL - you'll need to provide all of the
source code for everything you distribute, including the Cygwin DLL.

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: Coverity Scan

[David Arnstein]

On Fri, Apr 25, 2014 at 11:53:24AM -0400, Christopher Faylor wrote:
> We use coverity at work.  It is annoying and it does have false positive
> but a lot of what look like false positives often turn out to be:  "Oh,
> wait.  (#*(&$  Yeah.  That's a problem."

I use Coverity as well, and I find it to be excellent. The latest version
finds copy and paste errors. In particular, it recently issued two
complaints about such errors. In both cases, Coverity was correct, a
developer really had done copy-and-paste twice, introducing an error
each time.

--
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: 64-bit vs. 32-bit

[Erwin Waterlander]

Op 25-4-2014 20:13 Tom Szczesny schreef:

result from uname -a
CYGWIN_NT-6.1-WOW64 Toshiba 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin


uname -a on 64 bit cygwin should say something like:

CYGWIN_NT-6.1 PC2 1.7.28(0.271/5/3) 2014-02-09 21:06 x86_64 Cygwin

Note there is no "WOW64", and there is a "x86_64".


Sorry that I was not clear.
I have an open source app (hosted on github.com) that was developed
for Linux.  It compiles and works on Windows-64 using my current
version of Cygwin, but I suspect that I am getting a 32-bit executable
as a result.

I wish to get a 64-bit executable, which I intend to redistribute to
other Windows users.

Do I need to uninstall my 32-bit version of Cygwin from my laptop
before I install the 64-bit version of Cygwin?


No, you can have both 32 and 64 bit Cygwin installed.

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/


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

64-bit vs. 32-bit

[Tom Szczesny]

result from uname -a
CYGWIN_NT-6.1-WOW64 Toshiba 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin

Sorry that I was not clear.
I have an open source app (hosted on github.com) that was developed
for Linux.  It compiles and works on Windows-64 using my current
version of Cygwin, but I suspect that I am getting a 32-bit executable
as a result.

I wish to get a 64-bit executable, which I intend to redistribute to
other Windows users.

Do I need to uninstall my 32-bit version of Cygwin from my laptop
before I install the 64-bit version of Cygwin?

--
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: rm -f behavior

[Douglas Coup]

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 4/25/2014 11:47 AM, Corinna Vinschen wrote:


Please don't top-post.  Thanks.


On Apr 25 11:30, Douglas Coup wrote:

I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all
I need to do is run tar xvf against this file?  From the output it
certainly looked like it installed the files.

No.  Just download the DLL and only install the DLL in place of the old
DLL.  Installing the tar inst file under Cygwin doesn't effectively
replace the Cygwin DLL.  You should exit all(!) Cygwin processes, mopve
the release DLL out of the way, and move the new DLL in place.

Good shooting, Corinna.  The problem has gone away with the new DLL.



But I'm not seeing any difference.  I'm still seeing the permission
denied error on rm -f in the scenarios I've described.

Incidentally, the sequence below should have nothing to do with Perforce.

$ touch dac.txt
$ chmod 444 dac.txt
$ rm -f dac.txt

This is being done completely outside of any Perforce workspaces.

Sorry, this isn't helpful.  Make sure you're *really* using the correct
Cygwin DLL from the snapshot (uname -a), and if the above sequence
really fails to work, first call `attrib dac.txt' before calling rm to
see if the R/O attribute is set, then call rm under strace again and
send the strace.  Also, if the R/O attribute gets set in the above
sequence, I have to know where it comes from.  As I said, Cygwin does
not set the flag at all for normal files, not even in chmod.


Corinna




--
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: 64-bit vs. 32-bit

[Tim Prince]

On 4/25/2014 1:38 PM, Christopher Faylor wrote:

On Fri, Apr 25, 2014 at 01:26:22PM -0400, Tom Szczesny wrote:

I have a 64-bit Windows laptop, and installed Cygwin several years ago.
I wish to verify that I did install the 64-bit installation.
I get the following results:

cygcheck -V
cygcheck (cygwin) 1.7.15

uname
CYGWIN_NT-6.1-WOW64

If I did install the 64-bit version, when I rebuild my Linux app on
Cygwin, do I automatically get a 64-bit executable (that will not run
on a 32-bit Windows computer)?

1) No, you didn't install a 64-bit version of Cygwin.  "uname -a" should
make that clear.  You'll need to instal a 64-bit version if that's what
you want.

2) Cygwin doesn't build Linux apps.  If you have a cross-compiler then
it won't automatically decide to build 64-bit Linux apps because you
are on a 64-bit sytem.


There are cygwin 64- and 32-bit native compilers and mingw 32- and 
64-bit compilers on the setup.exe menu in case you mean to build for one 
of those targets.


--
Tim Prince


--
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: 64-bit vs. 32-bit

[Christopher Faylor]

On Fri, Apr 25, 2014 at 01:26:22PM -0400, Tom Szczesny wrote:
>I have a 64-bit Windows laptop, and installed Cygwin several years ago.
>I wish to verify that I did install the 64-bit installation.
>I get the following results:
>
>cygcheck -V
>cygcheck (cygwin) 1.7.15
>
>uname
>CYGWIN_NT-6.1-WOW64
>
>If I did install the 64-bit version, when I rebuild my Linux app on
>Cygwin, do I automatically get a 64-bit executable (that will not run
>on a 32-bit Windows computer)?

1) No, you didn't install a 64-bit version of Cygwin.  "uname -a" should
make that clear.  You'll need to instal a 64-bit version if that's what
you want.

2) Cygwin doesn't build Linux apps.  If you have a cross-compiler then
it won't automatically decide to build 64-bit Linux apps because you
are on a 64-bit sytem.

--
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: Screen crippled by applications using alternative screen

[Christopher Faylor]

On Fri, Apr 25, 2014 at 05:20:21PM +, Dawid Ferenczy wrote:
>Hi,
>
>I'm still having issues with applications which use alternative screen for 
>output (LESS, MAN). When I exit that application, its output stays on 
>screen, prompt is displayed over it.
>
>My system is as follows:
>
>OS: Windows 7 Home 64 bit
>Cygwin: 1.7.29 64 bit
>Console emulator: ConEmu 140416 64 bit, Console 2.00.148 64 bit
>
>Example steps to reproduce the issue:
>
>1. execute "man grep"
>2. scroll down to the end (PAGE DOWN)
>3. exit (press Q), result: http://ferenczy.cz/tmp/cygwin/1.png
>4. execute "pwd", result: http://ferenczy.cz/tmp/cygwin/2.png
>5. clear screen (CTRL + L), result: http://ferenczy.cz/tmp/cygwin/3.png
>
>Behavior is the same in plain cmd.exe, Console2 and ConEmu. MinTTY works 
>fine. If I exit MAN on first page (without scrolling), the screen isn't 
>crippled.
>
>To reach clean screen I have to repeatedly clear the screen (CTRL + L) until 
>I browse whole MAN output (all pages). Alternative screen should be 
>completely separated from the regular screen.
>
>It's probably caused by that Cygwin doesn't send ANSI codes to the console 
>emulator, see https://code.google.com/p/conemu-maximus5/wiki/CygwinAnsi.

"doesn't send ANSI codes to the console" doesn't make a lot of sense.
"Cygwin" doesn't send ANSI codes to the windows console since the windows
console doesn't understand ANSI codes.

I don't see the behavior that you are specifying but I doubt that what
you are seeing has anything to do with the gobbledegook on the above
page.  If you do want "Cygwin" to send ANSI escape sequences then you'll
need to make sure that you're using a package which knows how to send
them, i.e., an ncurses-using package, and that the TERM environment
variable is set appropriately.

cgf

It 
>has another consequences, for example there doesn't work mouse in 
>applications under Cygwin, see https://code.google.com/p/conemu-
>maximus5/issues/detail?id=1497 (last messages).
>
>Would it be possible to solve this somehow? This could solve all issues with 
>crippled screen, scroll buffer, not working mouse etc, I guess. Moreover 
>ANSI codes are standard behavior.
>
>Thank you for your opinion.
>
>-- 
> Dawid Ferenczy
> http://twitter.com/DawidFerenczy
>
>
>--
>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

64-bit vs. 32-bit

[Tom Szczesny]

I have a 64-bit Windows laptop, and installed Cygwin several years ago.
I wish to verify that I did install the 64-bit installation.
I get the following results:

cygcheck -V
cygcheck (cygwin) 1.7.15

uname
CYGWIN_NT-6.1-WOW64

If I did install the 64-bit version, when I rebuild my Linux app on
Cygwin, do I automatically get a 64-bit executable (that will not run
on a 32-bit Windows computer)?

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

Screen crippled by applications using alternative screen

[Dawid Ferenczy]

Hi,

I'm still having issues with applications which use alternative screen for 
output (LESS, MAN). When I exit that application, its output stays on 
screen, prompt is displayed over it.

My system is as follows:

OS: Windows 7 Home 64 bit
Cygwin: 1.7.29 64 bit
Console emulator: ConEmu 140416 64 bit, Console 2.00.148 64 bit

Example steps to reproduce the issue:

1. execute "man grep"
2. scroll down to the end (PAGE DOWN)
3. exit (press Q), result: http://ferenczy.cz/tmp/cygwin/1.png
4. execute "pwd", result: http://ferenczy.cz/tmp/cygwin/2.png
5. clear screen (CTRL + L), result: http://ferenczy.cz/tmp/cygwin/3.png

Behavior is the same in plain cmd.exe, Console2 and ConEmu. MinTTY works 
fine. If I exit MAN on first page (without scrolling), the screen isn't 
crippled.

To reach clean screen I have to repeatedly clear the screen (CTRL + L) until 
I browse whole MAN output (all pages). Alternative screen should be 
completely separated from the regular screen.

It's probably caused by that Cygwin doesn't send ANSI codes to the console 
emulator, see https://code.google.com/p/conemu-maximus5/wiki/CygwinAnsi. It 
has another consequences, for example there doesn't work mouse in 
applications under Cygwin, see https://code.google.com/p/conemu-
maximus5/issues/detail?id=1497 (last messages).

Would it be possible to solve this somehow? This could solve all issues with 
crippled screen, scroll buffer, not working mouse etc, I guess. Moreover 
ANSI codes are standard behavior.

Thank you for your opinion.

-- 
 Dawid Ferenczy
 http://twitter.com/DawidFerenczy


--
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: GIT (was: Coverity Scan)

[Corinna Vinschen]

On Apr 25 15:24, Jim Garrison wrote:
> > Corinna Vinschen
> > > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> > > >with CVS or SVN, but have nothing but trouble with git.  But since
> > > >everybody else is so very happy with git, I guess I'll have to adapt.
> > > >Teeth-gnashingly.
> 
> I recently went through the same reluctant switch to Git from SVN.
> 
> I can tell you from personal experience that there's a period of 
> disorientation when even the simplest tasks require a quick trip to Google.  
> And Git requires a major shift in your mental model of how things work. 
> Instead of 2 places where stuff is (local and remote) there are now 4 
> (workspace, stage, local repo, remote repo).
> 
> HOWEVER... once you get over the learning hump you see that Git is MUCH 
> better and allows much finer control over what's happening.  Plus, the online 
> documentation is very good, and questions have been asked enough times that 
> Google serves up good answers to just about any question.  If you have 
> Cygwin/X installed, the "git gui" and "gitk" tools will make the transition 
> easier.
> 
> I started learning Git in earnest back in December, and really started 
> "thinking in Git" soon after.  Now, if I had to go back I would be 
> disappointed.

Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/


Corinna

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


pgpewnqxvBmUk.pgp
Description: PGP signature

Re: Coverity Scan

[Christopher Faylor]

On Fri, Apr 25, 2014 at 02:17:19PM +0200, Corinna Vinschen wrote:
>On Apr 25 11:10, Jan Nijtmans wrote:
>> 2014-04-25 10:35 GMT+02:00 Corinna Vinschen:
>> > Yeah, I'm n ot exactly looking forward to it since I'm very familiar
>> > with CVS or SVN, but have nothing but trouble with git.  But since
>> > everybody else is so very happy with git, I guess I'll have to adapt.
>> > Teeth-gnashingly.
>> 
>> There are other alternatives than SVN and Git, you could try
>> Fossil: 
>> 
>> Jari Aalto made fossil version 1.28 available recently as
>> Cygwin/Cygwin64 package, which works fine. (Previous
>> builds had issues due to SQLite build problems, but those
>> are all fixed in this build). Highly recommended,
>> especially if you hate GIT (you are not the only one, really!),
>> I am using it extensively.
>
>Looks nice, but I'm not so sure there should run YA sccs on sourceware.

Right.

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: Coverity Scan

[Christopher Faylor]

On Fri, Apr 25, 2014 at 10:35:00AM +0200, Corinna Vinschen wrote:
>On Apr 25 06:33, David Stacey wrote:
>> Coverity Scan [1] is a commercial (paid for) static analysis tool, but
>> they offer it to Open Source programmes for free. I was having a browse
>> through the list of Open Source programmes using Coverity Scan, and
>> noticed that Cygwin wasn't listed. Would there be any interest in
>> analysing the cygwin1.dll source code on a fairly regular basis? If so,
>> I would be happy to have a go at setting up an analysis job for Cygwin.
>> 
>> I would imagine this would be of interest to CGF, Corinna and anyone
>> else who regularly updates the Cygwin source code. Obviously, this is
>> only worth doing if the analysis results are looked at and acted upon.
>
>Depends.  If the report contains lots of false positives, it's getting
>annoying pretty quickly.

We use coverity at work.  It is annoying and it does have false positive
but a lot of what look like false positives often turn out to be:  "Oh,
wait.  (#*(&$  Yeah.  That's a problem."

If we could use coverity I'm sure it would be interesting if we can get
it.

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: rm -f behavior

[Corinna Vinschen]

On Apr 25 17:47, Corinna Vinschen wrote:
> On Apr 25 11:30, Douglas Coup wrote:
> > Incidentally, the sequence below should have nothing to do with Perforce.
> > 
> > $ touch dac.txt
> > $ chmod 444 dac.txt
> > $ rm -f dac.txt
> > 
> > This is being done completely outside of any Perforce workspaces.
> 
> Sorry, this isn't helpful.  Make sure you're *really* using the correct
> Cygwin DLL from the snapshot (uname -a), and if the above sequence
> really fails to work, first call `attrib dac.txt' before calling rm to
> see if the R/O attribute is set, then call rm under strace again and
> send the strace.  Also, if the R/O attribute gets set in the above
> sequence, I have to know where it comes from.  As I said, Cygwin does
> not set the flag at all for normal files, not even in chmod.

...on NTFS.  It uses the R/O bit on FAT or other crippled filesystems,
but then it wouldn't even try to start a transaction since only NTFS
supports that anyway.


Corinna

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


pgpYASDzZ_ByI.pgp
Description: PGP signature

Re: rm -f behavior

[Corinna Vinschen]

Please don't top-post.  Thanks.


On Apr 25 11:30, Douglas Coup wrote:
> I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all
> I need to do is run tar xvf against this file?  From the output it
> certainly looked like it installed the files.

No.  Just download the DLL and only install the DLL in place of the old
DLL.  Installing the tar inst file under Cygwin doesn't effectively
replace the Cygwin DLL.  You should exit all(!) Cygwin processes, mopve
the release DLL out of the way, and move the new DLL in place.

> But I'm not seeing any difference.  I'm still seeing the permission
> denied error on rm -f in the scenarios I've described.
> 
> Incidentally, the sequence below should have nothing to do with Perforce.
> 
> $ touch dac.txt
> $ chmod 444 dac.txt
> $ rm -f dac.txt
> 
> This is being done completely outside of any Perforce workspaces.

Sorry, this isn't helpful.  Make sure you're *really* using the correct
Cygwin DLL from the snapshot (uname -a), and if the above sequence
really fails to work, first call `attrib dac.txt' before calling rm to
see if the R/O attribute is set, then call rm under strace again and
send the strace.  Also, if the R/O attribute gets set in the above
sequence, I have to know where it comes from.  As I said, Cygwin does
not set the flag at all for normal files, not even in chmod.


Corinna

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


pgptZT1zwyfEb.pgp
Description: PGP signature

Re: rm -f behavior

[Douglas Coup]

I downloaded the x86/cygwin-inst-20140425.tar.xz file.  I assume all I 
need to do is run tar xvf against this file?  From the output it 
certainly looked like it installed the files.


But I'm not seeing any difference.  I'm still seeing the permission 
denied error on rm -f in the scenarios I've described.


Incidentally, the sequence below should have nothing to do with Perforce.

$ touch dac.txt
$ chmod 444 dac.txt
$ rm -f dac.txt

This is being done completely outside of any Perforce workspaces.

Regards,

Doug Coup

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 4/25/2014 10:50 AM, Corinna Vinschen wrote:

On Apr 25 10:23, Douglas Coup wrote:

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 4/25/2014 8:16 AM, Corinna Vinschen wrote:

On Apr 24 18:36, Corinna Vinschen wrote:

On Apr 24 11:34, Douglas Coup wrote:

If I do "which rm" and "which chmod", it shows that both commands
resolve to the Cygwin binaries.

The attached rm.notworking.trace file is from an "rm -f dac.txt"
command that gets the permission denied error; i.e., when the
permissions on the file are 444.  Things seem to start going south
at entry 34276.

Gosh, how many ways to fail does transactional NTFS know?

Btw., this is not just the result of creating the file and chmod'ing it
to 444 in Cygwin, is it?  The reason I'm asking is that Cygwin does not
set the DOS R/O bit when chmod'ing the file to 444.  In fact, Cygwin
never sets the R/O bit, except for *.lnk type symlinks.

It doesn't seem to be related specifically to the chmod command.

For example, we use Perforce as our software control system.  The
files in my Perforce workspaces that are under Perforce control are
read-only files unless they're checked out for modification.  In
Cygwin this means the files have a permission mask of 444 out of the
box; no chmod command was done.  If I pick one of those files and
try to do an rm -f on it, I get the permission denied error.  If I
copy the file to a different name, I also get the permission denied
error if I try to do an rm -f on it.  But if I do chmod u+w on the
file, I can do the rm -f.

Yes, it's all about the DOS R/O bit here.  Cygwin doesn't try to start
a transaction if the R/O bit is unset.  The problem *seems* to be that
there's a Perforce transaction manager already enlisted to the files,
and that transaction manager is getting in the way.  Maybe you just
shouldn't try to remove a file from the Perforce-controlled area, unless
you removed the file from version control before.

Anyway, I applied a patch which covers more transactional error codes,
so as to retry the activity without transaction.  This should help you
along.  Please give the today's developer snapshot from
http://cygwin.com/snapshots/  a try.


Thanks,
Corinna




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

GIT (was: Coverity Scan)

[Jim Garrison]

> -Original Message-
> Corinna Vinschen
> Sent: Friday, April 25, 2014 6:33 AM
> > >>  There have been a few hints on this list about a possible move
> > >> from CVS  to git. If such a move were on the cards then that should
> > >> probably  happen first - I wouldn't want the nugatory effort of
> > >> getting this  working from CVS only to have to change it almost
> immediately.
> > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> > >with CVS or SVN, but have nothing but trouble with git.  But since
> > >everybody else is so very happy with git, I guess I'll have to adapt.
> > >Teeth-gnashingly.

I recently went through the same reluctant switch to Git from SVN.

I can tell you from personal experience that there's a period of disorientation 
when even the simplest tasks require a quick trip to Google.  And Git requires 
a major shift in your mental model of how things work. Instead of 2 places 
where stuff is (local and remote) there are now 4 (workspace, stage, local 
repo, remote repo).

HOWEVER... once you get over the learning hump you see that Git is MUCH better 
and allows much finer control over what's happening.  Plus, the online 
documentation is very good, and questions have been asked enough times that 
Google serves up good answers to just about any question.  If you have Cygwin/X 
installed, the "git gui" and "gitk" tools will make the transition easier.

I started learning Git in earnest back in December, and really started 
"thinking in Git" soon after.  Now, if I had to go back I would be disappointed.

Re: rm -f behavior

[Corinna Vinschen]

On Apr 25 10:23, Douglas Coup wrote:
> 
> Objective Systems, Inc.
> REAL WORLD ASN.1 AND XML SOLUTIONS
> Tel: +1 (484) 875-9841
> Fax: +1 (484) 875-9830
> Toll-free: (877) 307-6855 (USA only)
> http://www.obj-sys.com
> 
> On 4/25/2014 8:16 AM, Corinna Vinschen wrote:
> >On Apr 24 18:36, Corinna Vinschen wrote:
> >>On Apr 24 11:34, Douglas Coup wrote:
> >>>If I do "which rm" and "which chmod", it shows that both commands
> >>>resolve to the Cygwin binaries.
> >>>
> >>>The attached rm.notworking.trace file is from an "rm -f dac.txt"
> >>>command that gets the permission denied error; i.e., when the
> >>>permissions on the file are 444.  Things seem to start going south
> >>>at entry 34276.
> >>Gosh, how many ways to fail does transactional NTFS know?
> >Btw., this is not just the result of creating the file and chmod'ing it
> >to 444 in Cygwin, is it?  The reason I'm asking is that Cygwin does not
> >set the DOS R/O bit when chmod'ing the file to 444.  In fact, Cygwin
> >never sets the R/O bit, except for *.lnk type symlinks.
> It doesn't seem to be related specifically to the chmod command.
> 
> For example, we use Perforce as our software control system.  The
> files in my Perforce workspaces that are under Perforce control are
> read-only files unless they're checked out for modification.  In
> Cygwin this means the files have a permission mask of 444 out of the
> box; no chmod command was done.  If I pick one of those files and
> try to do an rm -f on it, I get the permission denied error.  If I
> copy the file to a different name, I also get the permission denied
> error if I try to do an rm -f on it.  But if I do chmod u+w on the
> file, I can do the rm -f.

Yes, it's all about the DOS R/O bit here.  Cygwin doesn't try to start
a transaction if the R/O bit is unset.  The problem *seems* to be that
there's a Perforce transaction manager already enlisted to the files,
and that transaction manager is getting in the way.  Maybe you just
shouldn't try to remove a file from the Perforce-controlled area, unless
you removed the file from version control before.

Anyway, I applied a patch which covers more transactional error codes,
so as to retry the activity without transaction.  This should help you
along.  Please give the today's developer snapshot from
http://cygwin.com/snapshots/ a try.


Thanks,
Corinna

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


pgpTX76icq1he.pgp
Description: PGP signature

Re: rm -f behavior

[Douglas Coup]

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 4/25/2014 8:16 AM, Corinna Vinschen wrote:

On Apr 24 18:36, Corinna Vinschen wrote:

On Apr 24 11:34, Douglas Coup wrote:

If I do "which rm" and "which chmod", it shows that both commands
resolve to the Cygwin binaries.

The attached rm.notworking.trace file is from an "rm -f dac.txt"
command that gets the permission denied error; i.e., when the
permissions on the file are 444.  Things seem to start going south
at entry 34276.

Gosh, how many ways to fail does transactional NTFS know?

Btw., this is not just the result of creating the file and chmod'ing it
to 444 in Cygwin, is it?  The reason I'm asking is that Cygwin does not
set the DOS R/O bit when chmod'ing the file to 444.  In fact, Cygwin
never sets the R/O bit, except for *.lnk type symlinks.

It doesn't seem to be related specifically to the chmod command.

For example, we use Perforce as our software control system.  The files 
in my Perforce workspaces that are under Perforce control are read-only 
files unless they're checked out for modification.  In Cygwin this means 
the files have a permission mask of 444 out of the box; no chmod command 
was done.  If I pick one of those files and try to do an rm -f on it, I 
get the permission denied error.  If I copy the file to a different 
name, I also get the permission denied error if I try to do an rm -f on 
it.  But if I do chmod u+w on the file, I can do the rm -f.


However, this:


20   34002 [main] rm 7580 unlink_nt: Trying to delete 
\??\C:\mydocs\temp\dac.txt, isdir = 0
   274   34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt for 
removing R/O failed, status = 0xC0190052

shows that the DOS R/O bit was set.  If this attribute really showed up
after you'd called chmod, how did it get there?!?


Corinna




--
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: Coverity Scan

[Corinna Vinschen]

On Apr 25 13:19, David Stacey wrote:
> On 25/04/14 09:35, Corinna Vinschen wrote:
> >>  There are some conditions associated with using Coverity Scan [2]. The
> >>  one thing that jumps out is that our relationship with RedHat might be
> >>  a stumbling block. We can but ask - the worst that can happen is that
> >>  they politely decline.
> >They will.  #7 won't fly due to the buyout license clause.
> 
> Would you like me to enquire anyway?

Well, asking never hurts :)

> >>  There have been a few hints on this list about a possible move from CVS
> >>  to git. If such a move were on the cards then that should probably
> >>  happen first - I wouldn't want the nugatory effort of getting this
> >>  working from CVS only to have to change it almost immediately.
> >Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> >with CVS or SVN, but have nothing but trouble with git.  But since
> >everybody else is so very happy with git, I guess I'll have to adapt.
> >Teeth-gnashingly.
> 
> It might help ease your pain knowing that you can use github with a
> svn client (to a limited extent):
> https://help.github.com/articles/support-for-subversion-clients

Neat.  But I fear it's time to get used to the idea.


Corinna

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


pgpn6jZeetg14.pgp
Description: PGP signature

Re: Coverity Scan

[David Stacey]

On 25/04/14 09:35, Corinna Vinschen wrote:

  There are some conditions associated with using Coverity Scan [2]. The
  one thing that jumps out is that our relationship with RedHat might be
  a stumbling block. We can but ask - the worst that can happen is that
  they politely decline.

They will.  #7 won't fly due to the buyout license clause.


Would you like me to enquire anyway?




  There have been a few hints on this list about a possible move from CVS
  to git. If such a move were on the cards then that should probably
  happen first - I wouldn't want the nugatory effort of getting this
  working from CVS only to have to change it almost immediately.

Yeah, I'm n ot exactly looking forward to it since I'm very familiar
with CVS or SVN, but have nothing but trouble with git.  But since
everybody else is so very happy with git, I guess I'll have to adapt.
Teeth-gnashingly.


It might help ease your pain knowing that you can use github with a svn 
client (to a limited extent):

https://help.github.com/articles/support-for-subversion-clients

Dave.


--
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: Coverity Scan

[Corinna Vinschen]

On Apr 25 11:10, Jan Nijtmans wrote:
> 2014-04-25 10:35 GMT+02:00 Corinna Vinschen:
> > Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> > with CVS or SVN, but have nothing but trouble with git.  But since
> > everybody else is so very happy with git, I guess I'll have to adapt.
> > Teeth-gnashingly.
> 
> There are other alternatives than SVN and Git, you could try
> Fossil: 
> 
> Jari Aalto made fossil version 1.28 available recently as
> Cygwin/Cygwin64 package, which works fine. (Previous
> builds had issues due to SQLite build problems, but those
> are all fixed in this build). Highly recommended,
> especially if you hate GIT (you are not the only one, really!),
> I am using it extensively.

Looks nice, but I'm not so sure there should run YA sccs on sourceware.


Corinna

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


pgpx3UAlrkJ9e.pgp
Description: PGP signature

Re: rm -f behavior

[Corinna Vinschen]

On Apr 24 18:36, Corinna Vinschen wrote:
> On Apr 24 11:34, Douglas Coup wrote:
> > If I do "which rm" and "which chmod", it shows that both commands
> > resolve to the Cygwin binaries.
> > 
> > The attached rm.notworking.trace file is from an "rm -f dac.txt"
> > command that gets the permission denied error; i.e., when the
> > permissions on the file are 444.  Things seem to start going south
> > at entry 34276.
> 
> Gosh, how many ways to fail does transactional NTFS know?

Btw., this is not just the result of creating the file and chmod'ing it
to 444 in Cygwin, is it?  The reason I'm asking is that Cygwin does not
set the DOS R/O bit when chmod'ing the file to 444.  In fact, Cygwin
never sets the R/O bit, except for *.lnk type symlinks.

However, this:

> >20   34002 [main] rm 7580 unlink_nt: Trying to delete 
> > \??\C:\mydocs\temp\dac.txt, isdir = 0
> >   274   34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt 
> > for removing R/O failed, status = 0xC0190052

shows that the DOS R/O bit was set.  If this attribute really showed up
after you'd called chmod, how did it get there?!?


Corinna

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


pgp_qXONmiBWr.pgp
Description: PGP signature

Re: ambiguous overload for operator [] on Cygwin_X86-64

[Tatsuro MATSUOKA]

--- On Fri, 2014/4/25, Yaakov (Cygwin/X) wrote:
> On 2014-04-23 22:15, Tatsuro MATSUOKA wrote:
> > I tried to build wxWidgets-3.0.0 on Cygwin.
> > For Cygwin x86, the build was successful.
> >
> > However, on Cygwin x86_64, the build failed at compling a cpp source file 
> > (src/common/appbase.cpp).
> >
> > ./include/wx/filename.h: In static member function 'static wxUniChar 
> > wxFileName::GetPathSeparator(wxPathFormat)':
> > ./include/wx/filename.h:473:43: error: ambiguous overload for 'operator[]' 
> > (operand types are 'wxString' and 'unsigned int')
> >           { return GetPathSeparators(format)[0u]; }
> >
> > The code "(format)[0u]" seemed to be accepted g++-4.8.2 on Cygwin x86_64.
> > What the difference of g++ between that of  Cygwin x86 and that of Cygwin 
> > x86_64?
> 
> wxWidgets requires several patches to build and/or run correctly on 
> Cygwin/X.  I haven't looked at 3.0 yet, but for 2.8 this issue is fixed 
> in my 2.8.12-cygwin64.patch:
> 
> http://sourceforge.net/p/cygwin-ports/wxWidgets2.8/
> 
> 
> Yaakov
> Cygwin/X

With your patch, I could build WxGTK-2.8.12.  I can build gnuplot with the wxt 
terminal.
That is really I want to execute. 

Thanks a lot!

Tatsuro

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

Fwd: Coverity Scan

[Jan Nijtmans]

2014-04-25 10:35 GMT+02:00 Corinna Vinschen:
> Yeah, I'm n ot exactly looking forward to it since I'm very familiar
> with CVS or SVN, but have nothing but trouble with git.  But since
> everybody else is so very happy with git, I guess I'll have to adapt.
> Teeth-gnashingly.

There are other alternatives than SVN and Git, you could try
Fossil: 

Jari Aalto made fossil version 1.28 available recently as
Cygwin/Cygwin64 package, which works fine. (Previous
builds had issues due to SQLite build problems, but those
are all fixed in this build). Highly recommended,
especially if you hate GIT (you are not the only one, really!),
I am using it extensively.

Regards,
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: THANKS!

[thuhuong]

THANK YOU FOR YOUR MAIL.




NGUYEN THI THU HUONG
Director
Mobile: 0939..38
---
PRODINCOM PHARMA CO.,LTD
I-7 Bis Chau Thoi Street, 15 Ward , District  10,  Ho Chi Minh city
Tel: 08.3977.8301
Fax: 08. 3977.8302
Email: thuhu...@prodincompharma.vn




--
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: Coverity Scan

[Corinna Vinschen]

On Apr 25 06:33, David Stacey wrote:
> Coverity Scan [1] is a commercial (paid for) static analysis tool, but
> they offer it to Open Source programmes for free. I was having a browse
> through the list of Open Source programmes using Coverity Scan, and
> noticed that Cygwin wasn't listed. Would there be any interest in
> analysing the cygwin1.dll source code on a fairly regular basis? If so,
> I would be happy to have a go at setting up an analysis job for Cygwin.
> 
> I would imagine this would be of interest to CGF, Corinna and anyone
> else who regularly updates the Cygwin source code. Obviously, this is
> only worth doing if the analysis results are looked at and acted upon.

Depends.  If the report contains lots of false positives, it's getting
annoying pretty quickly.

> There are some conditions associated with using Coverity Scan [2]. The
> one thing that jumps out is that our relationship with RedHat might be
> a stumbling block. We can but ask - the worst that can happen is that
> they politely decline.

They will.  #7 won't fly due to the buyout license clause.

> There have been a few hints on this list about a possible move from CVS
> to git. If such a move were on the cards then that should probably
> happen first - I wouldn't want the nugatory effort of getting this
> working from CVS only to have to change it almost immediately.

Yeah, I'm n ot exactly looking forward to it since I'm very familiar
with CVS or SVN, but have nothing but trouble with git.  But since
everybody else is so very happy with git, I guess I'll have to adapt.
Teeth-gnashingly.


Corinna

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


pgpS_ZNDpqiMD.pgp
Description: PGP signature