Re: set Cygwin terminal title

[Csaba Raduly]

On Tue, Apr 8, 2014 at 4:55 PM, Adam Dinwoodie  wrote:
> On Tue, Apr 08, 2014 at 03:24:29PM +0100, xmoon 2000 wrote:
>> Ho can I set Cygwin termnal title?
>>
>> I have tried echoing every escape sequence I have found on web.
>>
>> None seem to work.
>
> It's reasonably likely your `$PS1` includes a line to set the terminal
> title; I think the default Cygwin Bash profile files do that.  If that's
> the case, an escape sequence command to set the terminal title will
> work, but will then be immediately reset by the Bash prompt being
> displayed.

xmoon, if you are experimenting with setting the terminal title and
indeed PS1 is resetting it, try putting a sleep command after the
title-setting echo:

echo -ne "\033]2;I am ${USER}@${HOSTNAME} at ${PWD}\007"; sleep 3

Now you can admire the new title for three seconds.

Csaba, whose echo $PS1 says
\[\e]0;\u@\h: 
\w\a\]${debian_chroot:+($debian_chroot)}\[\033[00;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

Re: Possible bug with chere 1.4 when configuring for fish

[Ronald Fischer]

On Tue, Apr 8, 2014, at 0:35, Dave Kilroy wrote:
> On 07/04/2014 13:02, Ronald Fischer wrote:
> > I have installed fish 2.1.0. Works fine, when invoking a new fish shell
> > manually.
> >
> > However, when doing a
> >
> > chere -ifcm -t mintty -s fish
> >
> > and invoke the new fish shell from the Windows Explorer context menu, I
> > get plenty of error messages, like this:
> >
> > 
> >
> Thanks for the report.
> 
> I've just checked my x86_64 and x86 installation. Things are working on 
> my installation as I have c:\cygwin\bin on my standard windows path. 
> When I remove it and invoke fish, I get the errors that you highlight. 
> Similarly when echo'ing $PATH under the broken fish, /usr/bin is not one 
> of the entries.

Indeed: Once I'm adding the cygwin bin path to my windows system
environment, it works, so this is at least a temporary workaround (on
the long run, I don't want to have the cygwin path permanently set on
this machine).

> I need to have a play around to see how I can fix this, but I thought 
> cygwin prepended /usr/bin to the path...

I don't think "cygwin" by itself changes the path. It certainly doesn't
change the Windows system path (as defined in the "Advanced System
Settings" for Windows).

However, when I start a bash shell, /usr/bin is part of the PATH. This
happens inside /etc/profile. But this file is not always processed; This
depends on how bash is started. You can see the detailed rules in the
bash man-page, in the section INVOCATION.

My guess is that when doing a chere -2 fish, you start via bash in a way
that /etc/profile is not read. 

As for chere -1 fish, I suspect that this will never work, unless the
user has put the Cygwin bin path into his system PATH. Maybe in this
case, chere should output a warning message.

Ronald
-- 
Ronald Fischer 
+  If a packet hits a pocket on a socket on a port, 
+  and the bus is interrupted and the interrupt's not caught,
+  then the socket packet pocket has an error to report.
+   (cited after Peter van der Linden)


--
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: set Cygwin terminal title

[xmoon 2000]

@Csaba   Yes - that works.

Actually that's a big help - because within my looping bash script
that is keeping the window title up/changing until scripts stops .
Which is perfect.

thanks you

On 9 April 2014 08:37, Csaba Raduly  wrote:
> On Tue, Apr 8, 2014 at 4:55 PM, Adam Dinwoodie  wrote:
>> On Tue, Apr 08, 2014 at 03:24:29PM +0100, xmoon 2000 wrote:
>>> Ho can I set Cygwin termnal title?
>>>
>>> I have tried echoing every escape sequence I have found on web.
>>>
>>> None seem to work.
>>
>> It's reasonably likely your `$PS1` includes a line to set the terminal
>> title; I think the default Cygwin Bash profile files do that.  If that's
>> the case, an escape sequence command to set the terminal title will
>> work, but will then be immediately reset by the Bash prompt being
>> displayed.
>
> xmoon, if you are experimenting with setting the terminal title and
> indeed PS1 is resetting it, try putting a sleep command after the
> title-setting echo:
>
> echo -ne "\033]2;I am ${USER}@${HOSTNAME} at ${PWD}\007"; sleep 3
>
> Now you can admire the new title for three seconds.
>
> Csaba, whose echo $PS1 says
> \[\e]0;\u@\h: 
> \w\a\]${debian_chroot:+($debian_chroot)}\[\033[00;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\n\$
> --
> GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
> The Tao of math: The numbers you can count are not the real numbers.
> Life is complex, with real and imaginary parts.
> "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus 
> Torvalds
> "People disagree with me. I just ignore them." -- Linus Torvalds
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

--
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 Heimdal/Cygwin, clock, daylight savings conundrum

[Henry S. Thompson]

[cygcheck attachements got through, but message didn't???]

I'm running 64-bit Cygwin.  The problem described here occured both
before and after upgrading from 1.7.28 to 1.7.29.  (Cygcheck attached
to previous message).

I'm in the UK, where summer time started 10 days ago.

My Windows 8.1 laptop correctly gained an hour at that time.

Yesterday it gained _another_ hour :-(.

When I corrected the time by hand, kinit to my local host failed:

 > kinit
 [pwd]
 kinit: krb5_get_init_creds: PREAUTH_FAILED

This usually means timers are out of sync between client (me) and
server.

So I went to work on what I thought was the underlying problem, the
mistaken time.  Fixed that, eventually, by fiddling with BIOS clock
and its relation to the system clock.

But the kinit problem didn't go away.

However, _if_ I set the time one hour forward again, kinit succeeds.

True weirdness follows.  I have 32-bit install as well (for xemacs)
(Cygcheck attached to previous message).  Problem does _not_ manifest
itself there.  kinit works _regardless_ of what the windows clock
says.

Has something changed with system clock vs. hardware clock between 32-
and 64-bit cygwin?  Or am I looking in the wrong place altogether?

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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 Heimdal/Cygwin, clock, daylight savings conundrum

[Corinna Vinschen]

On Apr  9 10:24, Henry S. Thompson wrote:
> [cygcheck attachements got through, but message didn't???]
> 
> I'm running 64-bit Cygwin.  The problem described here occured both
> before and after upgrading from 1.7.28 to 1.7.29.  (Cygcheck attached
> to previous message).
> 
> I'm in the UK, where summer time started 10 days ago.
> 
> My Windows 8.1 laptop correctly gained an hour at that time.
> 
> Yesterday it gained _another_ hour :-(.
> 
> When I corrected the time by hand, kinit to my local host failed:
> 
>  > kinit
>  [pwd]
>  kinit: krb5_get_init_creds: PREAUTH_FAILED
> 
> This usually means timers are out of sync between client (me) and
> server.
> 
> So I went to work on what I thought was the underlying problem, the
> mistaken time.  Fixed that, eventually, by fiddling with BIOS clock
> and its relation to the system clock.
> 
> But the kinit problem didn't go away.
> 
> However, _if_ I set the time one hour forward again, kinit succeeds.
> 
> True weirdness follows.  I have 32-bit install as well (for xemacs)
> (Cygcheck attached to previous message).  Problem does _not_ manifest
> itself there.  kinit works _regardless_ of what the windows clock
> says.
> 
> Has something changed with system clock vs. hardware clock between 32-
> and 64-bit cygwin?  Or am I looking in the wrong place altogether?

Hmm, maybe.  Apart from time_t being 64 bit (32 bit on i686), the
code for time handling is identical.  What's your $TZ set to?


Corinna

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


pgp_cFDaATRHX.pgp
Description: PGP signature

Re: 64-bit Heimdal/Cygwin, clock, daylight savings conundrum

[Henry S. Thompson]

Corinna Vinschen writes:

> On Apr  9 10:24, Henry S. Thompson wrote:
>> [Clock behaving oddly/differently]
>> Has something changed with system clock vs. hardware clock between 32-
>> and 64-bit cygwin?  Or am I looking in the wrong place altogether?
>
> Hmm, maybe.  Apart from time_t being 64 bit (32 bit on i686), the
> code for time handling is identical.  What's your $TZ set to?

Europe/London in both cases.

It occurs to me to check the Heimdal code to see if anything changed
to enable 64-bit compilation. . .

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: Request for Junctions be treated consistently

[Linda Walsh]

Forgive me if this posts a 2nd time, but I haven't seen it come
back after 6+ hours, so not sure where it went.

Corinna Vinschen wrote:


No, it's not.  There's a major difference between mount points and
symlinks, which is, mount points are handled inside the kernel, while
symlinks are filesystem objects.  Reparse points are very certainly
filesystem objects.  And bind mounts in Cygwin are handled in the
"kernel" as well.  We can't add reparse points to the mount table
on the fly.

---
Windows Internals V5, p965

A reparse point is a block of up to 16kb of application defined reparse data
and a 32-bit repase tag that are stored in the $REPARSE_POINT attribute
of a file or directory.  Whenever an application creates or deletes a reparse
point, NTFS updates the \$Extend\$Reparse metadata file, in which NTFS stores\
entries that identify the file record numbers of files and directories that
contain reparse points.  Storing the records in a central location enables NTFS
to provide interfaces for applications to enumerate all a volumes reparse
points, **such** as **mount* *points**.  The $Extend$Reparse file uses the
general indexing facility of NTFS by collating the file's entries (in an
index named $R) by reparse point tags.
-
On p669, mounts are covered -- the bottom paragraph says mount points are 
reparse
points that store a volume name as the reparse data.

Theoretically, there should be a cental resource that would enable you to know
all the reparse points that are associated with mountpoints that wouldn't have
to be added "on the fly", but could be added to /etc/fstab on 
cygwin-initialization.

To further the case for linkd being a type of mount:

I created 2 links to C:\Users -- one with linkd, the other with mklink /d:
C:\tmp\test>dir
 Volume in drive C is System Disk
 Volume Serial Number is E889-68E4

 Directory of C:\tmp\test

04/08/2014  10:35 PM  .
04/08/2014  10:35 PM  ..
04/08/2014  10:35 PM foo [C:\Users]
04/08/2014  10:33 PM Users [C:\Users]
--
Using the fsutil reparsepoint query we can look at the two objects:

fsutil reparsepoint query foo

Reparse Tag Value : 0xa00c
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Symbolic Link

Reparse Data Length: 0x0034
Reparse Data:
:  10 00 18 00 00 00 10 00  00 00 00 00 43 00 3a 00  C.:.
0010:  5c 00 55 00 73 00 65 00  72 00 73 00 5c 00 3f 00  \.U.s.e.r.s.\.?.
0020:  3f 00 5c 00 43 00 3a 00  5c 00 55 00 73 00 65 00  ?.\.C.:.\.U.s.e.
0030:  72 00 73 00   r.s.

Foo is a Symbolic Link.
---


fsutil reparsepoint query Users

Reparse Tag Value : 0xa003
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Mount Point
Substitue Name offset: 0
Substitue Name length: 24
Print Name offset: 26
Print Name Length: 16
Substitute Name:   \??\C:\Users
Print Name:C:\Users

Reparse Data Length: 0x0034
Reparse Data:
:  00 00 18 00 1a 00 10 00  5c 00 3f 00 3f 00 5c 00  \.?.?.\.
0010:  43 00 3a 00 5c 00 55 00  73 00 65 00 72 00 73 00  C.:.\.U.s.e.r.s.
0020:  00 00 43 00 3a 00 5c 00  55 00 73 00 65 00 72 00  ..C.:.\.U.s.e.r.
0030:  73 00 00 00   s...

But the one created with 'linkd' is called a Mount Point.

Does that help clarify the differences between linkd and mountvol vs.
reparse points created by 'mklink'?










--
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 Heimdal/Cygwin, clock, daylight savings conundrum

[Andrey Repin]

Greetings, Henry S. Thompson!

> I'm running 64-bit Cygwin.  The problem described here occured both
> before and after upgrading from 1.7.28 to 1.7.29.  (Cygcheck attached
> to previous message).

> I'm in the UK, where summer time started 10 days ago.

> My Windows 8.1 laptop correctly gained an hour at that time.

> Yesterday it gained _another_ hour :-(.

This is suspicious. I hope, there was no changes to DST dates in UK recently?
How does it appear to you?
I.e. if your time zone in Windows set correctly, what time the system clock
show, and how it is converted to UTC?
Do you have real time synchronization set up?

> When I corrected the time by hand, kinit to my local host failed:

>  > kinit
>  [pwd]
>  kinit: krb5_get_init_creds: PREAUTH_FAILED

> This usually means timers are out of sync between client (me) and
> server.

Could it be a server issue at this point? Is it in the same timezone, as
yourself?

> So I went to work on what I thought was the underlying problem, the
> mistaken time.  Fixed that, eventually, by fiddling with BIOS clock
> and its relation to the system clock.

> But the kinit problem didn't go away.

> However, _if_ I set the time one hour forward again, kinit succeeds.

> True weirdness follows.  I have 32-bit install as well (for xemacs)
> (Cygcheck attached to previous message).  Problem does _not_ manifest
> itself there.  kinit works _regardless_ of what the windows clock
> says.

> Has something changed with system clock vs. hardware clock between 32-
> and 64-bit cygwin?  Or am I looking in the wrong place altogether?


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 09.04.2014, <17:18>

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 Heimdal/Cygwin, clock, daylight savings conundrum

[Henry S. Thompson]

Andrey Repin writes:

>> I'm in the UK, where summer time started 10 days ago.
>
>> My Windows 8.1 laptop correctly gained an hour at that time.
>
>> Yesterday it gained _another_ hour :-(.
>
> This is suspicious. I hope, there was no changes to DST dates in UK recently?

No, moved by one day from 31/3 in 2013 to 30/3 just now.

> How does it appear to you?
> I.e. if your time zone in Windows set correctly, what time the system clock
> show, and how it is converted to UTC?

Windows thinks I'm in (UTC) Dublin, Edinburgh, Lisbon, London, which
is correct.  Windows shows the correct time, as does Cygwin 'date' 

> Do you have real time synchronization set up?

Yes, that's how I got the time fixed.  I'm running ntpd from the
Meinberg distribution.

> Could it be a server issue at this point? Is it in the same timezone, as
> yourself?

No -- same timezone, we're all in the same city, Edinburgh.  I'm not
aware of anyone else with this problem.

>> So I went to work on what I thought was the underlying problem, the
>> mistaken time.  Fixed that, eventually, by fiddling with BIOS clock
>> and its relation to the system clock.
>
>> But the kinit problem didn't go away.
>
>> However, _if_ I set the time one hour forward again, kinit succeeds.
>
>> True weirdness follows.  I have 32-bit install as well (for xemacs)
>> (Cygcheck attached to previous message).  Problem does _not_ manifest
>> itself there.  kinit works _regardless_ of what the windows clock
>> says.

Note that I can't reproduce this anymore :-(.  That is, 32-bit and
64-bit now both require the time to be one hour forward of the correct
time for kinit to work.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: We need steenking patches (Re: Cygwin kill utility...)

[Steven Penny]

On Wed, Apr 9, 2014 at 12:51 AM, Christopher Faylor wrote:
> Except for the lack of an advertised bugzilla link at the Cygwin web
> page, Cygwin is like every one of the other projects hosted at
> sourceware.org/gcc.gnu.org.  This includes thriving projects like gcc,
> binutils, gdb, and others.  All of the developers in those projects were
> able to figure out how to find CVS (svn, git) web information and,
> eventually, check out their stuff.

I see now you have Stockholm Syndrome with CVS. Perhaps you missed the question,
so I will repeat it:

Where is the online search function for the mailing list and code base? With
GitHub you can use this

  http://github.com/svnpenn/bm/search?q=asdf

and it will search all issues and code for a repository. Cygwin appears to have
no web based way of searching either, besides a Google search. That is sad.

--
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 with default manifest when application provides its own

[Ken Brown]

I don't know if this report belongs here or if I should report a 
binutils bug, but I'll start here.


When building emacs-w32.exe with the current binutils, I end up with an 
executable that won't run after it's stripped (at least on x86_64).  I 
traced this to the fact that emacs-w32 comes with its own manifest.  My 
understanding is that the emacs-w32 manifest should take precedence over 
the Cygwin default manifest, but something's going wrong in this case.


Here's a simple test case to illustrate the problem, using a slight 
modification of the resource file that comes with emacs, and the 
corresponding manifest (see attached).


$ windres -O coff emacs.rc -o emacs.res

$ cat test.c
int main()
{
  return 0;
}

$ gcc -o test test.c -Wl,emacs.res

$ strip test.exe

$ ./test.exe
bash: ./test.exe: cannot execute binary file

The stripped binary has a messed up .rsrc section:

$ objdump -j .rsrc -s test.exe

test.exe: file format pei-x86-64

Contents of section .rsrc:
objdump: Reading section failed


Ken
1 24 "emacs-x64.manifest"

#ifndef VS_VERSION_INFO
#define VS_VERSION_INFO 1
#endif

VS_VERSION_INFO VERSIONINFO
 FILEVERSION 24,3,50,0
 PRODUCTVERSION 24,3,50,0
 FILEFLAGSMASK 0x3FL
#ifdef EMACSDEBUG
 FILEFLAGS 0x1L
#else
 FILEFLAGS 0x0L
#endif
 FILEOS 0x40004L
 FILETYPE 0x1L
 FILESUBTYPE 0x0L
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904B0"
BEGIN
VALUE "CompanyName", "Free Software Foundation\0"
VALUE "FileDescription", "GNU Emacs: The extensible 
self-documenting text editor\0"
VALUE "FileVersion", "24, 3, 50, 0\0"
VALUE "InternalName", "Emacs\0"
VALUE "LegalCopyright", "Copyright (C) 2001-2014\0"
VALUE "OriginalFilename", "emacs.exe"
VALUE "ProductName", "Emacs\0"
VALUE "ProductVersion", "24, 3, 50, 0\0"
VALUE "OLESelfRegister", "\0"
 END
 END
 BLOCK "VarFileInfo"
 BEGIN
 VALUE "Translation", 0x409, 1200
 END
END


  

  

  
  
  GNU Emacs
  

  

  

  
 
   
 
 
 
  
 
 
 
 
   



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

Compiling Heimdal

[Henry S. Thompson]

Trying to build heimdal to debug other problem.  Installed sources,
installed missing dependency of gettext-devel, hit a previously known
problem (?):

  
/usr/local/src/heimdal-1.5.3/heimdal-1.5.3-1/src/heimdal-1.5.3/lib/libedit/src/editline/readline.h:79:29:
 fatal error: sys/ttydefaults.h: No such file or directory
 #include 

This fixed it, maybe:

***
heimdal-1.5.3-1/src/heimdal-1.5.3/lib/libedit/src/editline/readline.h~
 2012-12-09 22:06:44.0 +
---
heimdal-1.5.3-1/src/heimdal-1.5.3/lib/libedit/src/editline/readline.h
 2014-04-09 16:47:29.174398900 +0100
***
*** 75,81 

  #ifndef CTRL
  #include 
! #if !defined(__sun) && !defined(__hpux) && !defined(_AIX)
  #include 
  #endif
  #ifndef CTRL
--- 75,81 

  #ifndef CTRL
  #include 
! #if !defined(__sun) && !defined(__hpux) && !defined(_AIX) &&
!defined(__CYGWIN__)
  #include 
  #endif
  #ifndef CTRL

Next problem:

/usr/local/src/heimdal-1.5.3/heimdal-1.5.3-1/build/lib/sqlite/.libs/libheimsqlite.a(sqlite3.o):
In function `winFullPathname':
/usr/src/debug/heimdal-1.5.3-1/lib/sqlite/sqlite3.c:34367: undefined
reference to `cygwin_conv_to_full_win32_path'

This appears to be a well-known problem -- how did this stuff get
shipped?  How did the heimdal package maintainers manage to build this
with the patches as shipped?  I'm confused.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: We need steenking patches (Re: Cygwin kill utility...)

[Christopher Faylor]

On Wed, Apr 09, 2014 at 09:55:51AM -0500, Steven Penny wrote:
>On Wed, Apr 9, 2014 at 12:51 AM, Christopher Faylor wrote:
>> Except for the lack of an advertised bugzilla link at the Cygwin web
>> page, Cygwin is like every one of the other projects hosted at
>> sourceware.org/gcc.gnu.org.  This includes thriving projects like gcc,
>> binutils, gdb, and others.  All of the developers in those projects were
>> able to figure out how to find CVS (svn, git) web information and,
>> eventually, check out their stuff.
>
>I see now you have Stockholm Syndrome with CVS. Perhaps you missed the 
>question,
>so I will repeat it:

I'm sorry.  You're absolutely right.  I completely missed your assertion
that web search of the code base was crucial to any contributions.

So, to rephrase for my clarification:

You went to the advertised link for the CVS web repository and didn't
see any way to search the repository.  You use the search functionality
that gitweb provides all of the time and think it would benefit Cygwin.

I'll see what I can do about upgrading to using a more modern view which
allows search.  I assume that the contribution floodgate will open.

>Where is the online search function for the mailing list and code base? With
>GitHub you can use this
>
>  http://github.com/svnpenn/bm/search?q=asdf
>
>and it will search all issues and code for a repository. Cygwin appears to have
>no web based way of searching either, besides a Google search. That is sad.

I'll once again point out that gdb, binutils, and gcc seem to get by
just fine without this.  And, maybe I missed something, but I don't see
search on sourceforge.net either.  Given that, I don't see how this can
be a huge barrier to entry.

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: Problem with default manifest when application provides its own

[Christopher Faylor]

On Wed, Apr 09, 2014 at 11:24:03AM -0400, Ken Brown wrote:
>I don't know if this report belongs here or if I should report a 
>binutils bug, but I'll start here.
>
>When building emacs-w32.exe with the current binutils, I end up with an 
>executable that won't run after it's stripped (at least on x86_64).  I 
>traced this to the fact that emacs-w32 comes with its own manifest.  My 
>understanding is that the emacs-w32 manifest should take precedence over 
>the Cygwin default manifest, but something's going wrong in this case.
>
>Here's a simple test case to illustrate the problem, using a slight 
>modification of the resource file that comes with emacs, and the 
>corresponding manifest (see attached).

Yes, this is definitely a binutils bug.  Would you mind filing a bug
report at:

https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

?

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: We need steenking patches (Re: Cygwin kill utility...)

[Christopher Faylor]

On Wed, Apr 09, 2014 at 12:37:10PM -0400, Christopher Faylor wrote:
>I'll see what I can do about upgrading to using a more modern view which
>allows search.  I assume that the contribution floodgate will open.

Actually, I guess I won't.  Here's what the web browsing software has to
say about searching:

## use_re_search: Enable regular expression search of files in a directory.
##
## SECURITY WARNING: Since a user can enter the regular expression, it
## is possible for them to enter an expression with many alternatives
## and a lot of backtracking. Executing that search over thousands of
## lines over dozens of files can easily tie up a server for a long
## period of time.  This option should only be used on sites with

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: We need steenking patches (Re: Cygwin kill utility...)

[Warren Young]

On 4/9/2014 08:55, Steven Penny wrote:

On Wed, Apr 9, 2014 at 12:51 AM, Christopher Faylor wrote:

I see now you have Stockholm Syndrome with CVS.


CVS sucks.  No new project should be started on CVS today.

HOWEVER:

If you think web code repository searching and a public bug tracker are 
primary barriers to contribution, you aren't being honest with yourself. 
 They are nice, but not necessary.


Neither is it necessary to switch everything off of a custom CVS system 
onto Github in order for Cygwin to succeed.  I give you proof by 
existence: ta daaa!


I say all of this as one who has expressed a wish for Cygwin to move to 
a better VCS at least once in the past; probably more than once.  The 
need to use CVS did not stop me from contributing a few small patches 
over the years.  It didn't even present a serious impediment.  Further, 
I managed to escape the experience without any PTSD. 


So yeah, it would be nice if Cygwin were on a modern VCS.  Personally, 
I'd like to see it on Fossil, since that has a built-in wiki and bug 
tracker.  Plus, it's worlds simpler than Git, and its model matches that 
of the Cygwin development structure better.


It would *also* be nice if you scraped up some fortitude tried working 
with Cygwin as you find it, instead of putting preconditions on others 
before you can start contributing.  It really is not that hard.



That is sad.


First world problem.

--
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: We need steenking patches (Re: Cygwin kill utility...)

[Steven Penny]

On Wed, Apr 9, 2014 at 11:37 AM, Christopher Faylor wrote:
> I'll once again point out that gdb, binutils, and gcc seem to get by
> just fine without this.  And, maybe I missed something, but I don't see
> search on sourceforge.net either.  Given that, I don't see how this can
> be a huge barrier to entry.

Noted. However this is an irrelevant conclusion. The fact that they are
successful does not mean Cygwin wont benefit from a search function.

On Wed, Apr 9, 2014 at 11:50 AM, Warren Young wrote:
> If you think web code repository searching and a public bug tracker are
> primary barriers to contribution, you aren't being honest with yourself.
> They are nice, but not necessary.

I am honest with myself. I, as everyone have limited time. I will not waste my
time with an archaic system and maintainers who fail to see the light of day
when there are better ways I can spend my time, example

  http://github.com/stars/svnpenn

--
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: We need steenking patches (Re: Cygwin kill utility...)

[Christopher Faylor]

On Wed, Apr 09, 2014 at 10:50:20AM -0600, Warren Young wrote:
>I say all of this as one who has expressed a wish for Cygwin to move to 
>a better VCS at least once in the past; probably more than once.  The 
>need to use CVS did not stop me from contributing a few small patches 
>over the years.  It didn't even present a serious impediment.  Further, 
>I managed to escape the experience without any PTSD. 

And, this gives me the opportunity to say a belated thank-you to you and
other people who have managed, despite all odds, to contribute.

Here's a knocked together list from the last 13-or-so years of Cygwin.

Chris January   John Bowman Ryan C. Gordon
Christian FrankeJohn Carey  Ryan Johnson
Christian Lestrade  Jon TURNEY  Salvador Eduardo Tropea
Christophe Jaillet  Kai Tietz   Sam Steingold
Christopher January KarellenScott Finneran
Conrad ScottKazuhiro FujiedaSergey Ivanov
Craig MacGregor Keith Seitz Sergey Okhapkin
Craig McGeachie Ken Brown   Silvio Laguzzi
Danny Smith Lars Munch  Sjors Gielen
Dave Korn   Lev Bishop  Steven O'Brien
David Billinghurst  Marco AtzeriSteve Osborn
David Huang Mark Bradshaw   Thomas Pfaff
David Jade  Mark Paulus Thomas Stalder
David MacMahon  Max Kaehn   Thomas Wolff
David Rothenberger  Michael Gorse   Tomas Ukkonen
Denis Excoffier Micha Nelissen  Tor Perkins
Diego Biurrun   Mikael Ylikoski Troy Curtiss
Dmitry TimoshkovMike Simons Vaclav Haisman
Doru Carastan   Mumit Khan  Václav Zeman
Dr. Volker Zell Nicholas S. Wourms  Vadim Egorov
Earl Chew   Nicholas Wourms Wu Yongwei
Earnie Boyd Nick Duffek Yaakov Selkowitz
Egor Duda   Norbert Schulze Yitzchak Scott-Thoennes
Eric Blake  N Stephens  Алексей Павлов
Ernie Coskrey

Apologies if I missed anyone.

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: We need steenking patches (Re: Cygwin kill utility...)

[Robert Pendell]

On Wed, Apr 9, 2014 at 10:55 AM, Steven Penny <...> wrote:
> On Wed, Apr 9, 2014 at 12:51 AM, Christopher Faylor wrote:
>> Except for the lack of an advertised bugzilla link at the Cygwin web
>> page, Cygwin is like every one of the other projects hosted at
>> sourceware.org/gcc.gnu.org.  This includes thriving projects like gcc,
>> binutils, gdb, and others.  All of the developers in those projects were
>> able to figure out how to find CVS (svn, git) web information and,
>> eventually, check out their stuff.
>
> I see now you have Stockholm Syndrome with CVS. Perhaps you missed the 
> question,
> so I will repeat it:
>
> Where is the online search function for the mailing list and code base? With
> GitHub you can use this
>
>   http://github.com/svnpenn/bm/search?q=asdf
>
> and it will search all issues and code for a repository. Cygwin appears to 
> have
> no web based way of searching either, besides a Google search. That is sad.
>

For the code no such function exists.  You will have to make do with
downloading the code from CVS and using local tools to grep and search
through it.  As it stands cgf has already mentioned the page that
tells you quite clearly how to download from CVS and (if you are a
contributor) how to upload as well.  The mailing list does have a
search function.  Go to the lists page (http://cygwin.com/lists.html)
and choose the list you want to search.  There is a nice search box on
each mailing list so that you can look for previous reports of an
issue.

Robert Pendell
A perfect world is one of chaos.

--
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: Problem with default manifest when application provides its own

[Corinna Vinschen]

On Apr  9 12:46, Christopher Faylor wrote:
> On Wed, Apr 09, 2014 at 11:24:03AM -0400, Ken Brown wrote:
> >I don't know if this report belongs here or if I should report a 
> >binutils bug, but I'll start here.
> >
> >When building emacs-w32.exe with the current binutils, I end up with an 
> >executable that won't run after it's stripped (at least on x86_64).  I 
> >traced this to the fact that emacs-w32 comes with its own manifest.  My 
> >understanding is that the emacs-w32 manifest should take precedence over 
> >the Cygwin default manifest, but something's going wrong in this case.
> >
> >Here's a simple test case to illustrate the problem, using a slight 
> >modification of the resource file that comes with emacs, and the 
> >corresponding manifest (see attached).
> 
> Yes, this is definitely a binutils bug.  Would you mind filing a bug
> report at:
> 
> https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Not required, Angelo already created a report for this a couple of
days ago:

  https://sourceware.org/bugzilla/show_bug.cgi?id=16807
  
Apparently there's still a bug when merging Windows resources.  There's
no fix for it yet.   Perhaps we should revert to binutils 2.23.x for
the time being, since there are a couple of problems in ld which still
need fixing.


Corinna

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


pgplcu_hKxWKr.pgp
Description: PGP signature

Re: We need steenking patches (Re: Cygwin kill utility...)

[Christopher Faylor]

On Wed, Apr 09, 2014 at 12:02:46PM -0500, Steven Penny wrote:
>On Wed, Apr 9, 2014 at 11:37 AM, Christopher Faylor wrote:
>> I'll once again point out that gdb, binutils, and gcc seem to get by
>> just fine without this.  And, maybe I missed something, but I don't see
>> search on sourceforge.net either.  Given that, I don't see how this can
>> be a huge barrier to entry.
>
>Noted. However this is an irrelevant conclusion. The fact that they are
>successful does not mean Cygwin wont benefit from a search function.

You clipped the part where I said "I'll see what I can do" and then offered
a followup as to why it may not be a good idea to have a search function.

I didn't say that a search function wouldn't be useful.  I said that it
can't be a huge barrier to entry given the fact that many popular
projects don't have that kind of functionality.

>On Wed, Apr 9, 2014 at 11:50 AM, Warren Young wrote:
>> If you think web code repository searching and a public bug tracker are
>> primary barriers to contribution, you aren't being honest with yourself.
>> They are nice, but not necessary.
>
>I am honest with myself. I, as everyone have limited time. I will not waste my
>time with an archaic system and maintainers who fail to see the light of day
>when there are better ways I can spend my time, example
>
>  http://github.com/stars/svnpenn

It's possible that a site like github has more bandwidth and compute
power than sourceware.org and doesn't have to worry about bogging down
the system with malicious search attacks.  We, unfortunately, do.  So,
while it is possible to turn on searches, it seems like I'd have to
personally take some time to fixing the viewvc code to mitigate any
damage from using searches.  That is more effort than I'm willing to go
to on one person's claim that this functionality is vitally necessary.

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

[PATCH] base-files-4.2-1: Change prompt if running with admin rights

[Christian Franke]

Thanks to Achim Gratz for adopting base-files.

Attached is an updated version of:
https://sourceware.org/ml/cygwin/2012-02/msg00806.html

Christian

diff -rup base-files-4.2-1.orig/etc/defaults/etc/bash.bashrc base-files-4.2-1/etc/defaults/etc/bash.bashrc
--- base-files-4.2-1.orig/etc/defaults/etc/bash.bashrc	2014-03-23 14:56:28.412930900 +0100
+++ base-files-4.2-1/etc/defaults/etc/bash.bashrc	2014-04-09 13:42:05.0 +0200
@@ -27,7 +27,7 @@
 export EXECIGNORE="*.dll"
 
 # Set a default prompt of: user@host and current_directory
-PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
+PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n'"${PS1a:-\\\$ }"
 
 # Uncomment to use the terminal colours set in DIR_COLORS
 # eval "$(dircolors -b /etc/DIR_COLORS)"
diff -rup base-files-4.2-1.orig/etc/defaults/etc/profile base-files-4.2-1/etc/defaults/etc/profile
--- base-files-4.2-1.orig/etc/defaults/etc/profile	2014-03-23 14:56:28.312931800 +0100
+++ base-files-4.2-1/etc/defaults/etc/profile	2014-04-09 12:59:43.0 +0200
@@ -109,6 +109,12 @@ else
   cd "${HOME}" || echo "WARNING: Failed attempt to cd into ${HOME}!"
 fi
 
+# Set PS1a if user has admin rights
+unset PS1a
+if [ -r /proc/registry/HKEY_LOCAL_MACHINE/SECURITY ]; then
+  PS1a="# "
+fi
+
 # Shell dependent settings
 profile_d ()
 {
@@ -135,15 +141,17 @@ if [ ! "x${BASH_VERSION}" = "x"  ]; then
   [ -f "/etc/bash.bashrc" ] && . "/etc/bash.bashrc"
 elif [ ! "x${KSH_VERSION}" = "x" ]; then
   typeset -l HOSTNAME="$(/usr/bin/hostname)"
-  [ "${PS1-null}" = "null" ] || PS1=$(print '\033]0;${PWD}\n\033[32m${USER}@${HOSTNAME} \033[33m${PWD/${HOME}/~}\033[0m\n$ ')
+  [ "${PS1-null}" = "null" ] || PS1=$(print '\033]0;${PWD}\n\033[32m${USER}@${HOSTNAME} \033[33m${PWD/${HOME}/~}\033[0m\n'"${PS1a:-\$ }")
 elif [ ! "x${ZSH_VERSION}" = "x" ]; then
   # zsh is in shell compatibility mode here, so we probably shouldn't do this
   profile_d zsh
+  [ "${PS1-null}" = "null" ] || PS1='(%n@%m)[%h] %~ '"${PS1a:-%% }"
 elif [ ! "x${POSH_VERSION}" = "x" ]; then
-  : # [ "${PS1-null}" = "null" ] || PS1="$ "
+  : # [ "${PS1-null}" = "null" ] || PS1="${PS1a:-\$ }"
 else
-  : # [ "${PS1-null}" = "null" ] || PS1="$ "
+  : # [ "${PS1-null}" = "null" ] || PS1="${PS1a:-\$ }"
 fi
+unset PS1a
 
 export PROFILEREAD PATH ORIGINAL_PATH MANPATH INFOPATH USER TMP TEMP PRINTER HOSTNAME PS1 SHELL tmp temp
 

--
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: Compiling Heimdal

[Yaakov (Cygwin/X)]

On 2014-04-09 10:59, Henry S. Thompson wrote:

Trying to build heimdal to debug other problem.  Installed sources,
installed missing dependency of gettext-devel, hit a previously known
problem (?):


You are missing BRs, namely libedit-devel and libsqlite3-devel.


Yaakov



--
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: Request for Junctions be treated consistently

[Corinna Vinschen]

On Apr  9 05:07, Linda Walsh wrote:
> Forgive me if this posts a 2nd time, but I haven't seen it come
> back after 6+ hours, so not sure where it went.
> 
> Corinna Vinschen wrote:
> >
> >No, it's not.  There's a major difference between mount points and
> >symlinks, which is, mount points are handled inside the kernel, while
> >symlinks are filesystem objects.  Reparse points are very certainly
> >filesystem objects.  And bind mounts in Cygwin are handled in the
> >"kernel" as well.  We can't add reparse points to the mount table
> >on the fly.
> ---
> Windows Internals V5, p965
> [snip]

I know how reparse points work, but thanks all the same.

> Theoretically, there should be a cental resource that would enable you to know
> all the reparse points that are associated with mountpoints that wouldn't have
> to be added "on the fly", but could be added to /etc/fstab on 
> cygwin-initialization.

I'm not sure how we came to discuss adding Windows mount points to
/etc/fstab, but either way, we don't want to do that.  It doesn't make
sense.  The Cygwin mount table provides a translation from Windows paths
to POSIX paths.  Adding the existing Windows device mounts doesn't add
any functionality.  Quite apart from the fact that Windows mount points
can change underneath Cygwin, so a fixed /etc/fstab containing Windows
device mounts is kind of moot anyway.

> But the one created with 'linkd' is called a Mount Point.

So because one Microsoft tool calls directory junctions "mount points",
they are mount points from a POSIX POV?

Again, we can't make the directory junctions POSIX mount points.  The
mount table is in memory and has a fixed, limited size.  The only choice
you have is to handle a directory junction as symlink or as plain
directory.  The latter is wrong since it's not a plain directory.  It's
just a file system object pointing to the real directory.  If you
handle it as directory, find and other recursive tools would enumerate
the directory twice, once via the real directory entry, once via the
reparse point.  And there would be no way at all from a POSIX POV to
distinguish the two.


Corinna

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


pgpPCunRVf67E.pgp
Description: PGP signature

Re: We need steenking patches (Re: Cygwin kill utility...)

[Steven Penny]

On Wed, Apr 9, 2014 at 12:13 PM, Christopher Faylor wrote:
> It's possible that a site like github has more bandwidth and compute
> power than sourceware.org and doesn't have to worry about bogging down
> the system with malicious search attacks.  We, unfortunately, do.  So,
> while it is possible to turn on searches, it seems like I'd have to
> personally take some time to fixing the viewvc code to mitigate any
> damage from using searches.  That is more effort than I'm willing to go
> to on one person's claim that this functionality is vitally necessary.

You dont want to take the time to fix it? You want to maintain the status quo?
Thats cool. But then dont go complaining on the mailing list when you are
unwilling to take steps to fix it.

I promise you complaining is going to do nothing other than make you feel better
(temporarily).

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

"mount -c /" in 64-bit win7 not persisting

[KARR, DAVID]

I haven't installed a new Cygwin in quite a while.  I'm doing it this morning 
on a new 64-bit Win7 box.

I typically set my cygdrive prefix to "/".  In the past, I believe I would do 
this once, and it wouldn't have to do it again, as it would persist somewhere.

Now, it appears as if this goes away as soon as that shell goes away.

I've checked some of the FAQs and did some searches, but I didn't find anything 
obvious.

What am I missing?

--
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: Compiling Heimdal

[Henry S. Thompson]

Yaakov (Cygwin/X) writes:

> On 2014-04-09 10:59, Henry S. Thompson wrote:
>> Trying to build heimdal to debug other problem.  Installed sources,
>> installed missing dependency of gettext-devel, hit a previously known
>> problem (?):
>
> You are missing BRs, namely libedit-devel and libsqlite3-devel.

Thanks!  Help me not waste time (mine and others') again, please, by
telling me how I should have known that/been able to find that out?

Maybe same question -- acronym failure: BR ?

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: Compiling Heimdal

[Achim Gratz]

Henry S. Thompson writes:
> Maybe same question -- acronym failure: BR ?

Build Requirement.


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

SD adaptation for Waldorf microQ V2.22R2:
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: 64-bit Heimdal/Cygwin, clock, daylight savings conundrum

[Henry S. Thompson]

ht writes:

> Corinna Vinschen writes:
>
>> On Apr  9 10:24, Henry S. Thompson wrote:
>>> [Clock behaving oddly/differently]
>>> Has something changed with system clock vs. hardware clock between 32-
>>> and 64-bit cygwin?  Or am I looking in the wrong place altogether?
>>
>> Hmm, maybe.  Apart from time_t being 64 bit (32 bit on i686), the
>> code for time handling is identical.  What's your $TZ set to?
>
> Europe/London in both cases.
>
> It occurs to me to check the Heimdal code to see if anything changed
> to enable 64-bit compilation. . .

Nah, much simpler than that :-( Four hours later, after abandoning the
attempt to compile heimdal from cygport and installing
heimdal-debuginfo, another hour of work with gdb establishes that by
default heimdal caches config info in a file in /tmp
(e.g. /tmp/krb5cc_1001) and despite a comment in the code which says
"We always try to remove the file", they don't.  And the cache
includes the offset of clock time from UTC.  So a cache which
persists over a change in, say DST, will be wrong wrt that!

Sigh.

Another time, I'll try to figure out why the cache isn't being deleted
-- _that_ might actually be a cygwin version issue.

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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 Heimdal/Cygwin, clock, daylight savings conundrum

[Henry S. Thompson]

ht writes:

> Another time, I'll try to figure out why [Heimdal's] cache isn't
> being deleted -- _that_ might actually be a cygwin version issue.

It's not.  It's a Heimdal logic bug, I think.  But if I'm right, it
should have bitten people using Heimdal under Linux before now.

I give up, back to real work.

If anyone else cares to investigate further, the recipe to reproduce
is simple:

  > kinit
  [your] Password: ...
  > date
  [date and time]
  > date [set it an hour ahead, plus a few seconds to allow for typing]
  > kinit
  [your] Password: ...
  > date
  > date [set it back to where it should be]
  > kinit
  [your] Password:
  kinit: krb5_get_init_creds: PREAUTH_FAILED
  > rm /tmp/krb5cc_1001 [or whatever]
  > kinit
  [your] Password:
  >

ht
-- 
   Henry S. Thompson, School of Informatics, University of Edinburgh
  10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: h...@inf.ed.ac.uk
   URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

--
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: [PATCH] base-files-4.2-1: Change prompt if running with admin rights

[Achim Gratz]

Christian Franke writes:
> Attached is an updated version of:
> https://sourceware.org/ml/cygwin/2012-02/msg00806.html

I'll put this on hold until the AD integration has landed in Cygwin
(which will require some larger changes anyway).

Generally I'd prefer to move such things that depend on personal
preferences like setting up prompts into profile.d where they are easier
to change and maintain independently from core system functionality.
Using the registry to check for administrative privileges is clever,
however I'm wondering why we shouldn't simply check via id (that's what
I'm doing personally at the moment).


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: Compiling Heimdal

[Yaakov (Cygwin/X)]

On 2014-04-09 12:47, Henry S. Thompson wrote:

On 2014-04-09 10:59, Henry S. Thompson wrote:

Trying to build heimdal to debug other problem.  Installed sources,
installed missing dependency of gettext-devel, hit a previously known
problem (?):


You are missing BRs, namely libedit-devel and libsqlite3-devel.


Thanks!  Help me not waste time (mine and others') again, please, by
telling me how I should have known that/been able to find that out?


The --with-sqlite3=/usr --with-libedit=/usr configure flags.


Yaakov


--
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: "mount -c /" in 64-bit win7 not persisting

[Corinna Vinschen]

On Apr  9 17:43, KARR, DAVID wrote:
> I haven't installed a new Cygwin in quite a while.  I'm doing it this morning 
> on a new 64-bit Win7 box.
> 
> I typically set my cygdrive prefix to "/".  In the past, I believe I would do 
> this once, and it wouldn't have to do it again, as it would persist somewhere.
> 
> Now, it appears as if this goes away as soon as that shell goes away.
> 
> I've checked some of the FAQs and did some searches, but I didn't find 
> anything obvious.
> 
> What am I missing?

The user's guide:

  http://cygwin.com/cygwin-ug-net/using.html#mount-table

Persisent mounting via mount(1) has been given up in favor of the
/etc/fstab file a long time ago (2009).


Corinna

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


pgpOy3C8DAm3x.pgp
Description: PGP signature

attention tar maintainer

[George Pearson]

Would it be possible to update the version of tar currently in cygwin?
The current version is 1.26, which, in the GNU project anyway, was 
released in March 2011.  I need a version with a bug fix done in Nov 
2011, so 1.27 or the latest (1.27-1) should do.

The bug fix fixes (among other things) the use of the -diff option with 
an archive created with -g (listed-incremental).  A related post from 
Sergey Poznyakoff, one of the GNU tar maintainers, will found here:

http://www.mail-archive.com/bug-tar%40gnu.org/msg03446.html

--
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: "mount -c /" in 64-bit win7 not persisting

[KARR, DAVID]

> -Original Message-
> Corinna Vinschen
> Sent: Wednesday, April 09, 2014 11:45 AM
> Subject: Re: "mount -c /" in 64-bit win7 not persisting
> 
> On Apr  9 17:43, KARR, DAVID wrote:
> > I haven't installed a new Cygwin in quite a while.  I'm doing it this
> morning on a new 64-bit Win7 box.
> >
> > I typically set my cygdrive prefix to "/".  In the past, I believe I would
> do this once, and it wouldn't have to do it again, as it would persist
> somewhere.
> >
> > Now, it appears as if this goes away as soon as that shell goes away.
> >
> > I've checked some of the FAQs and did some searches, but I didn't find
> anything obvious.
> >
> > What am I missing?
> 
> The user's guide:
> 
>   http://cygwin.com/cygwin-ug-net/using.html#mount-table
> 
> Persisent mounting via mount(1) has been given up in favor of the
> /etc/fstab file a long time ago (2009).

Curious.  I didn't think it was THAT long ago that I last installed Cygwin.  
That works, in any case.  Thanks.

Re: We need steenking patches (Re: Cygwin kill utility...)

[Christopher Faylor]

On Wed, Apr 09, 2014 at 12:43:25PM -0500, Steven Penny wrote:
>On Wed, Apr 9, 2014 at 12:13 PM, Christopher Faylor wrote:
>>It's possible that a site like github has more bandwidth and compute
>>power than sourceware.org and doesn't have to worry about bogging down
>>the system with malicious search attacks.  We, unfortunately, do.  So,
>>while it is possible to turn on searches, it seems like I'd have to
>>personally take some time to fixing the viewvc code to mitigate any
>>damage from using searches.  That is more effort than I'm willing to go
>>to on one person's claim that this functionality is vitally necessary.
>
>You dont want to take the time to fix it?  You want to maintain the
>status quo?  Thats cool.  But then dont go complaining on the mailing
>list when you are unwilling to take steps to fix it.

Any fix to viewvc was likely to be non-trivial.  It would require making
changes to unfamiliar code and, since we've had a lot of attacks on
sourceware.org over the years, I was leery about introducing another
vector.  So, given that you are a data point of one, it didn't seem
worth my time do spend a lot of time on this, despite your indulgenge in
the de rigeur internet style of claiming that your opinions are fact.

The good news is that when we eventually switch Cygwin to git we'll get
search functionality for free so it really is more worth my time to make
that switch than it is to investigate changing viewvc.  I'll try to get
to that in the next week or so.  I know that Corinna will be thrilled to
finally be on git.

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

[ANNOUNCEMENT] Updated: gawk-4.1.1-1

[Corinna Vinschen]

I've updated the gawk package to 4.1.1-1.

This is a new upstream release.

Changes from 4.1.0 to 4.1.1
---

1. The "stat" extension now includes a "devbsize" element which indicates
   the units for the "nblocks" element.

2. The extension facility now works on MinGW. Many of the extensions can be
   built and used directly.

3. A number of bugs in the pretty-printing / profiling code have been fixed.

4. Sockets and two-way pipes now work under MinGW.

5. The debugger now lists source code correctly under Cygwin.

6. Configuration and building with the Mac OS X libreadline should work now.

7. The -O option now works again.

8. The --include option, documented since 4.0, now actually works.

9. Infrastructure updated to automake 1.13.4, bison 3.0.2, and
   libtool 2.4.2.418.

10. The configure script now accepts a --disable-extensions option,
which disables checking for and building the extensions.

11. The VMS port has been considerably improved. In particular config.h
is now generated by a DCL script. Also, the extension facility works
and several of the extensions can be built and used. Currently, the
extension facility only works on Alpha and Itanium.

12. The API now provides functions pointers for malloc(), calloc(),
realloc() and free(), to insure that the same memory allocation
functions are always used. This bumps the minor version by one.

13. The printf quote flag now works correctly in locales with a different
decimal point character but without a thousands separator character.
If the thousands separator is a string, it will be correctly added
to decimal numbers.

14. The readfile extension now has an input parser that will read whole
files as a single record.

15. A number of bugs have been fixed. See the ChangeLog.


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

    *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

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

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

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

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

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

--
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: Request for Junctions be treated consistently

[Linda Walsh]

Corinna Vinschen wrote:

No, it's not.  There's a major difference between mount points and
symlinks, which is, mount points are handled inside the kernel, while
symlinks are filesystem objects.  Reparse points are very certainly
filesystem objects.  And bind mounts in Cygwin are handled in the
"kernel" as well.  We can't add reparse points to the mount table
on the fly.

---
Windows Internals V5, p965
[snip]


I know how reparse points work, but thanks all the same.

---
Then you know that they used to be regularly referred to
as 'mount points'.





Theoretically, there should be a cental resource that would enable you to know
all the reparse points that are associated with mountpoints that wouldn't have
to be added "on the fly", but could be added to /etc/fstab on 
cygwin-initialization.


I'm not sure how we came to discuss adding Windows mount points to
/etc/fstab,


It was in response to you saying that you can't add reparse points
to the mount table "on the fly" with the user space mapping of mounts being
held in fstab (usually).  But if that's not what you want, then I'm not sure
why you mentioned it.





But the one created with 'linkd' is called a Mount Point.


So because one Microsoft tool calls directory junctions "mount points",

---
And the most authoritative NT-Internals book -- also calls them
mount points.  The original literature referred to them as mount points
frequently -- it took finding a relatively 'unchanged tool', from that
era (fsutil) to find the original description.



they are mount points from a POSIX POV?


If MS was POSIX, then why would someone need cygwin?
That seems like a straw-man argument.  The point was that they were
designed and documented to act like mount points.




Again, we can't make the directory junctions POSIX mount points.  The
mount table is in memory and has a fixed, limited size.  The only choice
you have is to handle a directory junction as symlink or as plain
directory.  The latter is wrong since it's not a plain directory. 

---
Neither is it a plain symlink -- functionality is lost by treating
it that way, and there is no workaround (that I know of).
I don't see what the big problem is -- you allow the possibility
with mountvol of duplicate content.  Why not draw the line
at what MS calls mount points and what they call symlinks?


 It's
just a file system object pointing to the real directory.  If you
handle it as directory, find and other recursive tools would enumerate
the directory twice, once via the real directory entry, once via the
reparse point. And there would be no way at all from a POSIX POV to
distinguish the two.

---
An administrator using these options would take the same risk
they take on linux -- If they use tar or find where content is loaded
in multiple places, it will be enumerated in multiple places.
It takes administrative access to create them.  An unprivileged
user will get "access denied" or "insufficient privilege".

That provides for the feature, but restricts it to those who
can do full backups.

The alternative is broken or missing functionality.

It's not like I'm asking you to implement something new -- just
to treat 'JUNCTION' mountpoints equally whether they point
to a volume root or a volume-root+offset(path).

Linux went out of its way to provide a bunch of these features even
though they require some common sense when using them.

I think it unlikely that many people will use Junctions -- BECAUSE
they aren't as versatile as symlinks for most purposes.  But in
cases where you don't want cp-a or cp-r or a tar-xaf to create a
new copy of something -- when, currently, only 1 copy exists,
is *worse* than it creating full, redundant copies during
archive creation.

Why worse?: on extraction, the 'symlink' is overwritten
and only the new files in the tar are extracted into the new
directory.  All previous content is 'lost' (still at the original
location), but if you have 'terminfo' in /usr/share/terminfo, where,
"/usr/share",  is, by design, supposed to contain architecture-independent,
sharable content, then when you untar a manpage for 'anything',
the 'share' link is overwritten and you find your terminal functions
no longer work.

Even with the downside of creating or enumerating multiple copies of the
same source, it's still less drastic than the effects of disabling
local mounts.

That's why I asked for the functionality to be rolled-back to where
it still was seen as a directory -- consistent with 'mountvol' behavior.

It allows more flexibility.



--
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: [PATCH] base-files-4.2-1: Change prompt if running with admin rights

[Christian Franke]

Achim Gratz wrote:

Christian Franke writes:

Attached is an updated version of:
https://sourceware.org/ml/cygwin/2012-02/msg00806.html

I'll put this on hold until the AD integration has landed in Cygwin
(which will require some larger changes anyway).


Agree.


Generally I'd prefer to move such things that depend on personal
preferences like setting up prompts into profile.d where they are easier
to change and maintain independently from core system functionality.


The user could disable the root prompt by an "unset PS1a" in a profile.d 
script. The default behavior of Cygwin should IMO be close to 
traditional *nix behavior: Use a special (#) prompt if root(-like) 
privileges are effective.




Using the registry to check for administrative privileges is clever,
however I'm wondering why we shouldn't simply check via id (that's what
I'm doing personally at the moment).


For standard local administrator users, both would work to check for 
privilege elevation.


I used the registry check in the past because it only uses shell 
builtins and does not rely on specific SID->gid mappings in /etc/group.


Christian


--
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: json-c-0.11-2

[Yaakov (Cygwin/X)]

The following packages have been updated in the Cygwin distribution:

* libjson-c2-0.11-2
* libjson-c-common-0.11-2
* libjson-c-devel-0.11-2

JSON-C implements a reference counting object model that allows you to 
easily construct JSON objects in C, output them as JSON formatted 
strings and parse JSON formatted strings back into the C representation

of JSON objects.

This release includes Fedora's patchset, with a fix for CVE-2013-6370 
and CVE-2013-6371.


--

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

Re: [PATCH] base-files-4.2-1: Change prompt if running with admin rights

[Andrey Repin]

Greetings, Achim Gratz!

> Christian Franke writes:
>> Attached is an updated version of:
>> https://sourceware.org/ml/cygwin/2012-02/msg00806.html

> I'll put this on hold until the AD integration has landed in Cygwin
> (which will require some larger changes anyway).

> Generally I'd prefer to move such things that depend on personal
> preferences like setting up prompts into profile.d where they are easier
> to change and maintain independently from core system functionality.
> Using the registry to check for administrative privileges is clever,

But indirect.
It does not guarantee, that a user have administrator rights, only that it has
access to the specified registry key.

> however I'm wondering why we shouldn't simply check via id (that's what
> I'm doing personally at the moment).

Unless there's a way to ask "if we're a part of " or more
direct questions, it would involve much tinkering.
And I agree, that all tinkering needs to go into personal profile.


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

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: We need steenking patches (Re: Cygwin kill utility...)

[Andrey Repin]

Greetings, Steven Penny!

> On Wed, Apr 9, 2014 at 11:50 AM, Warren Young wrote:
>> If you think web code repository searching and a public bug tracker are
>> primary barriers to contribution, you aren't being honest with yourself.
>> They are nice, but not necessary.

> I am honest with myself. I, as everyone have limited time.

Seems like the limit on your time is very laxed.
For the time you wrote all the posts to this list, I've downloaded whole
Cygwin /cvs/src, found the offended string, patched the file, and it took me 2
days to rebuild it only because I wasn't familiar with out-of-the tree build
system. (Had to read building instructions first, yeah...)
Now, I'm a happy owner of a custom cygpath that doesn't annoy me with
insignificant warnings.

> I will not waste my time with an archaic system and maintainers who fail to
> see the light of day when there are better ways I can spend my time,

If all the point you want to make is that YOU don't want to spend time
supporting the toolset you're using daily, please save your energy.
My Care-o-meter shows negative readings.


--
WBR,
Andrey Repin (anrdae...@yandex.ru) 10.04.2014, <05:52>

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

[ANNOUNCEMENT] Updated: mercurial 2.9.2-1 -- Python based distributed version control (DVCS)

[Jari Aalto]

PACKAGE DESCRIPTION
===

Homepage: http://mercurial.selenic.com
License : GPL-2+

Distributed, efficient Python based source control system. Mercurial is
designed for efficient handling of very large distributed projects.

CHANGES SINCE LAST RELEASE
==

- Built for Python 2.7
- See http://mercurial.selenic.com/wiki/WhatsNew

INSTALL OR UPGRADE NOTES


Standard install.

For more information, see
http://mercurial.selenic.com/wiki/UpgradeNotes

CYGWIN INSTALLATION INFORMATION
===

To install this package, click on the "Install Cygwin now" link on the
 web page. This downloads setup.exe to your
system. Then, run setup and answer all of the questions. You'll find
the package listed in the "All" category. After installation, read the
documentation at directories:

/usr/share/doc//*
/usr/share/doc/Cygwin/.README

If you have questions or comments, please send them to the Cygwin
mailing list at .

CYGWIN-ANNOUNCE UNSUBSCRIBE INFO


This message has been sent to cygwin-announce list.

If you want to unsubscribe from the 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.com(at)cygwin.com

More information on unsubscribing can be found:

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

Please read *all* of the information on unsubscribing that is available
starting at the above 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