[ANNOUNCEMENT] Updated: mingw-runtime-3.16

[Chris Sutcliffe]

I've made a new version of the mingw-runtime available for download.
For a list of changes see:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/ChangeLog?rev=1.447&cvsroot=src

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

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org

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

Re: 1.7.0-58 fixes fork crash in 1.7-compiled app running on 1.5

[Corinna Vinschen]

On Aug 16 13:54, Martin Dorey wrote:
> -58 fixed a repeatable crash I was seeing in fork on every machine on
> which I ran a particular big hairy application
> (http://software.jessies.org/terminator).  Nothing new there, so I only
> spam you with my thanks because the machines in question were all
> running 1.5, though the executable was compiled with 1.7.  I didn't
> notice that symptom reported previously.  I'd got as far as proving that
> the problem didn't happen in -50 and did in -51 through -57 inclusive.
> I was hoping to pin the change in behavior more conclusively on Dave
> Korn's big memory allocation check-in of 2009-07-07, which I believe was
> between -50 and -51, before reporting it.  This is somewhat contrary to
> Corinna's statement in the -58 announcement that the problem was
> introduced in -49.

Hey, you're right!  It wasn't introduced in -49, rather in -51.  My
annoncement is lying there.


Corinna

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

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

Re: Cygwin-1.7 and 'None' [was Nobody] group

[Corinna Vinschen]

On Aug 17 00:09, Angelo Graziosi wrote:
> Gulp! In this context, the translation of 'Nessuno' should be 'None' and  
> NOT 'Nobody' :-(
>
> I resend correcting, for the sake of completeness... :-)
>
>
>  Messaggio Originale  
> Oggetto: Cygwin-1.7 and 'Nobody' group
>
>
> Usually, installing Cygwin, the file /etc/passwd contains things like:
>
> ...
> Administrator:unused_by_nt/2000/xp:500:513...
> pippo:unused_by_nt/2000/xp:1006:513...
> Guest:unused_by_nt/2000/xp:501:513
> ...
>
> so that 'ls -lrt' shows many files like this:
>
>-rw-r--r-- 1 pippo None 5858 Jul 28 17:04 emoticon.txt
>
> To 'avoid' seeing 'None', the strategy I have applied has been to change
>
> 513 --> 544 for Administrator
> 513 --> 545 for pippo
> 513 --> 546 for Guest
>
> (using the informations from /etc/group...)
>
> Now, on Cygwin-1.7, with the default /etc/passwd and /etc/group, I see,
> as administrator, many files like
>
>-rw-r--r-- 1 Administrator root 5858 Jul 28 17:04 foo.txt
>
> which looks right, and many files like
>
>-rw-r--r-- 1 Administrator None 5858 Jul 28 17:04 foo.txt

Which is right as well.  After all these years I was sure that now
everyone was aware of the fact that the group "None" or whatever it's
called in other languages is not a bug in Cygwin, but an actual Windows
group.  The group is a local machine group with the RID 513.  The full
SID should be in your /etc/group file since an entry for this group gets
created by `mkgroup -l'.

If you don't like the name of the group, just change the name to
something you like more in /etc/group.  Better you don't give it the
same name as another group, otherwise you'll never know which group the
file is really owned by, unless you call `ls -ln'.


Corinna

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

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

Re: Cygwin-1.7 and 'None' [was Nobody] group

[Angelo Graziosi]

Corinna Vinschen wrote:

After all these years I was sure that now everyone was aware of the
fact that the group "None" or whatever it's called in other languages
is not a bug in Cygwin, but an actual Windows group.


I didn't mean a bug, but a different behavior under 1.7.

I have noticed that the following files belong to Nessuno (== None):

$ find /cygdrive/c/cygwin-2/ -group Nessuno -ls
[...] /cygdrive/c/cygwin-2/cygdrive
/cygdrive/c/cygwin-2/dev
/cygdrive/c/cygwin-2/dev/fd -> /proc/self/fd
/cygdrive/c/cygwin-2/dev/mqueue
/cygdrive/c/cygwin-2/dev/shm
/cygdrive/c/cygwin-2/dev/stderr -> /proc/self/fd/2
/cygdrive/c/cygwin-2/dev/stdin -> /proc/self/fd/0
/cygdrive/c/cygwin-2/dev/stdout -> /proc/self/fd/1
/cygdrive/c/cygwin-2/etc/bash.bashrc
/cygdrive/c/cygwin-2/etc/DIR_COLORS
/cygdrive/c/cygwin-2/etc/fstab
/cygdrive/c/cygwin-2/etc/fstab.d

/cygdrive/c/cygwin-2/etc/hosts ->
/cygdrive/c/WINDOWS/system32/drivers/etc/hosts

/cygdrive/c/cygwin-2/etc/mtab -> /proc/mounts

/cygdrive/c/cygwin-2/etc/networks ->
/cygdrive/c/WINDOWS/system32/drivers/etc/networks

/cygdrive/c/cygwin-2/etc/profile

/cygdrive/c/cygwin-2/etc/protocols ->
/cygdrive/c/WINDOWS/system32/drivers/etc/protocol

/cygdrive/c/cygwin-2/etc/services ->
/cygdrive/c/WINDOWS/system32/drivers/etc/services

/cygdrive/c/cygwin-2/etc/skel
/cygdrive/c/cygwin-2/etc/skel/.bashrc
/cygdrive/c/cygwin-2/etc/skel/.bash_profile
/cygdrive/c/cygwin-2/etc/skel/.inputrc
/cygdrive/c/cygwin-2/lib/terminfo -> /usr/share/terminfo
/cygdrive/c/cygwin-2/usr/share/info/dir
/cygdrive/c/cygwin-2/usr/share/misc/man.conf

Now, since them have been created by setup-1.7.exe (called from
Start/Run), I would expect that, after the changes 513 --> 544 etc. in
/etc/passwd, they belong to Administrators etc. (as the do in Cygwin-1.5
and for the other files in 1.7). Evidently, my logic, here, is wrong.

I would tempted to change them manually:

$ find /cygdrive/c/cygwin-2/ -group Nessuno | xargs chgrp -h \
Administrators


Thanks,
   Angelo.

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Corinna Vinschen]

On Aug 16 12:55, Charles Wilson wrote:
> Colin Harrison wrote:
> > I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
> > (1.1.11 run + your patch)
> > bForceUsingPipes = (os_version >= 0x0501); 
> 
> #$!%#
> 
> > I made this = FALSE to fix for 2003 server..not tried on Windows 7.
> > I'm still testing (run built with MinGW) so this is maybe a clue or just a
> > bodge fix!
> > One failing CUI was plink (an ssh client from PuTTY).
> > 
> > I'll try and get back with more detail or a better fix!
> 
> I'd appreciate it.
> 
> I'm starting to suspect that there is no good mechanism to automatically
> DTRT here for [cygwin-1.5/cygwin-1.7/mingw] x
> [w95/98/Me/NT/2k/XP/Vista/Svr200x/W7] x [every app known to mankind],
> and that a command line option to override the internal heuristics may
> be required.  Don't you just love Windows?
> 
> FWIW, I've added run to the cygwin-apps repository, here:
> 
> cvs -z3 -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co run
> 
> but you'll need to 'autoreconf -fvi' before building it.

I had the idea to redirect to NUL: for the inferior process, so I
applied the below patch.  Don't ask for a reason, it was just a hunch
that this might work.

Redirecting to /dev/null works fine for me on W7.  With this patch, XWin
starts as expected when called from the `run startxwin.bat' shortcut,
xterm, gvim, xeyes all start fine, and, that's most interesting, urxvt
starts fine as well, without constantly taking 100% CPU.  And yes,
*this* time I made sure that the shortcut actually calls urxvt-X via
run.  In no case I have a flickering console window.

I'm not sure this a generic enough solution, there's probable more
necessary.  However, would others be so kind to test this on non-W7
systems as well as with other applications like emacs?

Btw., the patch also disables the calls to FreeConsole/AttachConsole on
W7 because they are useless, as I noted in one of my mails.


Corinna


* run.c (configure_startupinfo): Open handles to "NUL:" and
redirect child processes stdio handles to them if no pipes
have to be set up.
(start_child): Remove Windows 7 AttachConsole workaround.
Set creation flag always to 0.  Set bForceUsingPipes always to
FALSE unless in DEBUG_FORCE_PIPES mode.


Index: src/run.c
===
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.8
diff -u -p -r1.8 run.c
--- src/run.c   16 Aug 2009 03:26:42 -  1.8
+++ src/run.c   17 Aug 2009 08:40:16 -
@@ -285,12 +285,13 @@ BOOL configure_startupinfo(STARTUPINFO* 
 
 ZeroMemory (psi, sizeof (STARTUPINFO));
 psi->cb = sizeof (STARTUPINFO);
-psi->hStdInput   = GetStdHandle(STD_INPUT_HANDLE);
-psi->hStdOutput  = GetStdHandle(STD_OUTPUT_HANDLE);
-psi->hStdError   = GetStdHandle(STD_ERROR_HANDLE);
 psi->dwFlags = STARTF_USESHOWWINDOW | STARTF_USESTDHANDLES;
 psi->wShowWindow = SW_HIDE;
 
+handle_attrs.nLength = sizeof(SECURITY_ATTRIBUTES);
+handle_attrs.bInheritHandle = TRUE;
+handle_attrs.lpSecurityDescriptor = NULL;
+
 /* foo() is some magic mechanism for determining that the HANDLEs 
  * returned by GetStdHandle() are from a console, and not redirected
  * or ptys of some sort.  If we have such a mechanism, then the 
@@ -310,6 +311,16 @@ BOOL configure_startupinfo(STARTUPINFO* 
  */
 if (!bForceUsingPipes && bHaveInvisConsole)
 {
+   hpStdInput[0] = CreateFile ("NUL:", GENERIC_READ | GENERIC_WRITE,
+   FILE_SHARE_VALID_FLAGS, &handle_attrs,
+   OPEN_EXISTING, 0, NULL);
+   hpStdOutput[1] = CreateFile ("NUL:", GENERIC_READ | GENERIC_WRITE,
+   FILE_SHARE_VALID_FLAGS, &handle_attrs,
+   OPEN_EXISTING, 0, NULL);
+   psi->hStdInput   = hpStdInput[0];
+   psi->hStdOutput  = hpStdOutput[1];
+   psi->hStdError   = hpStdOutput[1];
+
*bUsingPipes = FALSE;
return TRUE;
 }
@@ -317,10 +328,6 @@ BOOL configure_startupinfo(STARTUPINFO* 
 /* otherwise, set up pipes */
 *bUsingPipes = TRUE;
 
-handle_attrs.nLength = sizeof(SECURITY_ATTRIBUTES);
-handle_attrs.bInheritHandle = TRUE;
-handle_attrs.lpSecurityDescriptor = NULL;
-
 /* create a pipe for child's stdin.  Don't allow child to */
 /* inherit the write end of the pipe. */
 CreatePipe (&hpStdInput[0], &hpStdInput[1], &handle_attrs, 0);
@@ -353,34 +360,9 @@ int start_child(char* cmdline, int wait_
BOOL bForceUsingPipes = FALSE;
HANDLE hToChild, hFromChild;
HANDLE hToParent, hFromParent;
-   BOOL WINAPI (*AttachConsoleFP)(DWORD) = NULL;
-   HWND WINAPI (*GetConsoleWindowFP)(VOID) = NULL;
-   DWORD creationFlags = 0;
 
setup_win_environ();
 
-   /* Work around bug in Windows 7. For Vista and below, continue
-* to use the more reliable setup_invisible_

Re: rxvt slow to get the prompt if another rxvt is already open on windows 7 64bit

[Corinna Vinschen]

On Aug 16 17:11, Andy Koppe wrote:
> 2009/8/14 Corinna Vinschen:
> >> I tried it again briefly last night. It only happened when logged in
> >> as an administrator, not as a limited user. That's with UAC enabled.
> >> Didn't try disabling. Reproduced both with 'rxvt' and 'mintty -u', and
> >> timed the delay to about 15 seconds.
> >>
> >> Trying to investigate further now, I can no longer reproduce it.
> >> That's without having changed anything, knowingly anyway.
> >
> > What you could do is this.  Build a Cygwin DLL without optimization so
> > that it's easily debuggable and install the cygwin1.dbg file alongside
> > of the DLL.  Since the delay is so long, 15 secs, you could have enough
> > time to attach to the process via gdb and examine the thread call
> > stacks.  Maybe that gives us a clue.
> 
> I keep on trying it every now and then, but haven't been able to
> reproduce the issue again.
> 
> Sorry,

No worries.  Thanks for trying.


Corinna

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

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

Re: Cygwin-1.7 and 'None' [was Nobody] group

[Corinna Vinschen]

On Aug 17 10:47, Angelo Graziosi wrote:
> Now, since them have been created by setup-1.7.exe (called from
> Start/Run), I would expect that, after the changes 513 --> 544 etc. in
> /etc/passwd, they belong to Administrators etc. (as the do in Cygwin-1.5
> and for the other files in 1.7). Evidently, my logic, here, is wrong.

Setup-1.7 creates the files with POSIX-like permissions and other group
membership.  Other than that, changing /etc/passwd does obviously not
change the actual group membership of a file.


Corinna

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

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Colin Harrison]

Hi,

Corinna wrote:
> However, would others be so kind to test this on non-W7 systems

I built run from cvs + Corinna's patch with MinGW (for native Windows) and
tested on Windows 2003 server.
Tests OK for me..my Big List Of Dodgy CUIs appear to be happy bunnies now :)

Thanks,
Colin


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

Build Cygwin packages

[Bruno Galindro da Costa]

Hi!

    How can I build Cygwin packages?

--
Att.
Bruno Galindro da Costa
bruno.galin...@gmail.com
Florianópolis - SC

--
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: cppcheck-1.35-1

[Chris Sutcliffe]

Version 1.35-1 of cppcheck has been uploaded, following the upstream release.

cppcheck is a tool for static C/C++ code analysis.  It tries to detect
bugs that your C/C++ compiler don't see.
The goal is no false positives.

cppcheck is versatile. You can check non-standard code that includes
various compiler extensions, inline assembly code, etc.

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

-- 
Chris Sutcliffe
http://emergedesktop.org

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Ken Brown]

On 8/17/2009 4:47 AM, Corinna Vinschen wrote:

On Aug 16 12:55, Charles Wilson wrote:

Colin Harrison wrote:

I am getting a stderr/pipe problem with some CUI's ~line 398 in run.c
(1.1.11 run + your patch)
bForceUsingPipes = (os_version >= 0x0501); 

#$!%#


I made this = FALSE to fix for 2003 server..not tried on Windows 7.
I'm still testing (run built with MinGW) so this is maybe a clue or just a
bodge fix!
One failing CUI was plink (an ssh client from PuTTY).

I'll try and get back with more detail or a better fix!

I'd appreciate it.

I'm starting to suspect that there is no good mechanism to automatically
DTRT here for [cygwin-1.5/cygwin-1.7/mingw] x
[w95/98/Me/NT/2k/XP/Vista/Svr200x/W7] x [every app known to mankind],
and that a command line option to override the internal heuristics may
be required.  Don't you just love Windows?

FWIW, I've added run to the cygwin-apps repository, here:

cvs -z3 -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co run

but you'll need to 'autoreconf -fvi' before building it.


I had the idea to redirect to NUL: for the inferior process, so I
applied the below patch.  Don't ask for a reason, it was just a hunch
that this might work.

Redirecting to /dev/null works fine for me on W7.  With this patch, XWin
starts as expected when called from the `run startxwin.bat' shortcut,
xterm, gvim, xeyes all start fine, and, that's most interesting, urxvt
starts fine as well, without constantly taking 100% CPU.  And yes,
*this* time I made sure that the shortcut actually calls urxvt-X via
run.  In no case I have a flickering console window.

I'm not sure this a generic enough solution, there's probable more
necessary.  However, would others be so kind to test this on non-W7
systems as well as with other applications like emacs?


Works for me on XP SP3.  I tested the 'run startxwin.bat' shorcut, the 
'run startemacs.bat' shortcut that I described earlier in the thread, 
and a shortcut that contains 'C:\cygwin-1.7\bin\run.exe -p /usr/bin bash 
-l -c "emacs --display=127.0.0.1:0.0"'.  With both methods of starting 
emacs, it starts as expected and runs without performance problems.


Thanks!

Ken

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Corinna Vinschen]

On Aug 17 08:18, Ken Brown wrote:
> On 8/17/2009 4:47 AM, Corinna Vinschen wrote:
>> I'm not sure this a generic enough solution, there's probable more
>> necessary.  However, would others be so kind to test this on non-W7
>> systems as well as with other applications like emacs?
>
> Works for me on XP SP3.  I tested the 'run startxwin.bat' shorcut, the  
> 'run startemacs.bat' shortcut that I described earlier in the thread,  
> and a shortcut that contains 'C:\cygwin-1.7\bin\run.exe -p /usr/bin bash  
> -l -c "emacs --display=127.0.0.1:0.0"'.  With both methods of starting  
> emacs, it starts as expected and runs without performance problems.

Oh well.  The above shortcut as well as your startxwin.bat script don't
work on W7.  Only a shortcut like this

  C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0

works and allows to start emacs.


Sigh,
Corinna

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

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Charles Wilson]

Corinna Vinschen wrote:

> Oh well.  The above shortcut as well as your startxwin.bat script don't
> work on W7.  Only a shortcut like this
> 
>   C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0
> 
> works and allows to start emacs.

So, here's another approach that seems to work for me, based on the
earlier conversation about treating GUI apps specially.  It's not nearly
as clean as Corinna's, but maybe it will work also on W7. No ChangeLog
yet...

Apply to current CVS.

--
Chuck

Index: src/run.c
===
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.8
diff -u -p -r1.8 run.c
--- src/run.c	16 Aug 2009 03:26:42 -	1.8
+++ src/run.c	17 Aug 2009 15:35:54 -
@@ -45,6 +45,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "run.h"
 
@@ -63,6 +64,9 @@ WinMainCRTStartup() { mainCRTStartup(); 
 DWORD os_version;
 char buffer[1024];
 
+static BOOL target_is_gui(const char* target_path);
+static void setup_win_environ(void);
+
 int WINAPI
 WinMain (HINSTANCE hSelf, HINSTANCE hPrev, LPSTR cmdline, int nShow)
 {
@@ -165,11 +169,61 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
Trace(("exec\t%s\nexecname\t%s\nexecpath\t%s\n",
  exec,execname,execpath));
 
-   wait_for_child = build_cmdline(cmdline2,exec,argc,argv);
+   wait_for_child = build_cmdline(cmdline2,exec,&argc,argv);
Trace((cmdline2));
 
xemacs_special(exec);
-   ret_code = start_child(cmdline2,wait_for_child);
+   if (target_is_gui (exec))
+ {
+   /* much simpler if target is gui, because we don't
+* actually need to worry about consoles, stdio
+* handles, etc.  If -wait, then delegate to _spawnv,
+* since we have the argv array. However, because
+* _spawnv (_P_NOWAIT) doesn't work reliably on
+* cygwin, use a lobotomized version of CreateProcess
+* (but still don't worry about handles or consoles).
+*/
+   setup_win_environ();
+   if (wait_for_child)
+ {
+   Trace(("gui wait for child: %s", exec));
+   /* ret_code is the child exit status for P_WAIT */
+   ret_code = _spawnv (_P_WAIT, exec, argv);
+   if (ret_code < 0)
+ error("could not start %s", exec);
+   return (int)ret_code;
+ }
+   else
+ {
+   STARTUPINFO start;
+   PROCESS_INFORMATION child;
+   ZeroMemory( &child, sizeof(PROCESS_INFORMATION) );
+   ZeroMemory (&start, sizeof (STARTUPINFO));
+   start.cb = sizeof (STARTUPINFO);
+   Trace(("Launch GUI target, async (cygwin-1.5): %s", cmdline2));
+   ret_code = CreateProcess (NULL,
+   cmdline2,/* command line*/
+   NULL,/* process security attributes */
+   NULL,/* primary thread security attributes  */
+   FALSE,   /* handles are NOT inherited,  */
+   0,   /* creation flags  */
+   NULL,/* use parent's environment*/
+   NULL,/* use parent's current directory  */
+   &start,  /* STARTUPINFO pointer */
+   &child); /* receives PROCESS_INFORMATION*/
+   if (ret_code == 0)
+ {
+   Trace(("getlasterror: %d\n", GetLastError()));
+   error("could not start %s", exec);
+ }
+   return 0;
+ }
+ }
+   else
+ {
+   Trace(("Launch non-GUI target"));
+   ret_code = start_child(exec, cmdline2,wait_for_child);
+ }
if (compact_invocation)
   for (i = 1; i < argc; i++) /* argv[0] was not malloc'ed */
  free(argv[i]);
@@ -179,6 +233,22 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
return (int) ret_code;
 }
 
+static BOOL target_is_gui(const char* target_path)
+{
+  char p, e;
+  DWORD_PTR d =
+  SHGetFileInfoA(target_path,/* LPCSTR pszPath */
+ 0,  /* DWORD dwFileAttributes */
+ NULL,   /* SHFILEINFO *psfi   */
+ 0,  /* UINT cbFileInfo*/
+ SHGFI_EXETYPE); /* UINT uFlags*/
+
+  p = LOBYTE (LOWORD (d));
+  e = HIBYTE (LOWORD (d));
+  Trace(("p=%c\ne=%c\nv=%d\n", p, e, HIWORD(d)));
+  return ( (((p=='P') || (p=='N')) && (e=='E')) && (HIWORD(d) != 0) );
+}
+
 /* Copy cygwin environment variables to the Windows environment if they're not
  * already there. */
 static void setup_win_environ(void)
@@ -342,7 +412,7 @@ BOOL configure_startupinfo(STARTUPINFO* 
 
 return TRUE;
 }
-int start_child(char* cmdline, int wait_for_child)
+int start_child(char *exec, char* cmdline, int wait_for_child)
 {
STARTUPINFO start;
PROCESS_INFORMATION child;
@@ -392,9 +462,10 @@ int start_child(char* cmdline, int wait_
 */
bHaveInvisConsole = os_version >= 0x0601 ? TRUE : setup_invisible_c

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Corinna Vinschen]

On Aug 17 11:36, Charles Wilson wrote:
> Corinna Vinschen wrote:
> 
> > Oh well.  The above shortcut as well as your startxwin.bat script don't
> > work on W7.  Only a shortcut like this
> > 
> >   C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0
> > 
> > works and allows to start emacs.
> 
> So, here's another approach that seems to work for me, based on the
> earlier conversation about treating GUI apps specially.  It's not nearly
> as clean as Corinna's, but maybe it will work also on W7. No ChangeLog
> yet...
> 
> Apply to current CVS.

No go, sorry.  The result is identical as with my patch.  Everything
works, except Ken's startemacs.bat and the `run bash -c emacs' invocation.


Corinna

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

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Robin Walker]

--On 17 August 2009 15:57 +0200 Corinna Vinschen wrote:


The [...] as well as your startxwin.bat script don't work on W7.


On any NT-class Windows, calling a *.bat file causes a 16-bit sub-system to 
be spawned, and the .bat file is interpreted within the 16-bit command 
interpreter.


Given that Cygwin 1.7 no longer supports Windows 9x systems, it would 
probably make sense to convert as many .bat files as possible to .cmd 
files, so that they run within the normal 32-bit command interpreter.


Does the startxwin.bat script work when it is renamed startxwin.cmd ?

--
Robin Walker


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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Colin Harrison]

Hi,

Chuck wrote:
> So, here's another approach that seems to work for me

I needed to #include  to compile this with MinGW (to find
SHGFI_EXETYPE)

However, then I get (on Windows 2003) an 'Unable to write to standard error'
with my CUI plink.

Thanks,
Colin



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

RE: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Stephan Mueller]

Robin Walker wrote:
" --On 17 August 2009 15:57 +0200 Corinna Vinschen wrote:
" > The [...] as well as your startxwin.bat script don't work on W7.
" On any NT-class Windows, calling a *.bat file causes a 16-bit sub-system to 
" be spawned, and the .bat file is interpreted within the 16-bit command 
" interpreter.
"
" Given that Cygwin 1.7 no longer supports Windows 9x systems, it would 
" probably make sense to convert as many .bat files as possible to .cmd 
" files, so that they run within the normal 32-bit command interpreter.
"
" Does the startxwin.bat script work when it is renamed startxwin.cmd ?

This is certainly an interesting question, but I'm not sure I believe the
preceding claim.  In my main environment (shared by a few thousand other
users) we've gotten (for all the usual historical reasons) to a place
where we live in a cmd.exe world, yet most of our batch scripts have a
.bat extension.  We use NT-class Windows.  I have never seen the 16-bit
subsystem invoked here.  Other groups prefer the .cmd extension, but
I have, in many years, not seen a technical difference.

stephan(speaking for myself only, not my employer);


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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Ken Brown]

On 8/17/2009 12:36 PM, Corinna Vinschen wrote:

On Aug 17 11:36, Charles Wilson wrote:

Corinna Vinschen wrote:


Oh well.  The above shortcut as well as your startxwin.bat script don't
work on W7.  Only a shortcut like this

  C:\cygwin-1.7\bin\run.exe emacs-X11 --display=127.0.0.1:0.0

works and allows to start emacs.

So, here's another approach that seems to work for me, based on the
earlier conversation about treating GUI apps specially.  It's not nearly
as clean as Corinna's, but maybe it will work also on W7. No ChangeLog
yet...

Apply to current CVS.


No go, sorry.  The result is identical as with my patch.  Everything
works, except Ken's startemacs.bat and the `run bash -c emacs' invocation.


Is this really specific to emacs, or is there a problem on W7 with `run 
bash -c ...'?


Ken

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

RE: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Robin Walker]

--On 17 August 2009 17:52 + Stephan Mueller wrote:


Robin Walker wrote:
" On any NT-class Windows, calling a *.bat file causes a 16-bit
sub-system to  " be spawned, and the .bat file is interpreted within the
16-bit command  " interpreter.
"
" Given that Cygwin 1.7 no longer supports Windows 9x systems, it would
" probably make sense to convert as many .bat files as possible to .cmd
" files, so that they run within the normal 32-bit command interpreter.
"
" Does the startxwin.bat script work when it is renamed startxwin.cmd ?

This is certainly an interesting question, but I'm not sure I believe the
preceding claim.


OK, I stand corrected.  It looks as if something that bit me more years ago 
than I can remember is not in fact the problem that I mis-remembered it to 
be.


Sorry for wasting your time!

--
Robin Walker

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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Christopher Faylor]

On Mon, Aug 17, 2009 at 07:16:17PM +0100, Robin Walker wrote:
>--On 17 August 2009 17:52 + Stephan Mueller wrote:
>
>> Robin Walker wrote:
>> " On any NT-class Windows, calling a *.bat file causes a 16-bit
>> sub-system to  " be spawned, and the .bat file is interpreted within the
>> 16-bit command  " interpreter.
>> "
>> " Given that Cygwin 1.7 no longer supports Windows 9x systems, it would
>> " probably make sense to convert as many .bat files as possible to .cmd
>> " files, so that they run within the normal 32-bit command interpreter.
>> "
>> " Does the startxwin.bat script work when it is renamed startxwin.cmd ?
>>
>> This is certainly an interesting question, but I'm not sure I believe the
>> preceding claim.
>
>OK, I stand corrected.  It looks as if something that bit me more years ago 
>than I can remember is not in fact the problem that I mis-remembered it to 
>be.
>
>Sorry for wasting your time!

Too bad.  It was an interesting supposition, at least.

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: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Charles Wilson]

Colin Harrison wrote:
> Hi,
> 
> Chuck wrote:
>> So, here's another approach that seems to work for me
> 
> I needed to #include  to compile this with MinGW (to find
> SHGFI_EXETYPE)
> 
> However, then I get (on Windows 2003) an 'Unable to write to standard error'
> with my CUI plink.

Okay, so here's another idea:


In setup_invisible_console(), there is:

  /* until we have a mechanism of determining whether a given HANDLE
* returned by GetStdHandles actually derives from a console,
* unconditionally call FreeConsole() on all OSes under all conditions.
* See comments in configure_startupinfo().
*/
   FreeConsole();



And in configure_startupinfo():

/* foo() is some magic mechanism for determining that the HANDLEs
 * returned by GetStdHandle() are from a console, and not redirected
 * or ptys of some sort.  If we have such a mechanism, then the
 * unconditional FreeConsole() at the top of setup_invisible_console()
 * should be removed.
 */
/*
if (!bForceUsingPipes && foo())
{
   *bUsingPipes = FALSE;
   return TRUE;
}
*/


So, does anybody have any suggestions for how to implement foo()?  I'm
guessing that some of the problems we're seeing are related to the fact
that some target apps really expect to have true handles to $CONOUT etc,
and get perturbed when they are given something else.

If we already HAVE true console handles, then we shouldn't FreeConsole
and try to recreate our own...

--
Chuck


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

Re: UNZIP: Why don't .exe/.dll files get eXecute privs?

[Warren Young]

Jim Reisert AD1C wrote:


I can't control how the ZIP file gets created, but I do expect that
when I unzip a file, that the .exe will actually execute without
having to change permissions!


I guess it comes down to a question of whether *.exe implies chmod +x. 
It doesn't in any "native" *ix packaging format, like tar or cpio. 
Doing this would thus be a break from expected behavior for some.  I can 
see your point, Jim, but I don't think the answer is obvious.


Should unzip do this for *.sh?  *.pl?  *.insert-yfl-extension?  Before 
you answer, have you looked at a programming language list lately? 
There are "only" about 750 on this index page in Wikipedia:


http://en.wikipedia.org/wiki/List_of_programming_languages

I've seen other lists that put the count at more like 2,500.  Obviously 
we don't have to handle them all, as some may re-use extensions, and 
others aren't directly executable from a shell, like C code.  We're 
still left with hundreds, surely?  If we don't have to handle them all, 
what's the razor that describes which get this special treatment and 
which don't?  How do you deal with conflicts among file name extensions?


Now throw in shebang magic.  Does unzip have to set the executable bit 
on files with a shebang line at the start?  What if it's binary data 
that just happens to start with those two bytes?  Now does unzip have to 
parse the line and check for the existence of an interpreter?


Should unzip have this special-case code only if it doesn't see an ACL, 
or does it override explicit settings?


This isn't Cygwin-specific.  I use a package on Linux that uses zip for 
its distributed binary packages (yeah, yech, I know), and has a bunch of 
chmod hackery in its post-unpack installation instructions.


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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Charles Wilson]

Charles Wilson wrote:

> If we already HAVE true console handles, then we shouldn't FreeConsole
> and try to recreate our own...

OK, how about this?  Seems to work on Vista(cyg1.5, cyg1.7, mingw) x
gui/cui/bat.

The basic idea is to try and re-use whatever console is available, if
any, when run is started.  If this is the invisible console created by
cygwin as part of process startup, great. If it is inherited from the
calling window, fine.  But never try to explicitly hide the console if
it already exists (that way, you can call 'run foo' from a cmd box
without it disappearing on you).

Also, if creating a new console, then do it in the parent (run) process
and hide it there -- even for W7, by using the message-only trick --
instead of attaching to the child's console and manipulating it after
the fact.

I *think* this slight refactoring will allow us to add any additional
tweaks needed by W7 with only small, localized changes, so I'm hopeful
that this patch can actual be checked in even if it is not perfect.

--
Chuck
Index: src/run.c
===
RCS file: /cvs/cygwin-apps/run/src/run.c,v
retrieving revision 1.8
diff -u -p -r1.8 run.c
--- src/run.c	16 Aug 2009 03:26:42 -	1.8
+++ src/run.c	17 Aug 2009 22:33:23 -
@@ -40,11 +40,13 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "run.h"
 
@@ -63,6 +65,9 @@ WinMainCRTStartup() { mainCRTStartup(); 
 DWORD os_version;
 char buffer[1024];
 
+static BOOL target_is_gui(const char* target_path);
+static void setup_win_environ(void);
+
 int WINAPI
 WinMain (HINSTANCE hSelf, HINSTANCE hPrev, LPSTR cmdline, int nShow)
 {
@@ -165,11 +170,61 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
Trace(("exec\t%s\nexecname\t%s\nexecpath\t%s\n",
  exec,execname,execpath));
 
-   wait_for_child = build_cmdline(cmdline2,exec,argc,argv);
+   wait_for_child = build_cmdline(cmdline2,exec,&argc,argv);
Trace((cmdline2));
 
xemacs_special(exec);
-   ret_code = start_child(cmdline2,wait_for_child);
+   if (target_is_gui (exec))
+ {
+   /* much simpler if target is gui, because we don't
+* actually need to worry about consoles, stdio
+* handles, etc.  If -wait, then delegate to _spawnv,
+* since we have the argv array. However, because
+* _spawnv (_P_NOWAIT) doesn't work reliably on
+* cygwin, use a lobotomized version of CreateProcess
+* (but still don't worry about handles or consoles).
+*/
+   setup_win_environ();
+   if (wait_for_child)
+ {
+   Trace(("gui wait for child: %s", exec));
+   /* ret_code is the child exit status for P_WAIT */
+   ret_code = _spawnv (_P_WAIT, exec, argv);
+   if (ret_code < 0)
+ error("could not start %s", exec);
+   return (int)ret_code;
+ }
+   else
+ {
+   STARTUPINFO start;
+   PROCESS_INFORMATION child;
+   ZeroMemory( &child, sizeof(PROCESS_INFORMATION) );
+   ZeroMemory (&start, sizeof (STARTUPINFO));
+   start.cb = sizeof (STARTUPINFO);
+   Trace(("Launch GUI target, async: %s", cmdline2));
+   ret_code = CreateProcess (NULL,
+   cmdline2,/* command line*/
+   NULL,/* process security attributes */
+   NULL,/* primary thread security attributes  */
+   FALSE,   /* handles are NOT inherited,  */
+   0,   /* creation flags  */
+   NULL,/* use parent's environment*/
+   NULL,/* use parent's current directory  */
+   &start,  /* STARTUPINFO pointer */
+   &child); /* receives PROCESS_INFORMATION*/
+   if (ret_code == 0)
+ {
+   Trace(("getlasterror: %d\n", GetLastError()));
+   error("could not start %s", exec);
+ }
+   return 0;
+ }
+ }
+   else
+ {
+   Trace(("Launch non-GUI target"));
+   ret_code = start_child(exec, cmdline2,wait_for_child);
+ }
if (compact_invocation)
   for (i = 1; i < argc; i++) /* argv[0] was not malloc'ed */
  free(argv[i]);
@@ -179,6 +234,51 @@ WinMain (HINSTANCE hSelf, HINSTANCE hPre
return (int) ret_code;
 }
 
+static BOOL target_is_gui(const char* target_path)
+{
+  char p, e;
+  DWORD_PTR d =
+  SHGetFileInfoA(target_path,/* LPCSTR pszPath */
+ 0,  /* DWORD dwFileAttributes */
+ NULL,   /* SHFILEINFO *psfi   */
+ 0,  /* UINT cbFileInfo*/
+ SHGFI_EXETYPE); /* UINT uFlags*/
+
+  p = LOBYTE (LOWORD (d));
+  e = HIBYTE (LOWORD (d));
+  Trace(("p=%c\ne=%c\nv=%d\n", p, e, HIWORD(d)));
+  return ( (((p=='P') || (p==

popen bugs

[Eric Blake]

popen misbehaves when various std fds are closed.

Test program:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static FILE *tty;

static void
dump (const char *s, int fd)
{
  fprintf (tty, "%s: fd %d: %s\n", s, fd,
   dup2 (fd, fd) == fd
   ? (fcntl (fd, F_GETFD) & FD_CLOEXEC) ? "cloexec" : "open"
   : "closed");
}

int
main (int argc, char** argv)
{
  const char *id = "child";
  if (dup2 (6, 6) == 6)
tty = fdopen (6, "a");
  else
{
  int fd = open ("/dev/tty", O_WRONLY|O_CREAT|O_APPEND, 0600);
  tty = fdopen (fcntl (fd, F_DUPFD, 6), "w");
  close (fd);
}
  assert (tty);
  if (argc > 1)
{
  id = "parent";
  FILE *slave = popen (argv[0], argv[1]);
  if (slave)
{
  fputs ("parent ", tty);
  dump ("slave", fileno (slave));
}
  else
fputs ("invalid mode to popen\n", tty);
}
  dump (id, 0);
  dump (id, 1);
  dump (id, 2);
  return 0;
}


I ran the following (testing all combinations of read and write
children, and all combinations of which std fds are closed):

{ for mode in r w; do echo testing $mode >&6; i=0;
for closed in '' '<&-' '>&-' '<&- >&-' '2>&-' \
'<&- 2>&-' '>&- 2>&-' '<&- >&- 2>&-' ;
do echo $((i++)) >&6;  (eval ./foo $mode $closed); sleep 1;
  done; done } 6>log.txt

then compared the logs between cygwin and Solaris, to spot
the following bugs:

When both stdin and stdout are closed and the parent
is reading from the slave, the slave fails to get the
write end of the pipe set to its stdout (regardless
of whether stderr is also closed; cases r3 and r7 above):

./foo r <&- >&-
$ ./foo r <&- >&-
parent's slave: fd 0: cloexec
parent: fd 0: cloexec
parent: fd 1: closed
parent: fd 2: open
child: fd 0: closed
child: fd 1: closed
child: fd 2: open

expected "child: fd 1: open"

When stdin is closed and the parent is writing to
the slave, the slave fails to get the read end of the
pipe set to its stdin (regardless of whether stdout or
stderr are closed, cases w1, w3, w5, and w7 above).

$ ./foo w <&-
parent's slave: fd 3: cloexec
parent: fd 0: closed
parent: fd 1: open
parent: fd 2: open
child: fd 0: closed
child: fd 1: open
child: fd 2: open

expected "child: fd 0: open"

-- 
Eric Blake

-- 
View this message in context: 
http://www.nabble.com/popen-bugs-tp25015624p25015624.html
Sent from the Cygwin list mailing list archive at Nabble.com.


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

Re: popen bugs

[Christopher Faylor]

On Mon, Aug 17, 2009 at 03:45:23PM -0700, Eric Blake wrote:
>popen misbehaves when various std fds are closed.

And, who among us could have not seen that coming?

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: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Stephan Mueller]

CGF wrote:
" On Mon, Aug 17, 2009 at 07:16:17PM +0100, Robin Walker wrote:
" >--On 17 August 2009 17:52 + Stephan Mueller wrote:
" >
" >> Robin Walker wrote:
" >> " On any NT-class Windows, calling a *.bat file causes a 16-bit
" >> sub-system to  " be spawned, and the .bat file is interpreted within the
" >> 16-bit command  " interpreter.
" >> "
" >> " Does the startxwin.bat script work when it is renamed startxwin.cmd ?
" >>
" >> This is certainly an interesting question, but I'm not sure I believe the
" >> preceding claim.
" >
" >OK, I stand corrected.  It looks as if something that bit me more years ago 
" >than I can remember is not in fact the problem that I mis-remembered it to 
" >be.
" >
" >Sorry for wasting your time!
"
" Too bad.  It was an interesting supposition, at least.

... and perhaps worth doing the quick test Robin suggested, just to be sure,
since it really is cheap.

(Despite my years of not noticing 16-bit involvement, I stand by my
weasel words -- I'm not 100% _sure_ here either.)


--
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: UNZIP: Why don't .exe/.dll files get eXecute privs?

[Andrew DeFaria]

On 08/17/2009 12:32 PM, Warren Young wrote:

Jim Reisert AD1C wrote:


I can't control how the ZIP file gets created, but I do expect that
when I unzip a file, that the .exe will actually execute without
having to change permissions!


I guess it comes down to a question of whether *.exe implies chmod +x. 
It doesn't in any "native" *ix packaging format, like tar or cpio. 
Doing this would thus be a break from expected behavior for some.  I 
can see your point, Jim, but I don't think the answer is obvious.


Should unzip do this for *.sh?  *.pl?  *.insert-yfl-extension?

Sure, why not?
Before you answer, have you looked at a programming language list 
lately? There are "only" about 750 on this index page in Wikipedia:


http://en.wikipedia.org/wiki/List_of_programming_languages

I've seen other lists that put the count at more like 2,500.  
Obviously we don't have to handle them all, as some may re-use 
extensions, and others aren't directly executable from a shell, like C 
code.  We're still left with hundreds, surely?  If we don't have to 
handle them all, what's the razor that describes which get this 
special treatment and which don't?  How do you deal with conflicts 
among file name extensions?

Computers are good at handling large lists of things...


Now throw in shebang magic.  Does unzip have to set the executable bit 
on files with a shebang line at the start?

Great idea!

What if it's binary data that just happens to start with those two bytes?

You obviously need to look at more than just those two...
Now does unzip have to parse the line and check for the existence of 
an interpreter?

Another good idea!
Should unzip have this special-case code only if it doesn't see an 
ACL, or does it override explicit settings?


This isn't Cygwin-specific.  I use a package on Linux that uses zip 
for its distributed binary packages (yeah, yech, I know), and has a 
bunch of chmod hackery in its post-unpack installation instructions.

Only 1/2 a smiley smirk...
--
Andrew DeFaria 
What happened to Preparations A through G?


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

Re: [ANNOUNCEMENT] Updated: run-1.1.11-1

[Colin Harrison]

Hi,

Chuck wrote:
> OK, how about this?  Seems to work on Vista(cyg1.5, cyg1.7, mingw)
xgui/cui/bat.

Applied your latest patch to run's cvs and built with MinGW, for native
Windows.

Works for me on Windows 2003 Server.

Tested as before and with 'run CUIs' in batch files (*.bat) and shortcut
files (*.lnk). All now appear OK.

Thanks,
Colin


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