subject:"Re\: setup and mintty $was Re\: New setup.exe release\?$"

On 25 May 2011 16:51, Corinna Vinschen wrote:
 On May 25 09:54, Thomas Wolff wrote:
 Am 25.05.2011 09:43, schrieb Andy Koppe:
 ...
 Ah, sorry, I didn't realise that the desktop shortcut at the moment
 was simply called Cygwin rather than Cygwin Bash Shell. I suppose
 that could just stay like that actually.
 
 Also, since the start menu shortcut already is inside the Cygwin
 folder, just Terminal rather than Cygwin Terminal would be nice
 and crisp there.
 I think common usage is to give shortcuts rather a complete name.
 That's also better if people move them around, placing a copy on the
 desktop etc.
 And since bash shell runs in both command windows (is that a common
 name?), I think the previous proposal Cygwin Console and Cygwin
 Terminal is the best to distinguish them.

 I'm wondering if renaming the shortcuts is wise.

 New users should get the new shortcuts, but what about users who just
 update Cygwin?  If we rename the shortcuts, existing users will
 have both check buttons in the last dialog checked again, even if they
 already had installed the old shortcuts before.

 Alternatively setup could test for the old and the new shortcut names,
 and only install if neither the old, nor the new ones exist.

Gah, this is surprisingly difficult.

How about:

- Don't rename the desktop shortcut, leaving it as Cygwin. This
means that it won't change for users that already have one, nor will
they get another desktop shortcut. Only newly created desktop
shortcuts would point at mintty, resulting in a somewhat more phased
introduction instead of springing it on users, which seems a prudent
thing to do.

- Offer the start menu item creation unless either Console or
Terminal is present in the Cygwin folder. If requested, remove
Cygwin Bash Shell and create Console and Terminal. (Add Cygwin
prefixes according to taste. I think anyone who moves the shortcuts
elsewhere would be quite capable of renaming them if they feel the
need to.)

Andy

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-26 Thread Corinna Vinschen

On May 26 08:00, Andy Koppe wrote:
 On 25 May 2011 16:51, Corinna Vinschen wrote:
  On May 25 09:54, Thomas Wolff wrote:
  Am 25.05.2011 09:43, schrieb Andy Koppe:
  ...
  Ah, sorry, I didn't realise that the desktop shortcut at the moment
  was simply called Cygwin rather than Cygwin Bash Shell. I suppose
  that could just stay like that actually.
  
  Also, since the start menu shortcut already is inside the Cygwin
  folder, just Terminal rather than Cygwin Terminal would be nice
  and crisp there.
  I think common usage is to give shortcuts rather a complete name.
  That's also better if people move them around, placing a copy on the
  desktop etc.
  And since bash shell runs in both command windows (is that a common
  name?), I think the previous proposal Cygwin Console and Cygwin
  Terminal is the best to distinguish them.
 
  I'm wondering if renaming the shortcuts is wise.
 
  New users should get the new shortcuts, but what about users who just
  update Cygwin?  If we rename the shortcuts, existing users will
  have both check buttons in the last dialog checked again, even if they
  already had installed the old shortcuts before.
 
  Alternatively setup could test for the old and the new shortcut names,
  and only install if neither the old, nor the new ones exist.
 
 Gah, this is surprisingly difficult.
 
 How about:
 
 - Don't rename the desktop shortcut, leaving it as Cygwin. This
 means that it won't change for users that already have one, nor will
 they get another desktop shortcut. Only newly created desktop
 shortcuts would point at mintty, resulting in a somewhat more phased
 introduction instead of springing it on users, which seems a prudent
 thing to do.

Agreed.

 - Offer the start menu item creation unless either Console or
 Terminal is present in the Cygwin folder. If requested, remove
 Cygwin Bash Shell and create Console and Terminal. (Add Cygwin
 prefixes according to taste. I think anyone who moves the shortcuts
 elsewhere would be quite capable of renaming them if they feel the
 need to.)

Ooh, no.  I really don't like the idea to offer two start menu entries
by default.  I'm not sure a lot of people even have a vague
understanding what the difference between console and terminal is.
If in doubt, I bet most people will choose the alphabetically first
entry without reading or thinking, quite along the lines of
http://www.joelonsoftware.com/uibook/chapters/fog62.html

If we really do that, the name of the console entry should be last, and
ugly, so that people choose the Cygwin Terminal entry with a higher
probability.   Windows Console window with a bash within, only use if
you must or something.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On 26 May 2011 09:07, Corinna Vinschen wrote:
 On May 26 08:00, Andy Koppe wrote:
 On 25 May 2011 16:51, Corinna Vinschen wrote:
  On May 25 09:54, Thomas Wolff wrote:
  Am 25.05.2011 09:43, schrieb Andy Koppe:
  ...
  Ah, sorry, I didn't realise that the desktop shortcut at the moment
  was simply called Cygwin rather than Cygwin Bash Shell. I suppose
  that could just stay like that actually.
  
  Also, since the start menu shortcut already is inside the Cygwin
  folder, just Terminal rather than Cygwin Terminal would be nice
  and crisp there.
  I think common usage is to give shortcuts rather a complete name.
  That's also better if people move them around, placing a copy on the
  desktop etc.
  And since bash shell runs in both command windows (is that a common
  name?), I think the previous proposal Cygwin Console and Cygwin
  Terminal is the best to distinguish them.
 
  I'm wondering if renaming the shortcuts is wise.
 
  New users should get the new shortcuts, but what about users who just
  update Cygwin?  If we rename the shortcuts, existing users will
  have both check buttons in the last dialog checked again, even if they
  already had installed the old shortcuts before.
 
  Alternatively setup could test for the old and the new shortcut names,
  and only install if neither the old, nor the new ones exist.

 Gah, this is surprisingly difficult.

 How about:

 - Don't rename the desktop shortcut, leaving it as Cygwin. This
 means that it won't change for users that already have one, nor will
 they get another desktop shortcut. Only newly created desktop
 shortcuts would point at mintty, resulting in a somewhat more phased
 introduction instead of springing it on users, which seems a prudent
 thing to do.

 Agreed.

 - Offer the start menu item creation unless either Console or
 Terminal is present in the Cygwin folder. If requested, remove
 Cygwin Bash Shell and create Console and Terminal. (Add Cygwin
 prefixes according to taste. I think anyone who moves the shortcuts
 elsewhere would be quite capable of renaming them if they feel the
 need to.)

 Ooh, no.  I really don't like the idea to offer two start menu entries
 by default.  I'm not sure a lot of people even have a vague
 understanding what the difference between console and terminal is.
 If in doubt, I bet most people will choose the alphabetically first
 entry without reading or thinking, quite along the lines of
 http://www.joelonsoftware.com/uibook/chapters/fog62.html

Fair point.

 If we really do that, the name of the console entry should be last, and
 ugly, so that people choose the Cygwin Terminal entry with a higher
 probability.   Windows Console window with a bash within, only use if
 you must or something.

:)

That's possibly worse and certainly uglier than not having it at all,
so let's leave it.

On a closely related note, there's the issue of the mintty postinstall
script. Simply dropping the mintty shortcut creation when setup.exe
is changed would mean that the shortcut would disappear without
replacement for people updating with a not-quite-up-to-date setup.exe
or who habitually untick the Add start menu item checkbox.

Therefore I think I should change the postinstall script such that it
continues to create the mintty shortcut, but only if Cygwin
Terminal isn't there. However, since setup.exe creates its shortcuts
*after* running the postinstall script, people would end up with both
mintty and Cygwin Terminal until the mintty package is next
updated. Avoiding that requires setup.exe to nuke the mintty
shortcut when it creates Cygwin Terminal.

Andy

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-26 Thread Corinna Vinschen

On May 26 12:33, Andy Koppe wrote:
 On 26 May 2011 09:07, Corinna Vinschen wrote:
  On May 26 08:00, Andy Koppe wrote:
  - Offer the start menu item creation unless either Console or
  Terminal is present in the Cygwin folder. If requested, remove
  Cygwin Bash Shell and create Console and Terminal. (Add Cygwin
  prefixes according to taste. I think anyone who moves the shortcuts
  elsewhere would be quite capable of renaming them if they feel the
  need to.)
  [...]
  If we really do that, the name of the console entry should be last, and
  ugly, so that people choose the Cygwin Terminal entry with a higher
  probability.   Windows Console window with a bash within, only use if
  you must or something.
 
 :)
 
 That's possibly worse and certainly uglier than not having it at all,
 so let's leave it.
 
 On a closely related note, there's the issue of the mintty postinstall
 script. Simply dropping the mintty shortcut creation when setup.exe
 is changed would mean that the shortcut would disappear without
 replacement for people updating with a not-quite-up-to-date setup.exe
 or who habitually untick the Add start menu item checkbox.
 
 Therefore I think I should change the postinstall script such that it
 continues to create the mintty shortcut, but only if Cygwin
 Terminal isn't there. However, since setup.exe creates its shortcuts
 *after* running the postinstall script, people would end up with both
 mintty and Cygwin Terminal until the mintty package is next
 updated. Avoiding that requires setup.exe to nuke the mintty
 shortcut when it creates Cygwin Terminal.

Hmm.

That begs for the question why the start menu entry isn't managed
entirely by mintty's postinstall/preremove scripts.  In theory we can
reduce setup to ask for the desktop icon.  The start menu entry is
always created, and it's always created by mintty.  That would make the
entire affair much easier, isn't it?


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On 26 May 2011 12:51, Corinna Vinschen wrote:
 On a closely related note, there's the issue of the mintty postinstall
 script. Simply dropping the mintty shortcut creation when setup.exe
 is changed would mean that the shortcut would disappear without
 replacement for people updating with a not-quite-up-to-date setup.exe
 or who habitually untick the Add start menu item checkbox.

 Therefore I think I should change the postinstall script such that it
 continues to create the mintty shortcut, but only if Cygwin
 Terminal isn't there. However, since setup.exe creates its shortcuts
 *after* running the postinstall script, people would end up with both
 mintty and Cygwin Terminal until the mintty package is next
 updated. Avoiding that requires setup.exe to nuke the mintty
 shortcut when it creates Cygwin Terminal.

 Hmm.

 That begs for the question why the start menu entry isn't managed
 entirely by mintty's postinstall/preremove scripts.  In theory we can
 reduce setup to ask for the desktop icon.  The start menu entry is
 always created, and it's always created by mintty.  That would make the
 entire affair much easier, isn't it?

Good point. The only argument against that I can think of is that the
postinstall script shortcut is non-optional. There have been some
minor complaints about that before.

(Setup.exe would still need to nuke Cygwin Bash Shell).

Andy

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-26 Thread Corinna Vinschen

On May 26 13:09, Andy Koppe wrote:
 On 26 May 2011 12:51, Corinna Vinschen wrote:
  That begs for the question why the start menu entry isn't managed
  entirely by mintty's postinstall/preremove scripts.  In theory we can
  reduce setup to ask for the desktop icon.  The start menu entry is
  always created, and it's always created by mintty.  That would make the
  entire affair much easier, isn't it?
 
 Good point. The only argument against that I can think of is that the
 postinstall script shortcut is non-optional. There have been some
 minor complaints about that before.
 
 (Setup.exe would still need to nuke Cygwin Bash Shell).

I'm willing to ignore both problems.  Mintty isn't the only package
to fill the Cygwin or Cygwin/X menu.  Removing an existent Cygwin Bash
Shell seems a bit harsh.  But that's just me.  What do other think?


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On 26 May 2011 13:17, Corinna Vinschen wrote:
 On May 26 13:09, Andy Koppe wrote:
 On 26 May 2011 12:51, Corinna Vinschen wrote:
  That begs for the question why the start menu entry isn't managed
  entirely by mintty's postinstall/preremove scripts.  In theory we can
  reduce setup to ask for the desktop icon.  The start menu entry is
  always created, and it's always created by mintty.  That would make the
  entire affair much easier, isn't it?

 Good point. The only argument against that I can think of is that the
 postinstall script shortcut is non-optional. There have been some
 minor complaints about that before.

 (Setup.exe would still need to nuke Cygwin Bash Shell).

 I'm willing to ignore both problems.  Mintty isn't the only package
 to fill the Cygwin or Cygwin/X menu.  Removing an existent Cygwin Bash
 Shell seems a bit harsh.

Ah, alright, I thought was the intention, but leaving it is fine by me.

Andy

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-25 Thread Andy Koppe

On 24 May 2011 10:50, Corinna Vinschen wrote:
 On May 24 11:15, Corinna Vinschen wrote:
 On May 23 21:14, Andy Koppe wrote:
  On 23 May 2011 12:50, Corinna Vinschen wrote:
   And who's going to create the patches?
 
  I suppose that should be me, but my spare time is rather limited at
  the moment and I still owe a patch or two for other things.

 I'm just trying a setup.exe patch which creates Cygwin Terminal
 desktop and start menu entries which point to mintty -.  I just
 have to get rid of my build environment problems...

 Ok, here's my patch.  It just replaces the Desktop and Start Menu
 entries with Cygwin Terminal entries pointing to mintty - and
 leaves Cygwin.bat untouched.  Is that ok with everyone?

 Index: desktop.cc
 ===
 RCS file: /cvs/cygwin-apps/setup/desktop.cc,v
 retrieving revision 2.55
 diff -u -p -r2.55 desktop.cc
 --- desktop.cc  19 Nov 2010 15:49:54 -      2.55
 +++ desktop.cc  24 May 2011 09:47:51 -
 @@ -78,7 +78,8 @@ DesktopSetupPage::DesktopSetupPage ()
  static void
  make_link (const std::string linkpath,
            const std::string title,
 -           const std::string target)
 +           const std::string target,
 +           const std::string arg)
  {
   std::string fname = linkpath + / + title + .lnk;

 @@ -93,10 +94,10 @@ make_link (const std::string linkpath,
   std::string exepath;
   std::string argbuf;

 -  if (!is_legacy)
 +  if (IsWindowsNT ())
     {
       exepath = target;
 -      argbuf =  ;
 +      argbuf = arg;
     }
   else
     {
 @@ -105,6 +106,8 @@ make_link (const std::string linkpath,
       GetWindowsDirectory (windir, sizeof (windir));
       exepath = std::string(windir) + \\command.com;
       argbuf = /E:4096 /c  + target;
 +      if (arg.size ())
 +       argbuf +=   + arg;
     }

   msg (make_link_2 (%s, %s, %s, %s),
 @@ -115,7 +118,8 @@ make_link (const std::string linkpath,
  }

  static void
 -start_menu (const std::string title, const std::string target)
 +start_menu (const std::string title, const std::string target,
 +           const std::string arg)
  {
   LPITEMIDLIST id;
   int issystem = (root_scope == IDC_ROOT_SYSTEM) ? 1 : 0;
 @@ -137,11 +141,12 @@ start_menu (const std::string title, co
     }
  // end of Win95 addition
   path += /Cygwin;
 -  make_link (path, title, target);
 +  make_link (path, title, target, arg);
  }

  static void
 -desktop_icon (const std::string title, const std::string target)
 +desktop_icon (const std::string title, const std::string target,
 +             const std::string arg)
  {
   char path[MAX_PATH];
   LPITEMIDLIST id;
 @@ -161,7 +166,7 @@ desktop_icon (const std::string title,
       msg (Desktop directory for deskop link changed to: %s, path);
     }
  // end of Win95 addition
 -  make_link (path, title, target);
 +  make_link (path, title, target, arg);
  }

  static void
 @@ -243,15 +248,17 @@ do_desktop_setup ()

   make_cygwin_bat ();

 +  std::string target;
 +
 +  target = is_legacy ? batname : backslash (cygpath (/bin/mintty));
 +
   if (root_menu)
 -    {
 -      start_menu (Cygwin Bash Shell, batname);
 -    }
 +    start_menu (is_legacy ? Cygwin Bash Shell : Cygwin Terminal, target,
 +               is_legacy ?  : -);

   if (root_desktop)
 -    {
 -      desktop_icon (Cygwin, batname);
 -    }
 +    desktop_icon (is_legacy ? Cygwin : Cygwin Terminal, target,
 +                 is_legacy ?  : -);
  }

  static int da[] = { IDC_ROOT_DESKTOP, 0 };
 @@ -425,8 +432,11 @@ DesktopSetupPage::OnActivate ()
       else
        {
          root_menu =
 -           check_startmenu (Cygwin Bash Shell,
 -                            backslash (cygpath (/cygwin.bat)));
 +           is_legacy
 +           ? check_startmenu (Cygwin Bash Shell,
 +                              backslash (cygpath (/cygwin.bat)))
 +           : check_startmenu (Cygwin Terminal,
 +                              backslash (cygpath (/bin/mintty)));
        }

       if (NoDesktopOption)
 @@ -436,7 +446,10 @@ DesktopSetupPage::OnActivate ()
       else
        {
          root_desktop =
 -           check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)));
 +           is_legacy
 +           ? check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)))
 +           : check_desktop (Cygwin Terminal,
 +                            backslash (cygpath (/bin/mintty)));
        }
     }

Ah, sorry, I didn't realise that the desktop shortcut at the moment
was simply called Cygwin rather than Cygwin Bash Shell. I suppose
that could just stay like that actually.

Also, since the start menu shortcut already is inside the Cygwin
folder, just Terminal rather than Cygwin Terminal would be nice
and crisp there.

Andy

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-25 Thread Thomas Wolff


Am 25.05.2011 09:43, schrieb Andy Koppe:

...
Ah, sorry, I didn't realise that the desktop shortcut at the moment
was simply called Cygwin rather than Cygwin Bash Shell. I suppose
that could just stay like that actually.

Also, since the start menu shortcut already is inside the Cygwin
folder, just Terminal rather than Cygwin Terminal would be nice
and crisp there.
I think common usage is to give shortcuts rather a complete name. That's 
also better if people move them around, placing a copy on the desktop etc.
And since bash shell runs in both command windows (is that a common 
name?), I think the previous proposal Cygwin Console and Cygwin 
Terminal is the best to distinguish them.

--
Thomas

Re: setup and mintty (was Re: New setup.exe release?)

On May 23 15:33, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
 On May 23 13:25, Christopher Faylor wrote:
  On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
  On May 23 11:33, Charles Wilson wrote:
   as-is.  What if you really WANT to use cmdbox?  How else can a
   cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
And since that's the only real way to do so, we ought to provide the 
   file.
  ^^
  Huh?
  
  You can simple create a Windows shortcut to bash.exe, edit it to
  add a --login option, and that's all you really need.
  
  I agree, except for people who need to set the CYGWIN environment
  variable for some reason.  You have to do that before running bash.
  
  Maybe we should be looking into introducing a way to set the CYGWIN
  environment variable in the global environment and adding c:\cygwin\bin
  (or whatever) to the global PATH as well.
 
 I would really like to avoid that.  The question is, which CYGWIN
 settings are really needed before an application starts?  Apart from the
 debugging the Cygwin DLL scenario, the only one I can think of is the
 tty setting, and that's about to go away.
 
 IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
 (CYGWIN=...) would change the CYGWIN settings for the calling process
 as well.
 
 Well, unless you make that change, all of the other Cygwin environment
 variables (not just tty) need to be set before the first Cygwin
 process in a tree is started.  Parsing the CYGWIN environment variable
 on the fly is trivial but I don't know for sure if there are some
 settings which only work right when set during program initialization.

I had a quick look:

 dosfilewarning Sets a bool.  Has immediate effect.
 envcache   Ditto.
 error_startSets a string.  Has immediate effect.
 export Sets a bool.  Has effect on exec'ed child processes.
 glob   Sets two bools.  Has effect on exec'ed child processes.
 proc_retry Sets number.  Has immediate effect.
 reset_com  Sets bool.  Has immediate effect.
  However, per the comment in fhandler_serial::open this
  works around a problem in Windows 9x!  Maybe we should
  kill the setting?
 strip_titleand
 display_title  set bools.  Has effect on exec'ed child processes.
 ttyWell...
 upcaseenv  Sets bool.  Has effect on exec'ed child processes.
 winsymlinksSets bool.  Has immediate effect.

So, as far as I can tell, except for the tty setting everything else
would work nicely if set via setenv/putenv.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On May 23 22:47, Buchbinder, Barry (NIH/NIAID) [E] wrote:
 Christopher Faylor sent the following at Monday, May 23, 2011 1:26 PM
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.
 
 http://cygwin.com/ml/cygwin/2010-01/msg00977.html
 
 Still Just a suggestion, not a request.

Still an interesting idea.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On May 23 21:14, Andy Koppe wrote:
 On 23 May 2011 12:50, Corinna Vinschen wrote:
  On May 20 17:09, Yaakov (Cygwin/X) wrote:
  The setup.exe download is still 2.738.  Could it be updated to 2.749
  to include jturney's recent bug fixes?
 
  I'd like to fix the mintty issue first.
 
  So, do we swtch to mintty as default terminal, yes or no?
 
  If we switch to mintty we don't need the Cygwin.bat file anymore.  But,
  shouldn't we keep it anyway for people who maintain some handmade symlink
  to it?
 
 Yes, I think so.
 
  If so, should we stick to the content of Cygwin.bat as is, or should
  we change it to call mintty, too?
 
 Better not, so as not to change people's existing setup. And because
 it would flash up a console for the .bat.
 
  And who's going to create the patches?
 
 I suppose that should be me, but my spare time is rather limited at
 the moment and I still owe a patch or two for other things.

I'm just trying a setup.exe patch which creates Cygwin Terminal
desktop and start menu entries which point to mintty -.  I just
have to get rid of my build environment problems...

 What it should do:
 1) Invoke the user's default shell as set in /etc/passwd as a login
 shell. (This is what the mintty start menu shortcut currently does)
 2) Invoke bash as a login shell.

#1, definitely.

 d) Cygwin Terminal: Linux desktops usually have Terminal entries
 in their menus.

Yep.

 I also think the console's start menu entry in the Cygwin folder
 should be kept, perhaps with a new name. Console vs Terminal?

Why?


Other than that, the docs need some tweaking as well, I guess.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On May 24 11:15, Corinna Vinschen wrote:
 On May 23 21:14, Andy Koppe wrote:
  On 23 May 2011 12:50, Corinna Vinschen wrote:
   And who's going to create the patches?
  
  I suppose that should be me, but my spare time is rather limited at
  the moment and I still owe a patch or two for other things.
 
 I'm just trying a setup.exe patch which creates Cygwin Terminal
 desktop and start menu entries which point to mintty -.  I just
 have to get rid of my build environment problems...

Ok, here's my patch.  It just replaces the Desktop and Start Menu
entries with Cygwin Terminal entries pointing to mintty - and
leaves Cygwin.bat untouched.  Is that ok with everyone?

Index: desktop.cc
===
RCS file: /cvs/cygwin-apps/setup/desktop.cc,v
retrieving revision 2.55
diff -u -p -r2.55 desktop.cc
--- desktop.cc  19 Nov 2010 15:49:54 -  2.55
+++ desktop.cc  24 May 2011 09:47:51 -
@@ -78,7 +78,8 @@ DesktopSetupPage::DesktopSetupPage ()
 static void
 make_link (const std::string linkpath,
const std::string title,
-   const std::string target)
+   const std::string target,
+   const std::string arg)
 {
   std::string fname = linkpath + / + title + .lnk;
 
@@ -93,10 +94,10 @@ make_link (const std::string linkpath,
   std::string exepath;
   std::string argbuf;
 
-  if (!is_legacy)
+  if (IsWindowsNT ())
 {
   exepath = target;
-  argbuf =  ;
+  argbuf = arg;
 }
   else
 {
@@ -105,6 +106,8 @@ make_link (const std::string linkpath,
   GetWindowsDirectory (windir, sizeof (windir));
   exepath = std::string(windir) + \\command.com;
   argbuf = /E:4096 /c  + target;
+  if (arg.size ())
+   argbuf +=   + arg;
 }
 
   msg (make_link_2 (%s, %s, %s, %s),
@@ -115,7 +118,8 @@ make_link (const std::string linkpath,
 }
 
 static void
-start_menu (const std::string title, const std::string target)
+start_menu (const std::string title, const std::string target,
+   const std::string arg)
 {
   LPITEMIDLIST id;
   int issystem = (root_scope == IDC_ROOT_SYSTEM) ? 1 : 0;
@@ -137,11 +141,12 @@ start_menu (const std::string title, co
 }
 // end of Win95 addition
   path += /Cygwin;
-  make_link (path, title, target);
+  make_link (path, title, target, arg);
 }
 
 static void
-desktop_icon (const std::string title, const std::string target)
+desktop_icon (const std::string title, const std::string target,
+ const std::string arg)
 {
   char path[MAX_PATH];
   LPITEMIDLIST id;
@@ -161,7 +166,7 @@ desktop_icon (const std::string title, 
   msg (Desktop directory for deskop link changed to: %s, path);
 }
 // end of Win95 addition
-  make_link (path, title, target);
+  make_link (path, title, target, arg);
 }
 
 static void
@@ -243,15 +248,17 @@ do_desktop_setup ()
 
   make_cygwin_bat ();
 
+  std::string target;
+
+  target = is_legacy ? batname : backslash (cygpath (/bin/mintty));
+
   if (root_menu)
-{
-  start_menu (Cygwin Bash Shell, batname);
-}
+start_menu (is_legacy ? Cygwin Bash Shell : Cygwin Terminal, target,
+   is_legacy ?  : -);
 
   if (root_desktop)
-{
-  desktop_icon (Cygwin, batname);
-}
+desktop_icon (is_legacy ? Cygwin : Cygwin Terminal, target,
+ is_legacy ?  : -);
 }
 
 static int da[] = { IDC_ROOT_DESKTOP, 0 };
@@ -425,8 +432,11 @@ DesktopSetupPage::OnActivate ()
   else
{
  root_menu =
-   check_startmenu (Cygwin Bash Shell,
-backslash (cygpath (/cygwin.bat)));
+   is_legacy
+   ? check_startmenu (Cygwin Bash Shell,
+  backslash (cygpath (/cygwin.bat)))
+   : check_startmenu (Cygwin Terminal,
+  backslash (cygpath (/bin/mintty)));
}
 
   if (NoDesktopOption) 
@@ -436,7 +446,10 @@ DesktopSetupPage::OnActivate ()
   else
{
  root_desktop =
-   check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)));
+   is_legacy
+   ? check_desktop (Cygwin, backslash (cygpath (/cygwin.bat)))
+   : check_desktop (Cygwin Terminal,
+backslash (cygpath (/bin/mintty)));
}
 }
 

Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-24 Thread Andy Koppe

On 24 May 2011 10:15, Corinna Vinschen wrote:
 On May 23 21:14, Andy Koppe wrote:

 I also think the console's start menu entry in the Cygwin folder
 should be kept, perhaps with a new name. Console vs Terminal?

 Why?

As a straightforward answer to questions along these lines:

- I loved the old Cygwin Bash Shell with its endearingly quirky
scrolling and copy'n'paste. Where did it go?

- Mysql/Python/Java/Cmd.exe/other_interactive_non_cygwin_program
doesn't work properly in this crappy new terminal. Can you make them
work again please.

Andy

Re: setup and mintty (was Re: New setup.exe release?)

On May 24 12:18, Andy Koppe wrote:
 On 24 May 2011 10:15, Corinna Vinschen wrote:
  On May 23 21:14, Andy Koppe wrote:
 
  I also think the console's start menu entry in the Cygwin folder
  should be kept, perhaps with a new name. Console vs Terminal?
 
  Why?
 
 As a straightforward answer to questions along these lines:
 
 - I loved the old Cygwin Bash Shell with its endearingly quirky
 scrolling and copy'n'paste. Where did it go?
 
 - Mysql/Python/Java/Cmd.exe/other_interactive_non_cygwin_program
 doesn't work properly in this crappy new terminal. Can you make them
 work again please.

FAQ answer:  Double-click Cygwin.bat in the Cygwin installation dir.

Sounds sufficiently straightforward to me.  Apart from that, keeping
the Cygwin Bash Shell menu entry requires another check button in
Setup's Create Icons menu.  I'd rather avoid that.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On Tue, May 24, 2011 at 09:19:08AM +0200, Corinna Vinschen wrote:
On May 23 15:33, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
 On May 23 13:25, Christopher Faylor wrote:
  On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
  On May 23 11:33, Charles Wilson wrote:
   as-is.  What if you really WANT to use cmdbox?  How else can a
   cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
And since that's the only real way to do so, we ought to provide the 
   file.
  ^^
  Huh?
  
  You can simple create a Windows shortcut to bash.exe, edit it to
  add a --login option, and that's all you really need.
  
  I agree, except for people who need to set the CYGWIN environment
  variable for some reason.  You have to do that before running bash.
  
  Maybe we should be looking into introducing a way to set the CYGWIN
  environment variable in the global environment and adding c:\cygwin\bin
  (or whatever) to the global PATH as well.
 
 I would really like to avoid that.  The question is, which CYGWIN
 settings are really needed before an application starts?  Apart from the
 debugging the Cygwin DLL scenario, the only one I can think of is the
 tty setting, and that's about to go away.
 
 IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
 (CYGWIN=...) would change the CYGWIN settings for the calling process
 as well.
 
 Well, unless you make that change, all of the other Cygwin environment
 variables (not just tty) need to be set before the first Cygwin
 process in a tree is started.  Parsing the CYGWIN environment variable
 on the fly is trivial but I don't know for sure if there are some
 settings which only work right when set during program initialization.

I had a quick look:

 dosfilewarning Sets a bool.  Has immediate effect.
 envcache   Ditto.
 error_start   Sets a string.  Has immediate effect.
 export Sets a bool.  Has effect on exec'ed child processes.
 glob   Sets two bools.  Has effect on exec'ed child processes.
 proc_retry Sets number.  Has immediate effect.
 reset_com  Sets bool.  Has immediate effect.
 However, per the comment in fhandler_serial::open this
  works around a problem in Windows 9x!  Maybe we should
  kill the setting?

Yep.  It's always fun to nuke those.

 strip_titleand
 display_title  set bools.  Has effect on exec'ed child processes.
 ttyWell...
 upcaseenv  Sets bool.  Has effect on exec'ed child processes.
 winsymlinksSets bool.  Has immediate effect.

So, as far as I can tell, except for the tty setting everything else
would work nicely if set via setenv/putenv.

Ok.  No objections here.  Do you want to do it or should I?

It looks like a fairly simple change to _addenv.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On Tue, May 24, 2011 at 11:50:52AM +0200, Corinna Vinschen wrote:
On May 24 11:15, Corinna Vinschen wrote:
 On May 23 21:14, Andy Koppe wrote:
  On 23 May 2011 12:50, Corinna Vinschen wrote:
   And who's going to create the patches?
  
  I suppose that should be me, but my spare time is rather limited at
  the moment and I still owe a patch or two for other things.
 
 I'm just trying a setup.exe patch which creates Cygwin Terminal
 desktop and start menu entries which point to mintty -.  I just
 have to get rid of my build environment problems...

Ok, here's my patch.  It just replaces the Desktop and Start Menu
entries with Cygwin Terminal entries pointing to mintty - and
leaves Cygwin.bat untouched.  Is that ok with everyone?

Index: desktop.cc
===
RCS file: /cvs/cygwin-apps/setup/desktop.cc,v
retrieving revision 2.55
diff -u -p -r2.55 desktop.cc
--- desktop.cc 19 Nov 2010 15:49:54 -  2.55
+++ desktop.cc 24 May 2011 09:47:51 -
@@ -78,7 +78,8 @@ DesktopSetupPage::DesktopSetupPage ()
 static void
 make_link (const std::string linkpath,
const std::string title,
-   const std::string target)
+   const std::string target,
+   const std::string arg)
 {
   std::string fname = linkpath + / + title + .lnk;
 
@@ -93,10 +94,10 @@ make_link (const std::string linkpath,
   std::string exepath;
   std::string argbuf;
 
-  if (!is_legacy)
+  if (IsWindowsNT ())

Why the change from is_legacy?

Did you check that legacy installations still work after your patch?

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On May 24 13:25, Christopher Faylor wrote:
 On Tue, May 24, 2011 at 11:50:52AM +0200, Corinna Vinschen wrote:
 On May 24 11:15, Corinna Vinschen wrote:
  On May 23 21:14, Andy Koppe wrote:
   On 23 May 2011 12:50, Corinna Vinschen wrote:
And who's going to create the patches?
   
   I suppose that should be me, but my spare time is rather limited at
   the moment and I still owe a patch or two for other things.
  
  I'm just trying a setup.exe patch which creates Cygwin Terminal
  desktop and start menu entries which point to mintty -.  I just
  have to get rid of my build environment problems...
 
 Ok, here's my patch.  It just replaces the Desktop and Start Menu
 entries with Cygwin Terminal entries pointing to mintty - and
 leaves Cygwin.bat untouched.  Is that ok with everyone?
 
 Index: desktop.cc
 ===
 RCS file: /cvs/cygwin-apps/setup/desktop.cc,v
 retrieving revision 2.55
 diff -u -p -r2.55 desktop.cc
 --- desktop.cc   19 Nov 2010 15:49:54 -  2.55
 +++ desktop.cc   24 May 2011 09:47:51 -
 @@ -78,7 +78,8 @@ DesktopSetupPage::DesktopSetupPage ()
  static void
  make_link (const std::string linkpath,
 const std::string title,
 -   const std::string target)
 +   const std::string target,
 +   const std::string arg)
  {
std::string fname = linkpath + / + title + .lnk;
  
 @@ -93,10 +94,10 @@ make_link (const std::string linkpath,
std::string exepath;
std::string argbuf;
  
 -  if (!is_legacy)
 +  if (IsWindowsNT ())
 
 Why the change from is_legacy?

Testing is_legacy was wrong here.   The else branch using command.com
is for 9x only.  YOu won't want that for NT, independently whther you
install the old or the new Cygwin.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-24 Thread Andy Koppe

On 24 May 2011 19:42, Corinna Vinschen wrote:
 On May 24 13:21, Christopher Faylor wrote:
 I had a quick look:
 
  dosfilewarning Sets a bool.  Has immediate effect.
  envcache       Ditto.
  error_start         Sets a string.  Has immediate effect.
  export         Sets a bool.  Has effect on exec'ed child processes.
  glob           Sets two bools.  Has effect on exec'ed child processes.
  proc_retry     Sets number.  Has immediate effect.
  reset_com      Sets bool.  Has immediate effect.
                However, per the comment in fhandler_serial::open this
                   works around a problem in Windows 9x!  Maybe we should
                   kill the setting?

 Yep.  It's always fun to nuke those.

 Talking about nuking CYGWIN settings, I have at least two more candidates:

  envcache   Did we ever had a problem which could be attributed
               to this setting?

  export     Does anybody really set CYGWIN settings in the registry?
               Shouldn't we drop fetching CYGWIN settings from the registry
               entirely?

  proc_retry Does it really help?

 Personally I would also remove strip_title, display_title, and
 upcaseenv, but that's just me.

The options remaining after such a cull are fairly obscure too, hence
I think the CYGWIN variable is the appropriate interface, in
particular if it will now be possible to set it in ~/.profile or
similar.

Adding a field to the mintty options dialog would of course be
possible, but I'd rather not, because those settings have nothing to
do with the terminal. Also, it looks suspiciously like the start of a
slippery slope towards options for all sorts of things.

Andy

Re: setup and mintty (was Re: New setup.exe release?)

On Tue, May 24, 2011 at 08:42:30PM +0200, Corinna Vinschen wrote:
On May 24 13:21, Christopher Faylor wrote:
 On Tue, May 24, 2011 at 09:19:08AM +0200, Corinna Vinschen wrote:
 On May 23 15:33, Christopher Faylor wrote:
  On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
  IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
  (CYGWIN=...) would change the CYGWIN settings for the calling process
  as well.
  
  Well, unless you make that change, all of the other Cygwin environment
  variables (not just tty) need to be set before the first Cygwin
  process in a tree is started.  Parsing the CYGWIN environment variable
  on the fly is trivial but I don't know for sure if there are some
  settings which only work right when set during program initialization.
 
 I had a quick look:
 
  dosfilewarning Sets a bool.  Has immediate effect.
  envcache   Ditto.
  error_startSets a string.  Has immediate effect.
  export Sets a bool.  Has effect on exec'ed child processes.
  glob   Sets two bools.  Has effect on exec'ed child processes.
  proc_retry Sets number.  Has immediate effect.
  reset_com  Sets bool.  Has immediate effect.
   However, per the comment in fhandler_serial::open this
   works around a problem in Windows 9x!  Maybe we should
   kill the setting?
 
 Yep.  It's always fun to nuke those.

Talking about nuking CYGWIN settings, I have at least two more candidates:

  envcache   Did we ever had a problem which could be attributed
   to this setting?

Don't think so.

  export Does anybody really set CYGWIN settings in the registry?
   Shouldn't we drop fetching CYGWIN settings from the registry
  entirely?

Every time this comes up I say I do.  The implementation allows you to
set the CYGWIN environment variable on a per path basis.  While it's not
well advertised, I think it's still pretty useful.

  proc_retry Does it really help?

Yes.  I actually implemented it for a customer so I'd rather not remove
it.

Personally I would also remove strip_title, display_title, and
upcaseenv, but that's just me.

I'd be happy to remove strip_title and display_title.  I thought that
someone would complain if we didn'thave upcaseenv but I was wrong so I
think that can go too.

  strip_titleand
  display_title  set bools.  Has effect on exec'ed child processes.
  ttyWell...
  upcaseenv  Sets bool.  Has effect on exec'ed child processes.
  winsymlinksSets bool.  Has immediate effect.
 
 So, as far as I can tell, except for the tty setting everything else
 would work nicely if set via setenv/putenv.
 
 Ok.  No objections here.  Do you want to do it or should I?

No worries, just go ahead.

Ok.  I'll remove most of the above too.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On Tue, May 24, 2011 at 08:44:55PM +0100, Andy Koppe wrote:
Adding a field to the mintty options dialog would of course be
possible, but I'd rather not, because those settings have nothing to
do with the terminal. Also, it looks suspiciously like the start of a
slippery slope towards options for all sorts of things.

FWIW, I agree.  I hate the Well, you already do X you might as well
do Y argument.

Except when I use it, of course.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On May 24 15:58, Christopher Faylor wrote:
 On Tue, May 24, 2011 at 08:42:30PM +0200, Corinna Vinschen wrote:
 On May 24 13:21, Christopher Faylor wrote:
  On Tue, May 24, 2011 at 09:19:08AM +0200, Corinna Vinschen wrote:
   dosfilewarning Sets a bool.  Has immediate effect.
   envcache   Ditto.
   error_start  Sets a string.  Has immediate effect.
   export Sets a bool.  Has effect on exec'ed child processes.
   glob   Sets two bools.  Has effect on exec'ed child processes.
   proc_retry Sets number.  Has immediate effect.
   reset_com  Sets bool.  Has immediate effect.
  However, per the comment in fhandler_serial::open this
works around a problem in Windows 9x!  Maybe we should
kill the setting?
  
  Yep.  It's always fun to nuke those.
 
 Talking about nuking CYGWIN settings, I have at least two more candidates:
 
   envcache   Did we ever had a problem which could be attributed
to this setting?
 
 Don't think so.
 
   export Does anybody really set CYGWIN settings in the registry?
Shouldn't we drop fetching CYGWIN settings from the registry
 entirely?
 
 Every time this comes up I say I do.  The implementation allows you to
 set the CYGWIN environment variable on a per path basis.  While it's not
 well advertised, I think it's still pretty useful.

Ok.  Just so I understand, maybe you could give a real world example?
I simply don't see how this might be useful.  And how does the export
option come into play?  Wouldn't it make sense to set it by default
and drop the CYGWIN option?

What if we replace the registry options with options read from a file
along the lines of Barry's /etc/cygwin.env idea?  The file could be
organized so that you can have per-path options as well.

   proc_retry Does it really help?
 
 Yes.  I actually implemented it for a customer so I'd rather not remove
 it.

Ok.

 
 Personally I would also remove strip_title, display_title, and
 upcaseenv, but that's just me.
 
 I'd be happy to remove strip_title and display_title.  I thought that
 someone would complain if we didn'thave upcaseenv but I was wrong so I
 think that can go too.
 
   strip_titleand
   display_title  set bools.  Has effect on exec'ed child processes.
   ttyWell...
   upcaseenv  Sets bool.  Has effect on exec'ed child processes.
   winsymlinksSets bool.  Has immediate effect.
  
  So, as far as I can tell, except for the tty setting everything else
  would work nicely if set via setenv/putenv.
  
  Ok.  No objections here.  Do you want to do it or should I?
 
 No worries, just go ahead.
 
 Ok.  I'll remove most of the above too.

Cool.  Maybe, at one point we can drop the CYGWIN environment variable
entirely :)


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-24 Thread Charles Wilson

On 5/23/2011 4:57 PM, Charles Wilson wrote:
 Maybe when I get home I'll test out a few...
 
 Consolas
 Andale Mono
 Courier New
 Lucida Console
 Vera Sans Mono (or DejaVu LGC Sans)
 Droid Sans Mono
 Inconsolata
 ...

FYI:
http://cygutils.fruitbat.org/mintty-font-test/


--
Chuck

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Charles Wilson

On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
On May 20 17:09, Yaakov (Cygwin/X) wrote:
The setup.exe download is still 2.738. Could it be updated to 2.749
to include jturney's recent bug fixes?

I'd like to fix the mintty issue first.

So, do we swtch to mintty as default terminal, yes or no?

Uhm, maybe? :-)

Here's the deal: run the following program from the ncurses-demo package:
/usr/lib/ncurses/test/lrtest.exe
in a mintty terminal and bash-in-cmdbox, with the same UTF-8 $LANG
settings (I've tried C.UTF-8 and en_US.UTF-8). FWIW,
TERM=xterm-256color in mintty, and TERM=cygwin in bash-in-cmdbox.

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Now, according to a post from 2004 by T.E. Dickey (ncurses/terminfo
maintainer):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256446

non-wide ncurses relies on the acsc,
wide-curses has a kludge to recognize UTF-8 locales and an internal
table for line-drawing characters.

...which also has a suggested patch for putty, but it's not clear it was
ever adopted.

So...trying the wide variant
/usr/lib/ncursesw/test/lrtest.exe
I get the same behavior as before in mintty (e.g. no linedraw
chars)...so there goes that idea (maybe the 'kludge' has been removed
from libncursesw between 2004 and now).

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

1) does mintty need to do magic linedraw character rewriting,
replacing what APPEAR to be attempts to print line draw chars with
unicode linedraw glyphs? (ugh. heuristics. I hate heuristics. They
always guess wrong sometimes.)
2) do we need an explicit mintty terminfo entry, with a 'better' acsc
entry -- OTOH, it is *NOT* possible to put unicode values in the
terminfo src string, so that's probably a nonstarter, unless combined
with (1). (also: ugh. must propagate the entry to all server OSs to
which you want to ssh...push upstream to ncurses...wait years for
RHEL7.0 to adopt it...)
3) Maybe there is some magic combination of envvar TERM/LANG,
settings, mintty options, font choices, etc, that will make linedraw work?
4) bug (or misconfiguration) in cygwin ncurses- or ncursesw- ?
5) or punt. Who needs linedraw anyway.

I'm ok with #5...but just wanted to bring up the issue so the decision
is an informed one.

If we switch to mintty we don't need the Cygwin.bat file anymore. But,
shouldn't we keep it anyway for people who maintain some handmade symlink
to it?

yes.

If so, should we stick to the content of Cygwin.bat as is, or should
we change it to call mintty, too?

as-is. What if you really WANT to use cmdbox? How else can a
cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
And since that's the only real way to do so, we ought to provide the file.

And who's going to create the patches?

Well, my proposal is a one-liner in setup.exe: just change the target of
the shortcut created in the Start Menu.

Last but not least, shouldn't we add mintty to the Base package
anyway, independently of what we do to setup?

I think so.

However, if we do change setup.exe, then mintty should later be updated
to eliminate its postinstall/preremove scripts. We don't need TWO
shortcuts to the same proggie.

--
Chuck

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Corinna Vinschen

On May 23 11:33, Charles Wilson wrote:
On 5/23/2011 7:50 AM, Corinna Vinschen wrote:
On May 20 17:09, Yaakov (Cygwin/X) wrote:
The setup.exe download is still 2.738. Could it be updated to 2.749
to include jturney's recent bug fixes?

I'd like to fix the mintty issue first.

So, do we swtch to mintty as default terminal, yes or no?

Uhm, maybe? :-)

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Something. I don't know how mintty works, but the Cygwin console knows
the switch to/from alternate charset command ESC [ 11 m, ESC [ 10
m. The alternate charset is always codepage 437 which has the line
drawing chars at known single-byte positions in the = 128 region.
This is apparently used by ncurses when running in a console window,
but perhaps not when running in mintty.

Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

What is the difference to the Cygwin console exactly? I'm sure, if you
look a bit below the surface, you will easily find bugs in the Cygwin
console implementation as well. It's all about getting bug reports or
even testcases. Just because there are bugs in mintty and the Cygwin
console doesn't mean both are unusable as default terminal.

Btw., why is it so bad to have ASCII replacement chars? They just
work, even if they look ugly to some people.

2) do we need an explicit mintty terminfo entry, with a 'better' acsc
entry

I don't think so. If at all, it's just some shortcoming in the current
implementation, something which can be fixed or added.

3) Maybe there is some magic combination of envvar TERM/LANG,
settings, mintty options, font choices, etc, that will make linedraw work?

Windows fonts are unicode anyway, and the line drawing chars are
part of the unicode codeset. I guess a translation table from
CP437 to unicode line drawing chars and support of the alternate
charset setting should do it.

If we switch to mintty we don't need the Cygwin.bat file anymore. But,
shouldn't we keep it anyway for people who maintain some handmade symlink
to it?

yes.

If so, should we stick to the content of Cygwin.bat as is, or should
we change it to call mintty, too?

You can simple create a Windows shortcut to bash.exe, edit it to
add a --login option, and that's all you really need.

And who's going to create the patches?

Well, my proposal is a one-liner in setup.exe: just change the target of
the shortcut created in the Start Menu.

I don't think it makes sense if the desktop shortcut and the menu entry
behave differently. The desktop shortcut is the first thing new users
see, and this shortcut should start mintty in the first place. Just
as the menu entry since they should do the same.

Last but not least, shouldn't we add mintty to the Base package
anyway, independently of what we do to setup?

I think so.

However, if we do change setup.exe, then mintty should later be updated
to eliminate its postinstall/preremove scripts. We don't need TWO
shortcuts to the same proggie.

I agree.

Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
 as-is.  What if you really WANT to use cmdbox?  How else can a
 cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
  And since that's the only real way to do so, we ought to provide the file.
^^
Huh?

You can simple create a Windows shortcut to bash.exe, edit it to
add a --login option, and that's all you really need.

I agree, except for people who need to set the CYGWIN environment
variable for some reason.  You have to do that before running bash.

Maybe we should be looking into introducing a way to set the CYGWIN
environment variable in the global environment and adding c:\cygwin\bin
(or whatever) to the global PATH as well.

But, I am extemely in favor of making mintty the default terminal.  It
would present a much nicer end-user experience out-of-the-box even if
some pty stuff doesn't work quite right.

And, I can just imagine the blog entries now: Cygwin finally offers an
intelligent terminal interface - after ten years!

The only downside that I see is that Andy may ask to renegotiate his
contract.  I wouldn't be surprised if he asked to be paid double what
he's getting now, in fact.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Charles Wilson

On 5/23/2011 1:25 PM, Christopher Faylor wrote:
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I disagree.  I deliberately keep cygwin paths out of my global PATH, so
that I can switch between various separate cygwin installs, and various
MinGW/MSYS installs, without them all conflicting with each other.

If we DO change setup to muck with global %PATH%, then we need another
checkbox to opt out.  (BTW, whatever happened to that 'check box
persistence' patch?)

 But, I am extemely in favor of making mintty the default terminal.  It
 would present a much nicer end-user experience out-of-the-box even if
 some pty stuff doesn't work quite right.

Oh, sure, I'm not against that. I specifically said #5 was fine with me:
  5) or punt.  Who needs linedraw anyway.
which was my way of saying: sure, go ahead and make mintty the default.
If we really care about linedraw, we can fix it later -- and I wonder if
we really DO care about it.  It sounds like the consensus here is: we
don't care /much/, but PTC...

And that's fine.

 And, I can just imagine the blog entries now: Cygwin finally offers an
 intelligent terminal interface - after ten years!

Yep, that + unicode support is the most obvious user-visible improvement
in the 'new user experience' in a long time.  Maybe even since the
hallowed B19 - B20.1 transition /cue choirs of angels.

Most of the other great improvements aren't immediately obvious to the
new user...

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Andy needs a tipjar -- and a plug on this page:
http://cygwin.com/donations.html

--
Chuck

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Corinna Vinschen

On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the file.
 ^^
 Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.
 
 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.
 
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I would really like to avoid that.  The question is, which CYGWIN
settings are really needed before an application starts?  Apart from the
debugging the Cygwin DLL scenario, the only one I can think of is the
tty setting, and that's about to go away.

IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
(CYGWIN=...) would change the CYGWIN settings for the calling process
as well.

Apart from that, maybe mintty could provide a CYGWIN environment
variable settings edit text in the properties dialog.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Uh oh.


Corinna

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

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread marco atzeri

On Mon, May 23, 2011 at 8:21 PM, Corinna Vinschen  wrote:
 On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the 
  file.
                     ^^
                     Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.

 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.

 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

 I would really like to avoid that.

same. Different PATHS make me sane and I run cygwin from an external drive
not always connected.

 The question is, which CYGWIN
 settings are really needed before an application starts?  Apart from the
 debugging the Cygwin DLL scenario, the only one I can think of is the
 tty setting, and that's about to go away.

 IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
 (CYGWIN=...) would change the CYGWIN settings for the calling process
 as well.

 Apart from that, maybe mintty could provide a CYGWIN environment
 variable settings edit text in the properties dialog.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

 Uh oh.


 Corinna

mintty as standard console will simplify a lot our life in supporting users,
so this proposal takes also my vote


Regards
Marco

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 02:16:42PM -0400, Charles Wilson wrote:
On 5/23/2011 1:25 PM, Christopher Faylor wrote:
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I disagree.  I deliberately keep cygwin paths out of my global PATH, so
that I can switch between various separate cygwin installs, and various
MinGW/MSYS installs, without them all conflicting with each other.

If we DO change setup to muck with global %PATH%, then we need another
checkbox to opt out.

That's what I mean by a way.  I know that people will complain if you
can't opt out but I think most people would like to be able to type
bash in their Search programs and files box and have bash start
automatically.  This would also help squash the myth that you have to
start some sort of magical Cygwin environment to use a Cygwin program
like grep.

(BTW, whatever happened to that 'check box persistence' patch?)

I think I volunteered to make the final check boxes persistent but it is
of such little importance to me that it will probably never get done.  I
don't think there has been another patch presented otherwise.

 And, I can just imagine the blog entries now: Cygwin finally offers an
 intelligent terminal interface - after ten years!

Yep, that + unicode support is the most obvious user-visible improvement
in the 'new user experience' in a long time.  Maybe even since the
hallowed B19 - B20.1 transition /cue choirs of angels.

Most of the other great improvements aren't immediately obvious to the
new user...

The one thing that isn't clear is how this will affect the putty*
users whose blog entries claim this as the only solution to the problem
of the cygwin terminal.  Will this impact them?  I sure hope so.

 The only downside that I see is that Andy may ask to renegotiate his
 contract.  I wouldn't be surprised if he asked to be paid double what
 he's getting now, in fact.

Andy needs a tipjar -- and a plug on this page:
http://cygwin.com/donations.html

I'd be thrilled to add Andy to that page if he wants.  The same goes for
any maintainer.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

On Mon, May 23, 2011 at 08:21:20PM +0200, Corinna Vinschen wrote:
On May 23 13:25, Christopher Faylor wrote:
 On Mon, May 23, 2011 at 06:04:37PM +0200, Corinna Vinschen wrote:
 On May 23 11:33, Charles Wilson wrote:
  as-is.  What if you really WANT to use cmdbox?  How else can a
  cygwin-shell-in-cmdbox be started, other than a .bat file of some kind?
   And since that's the only real way to do so, we ought to provide the 
  file.
 ^^
 Huh?
 
 You can simple create a Windows shortcut to bash.exe, edit it to
 add a --login option, and that's all you really need.
 
 I agree, except for people who need to set the CYGWIN environment
 variable for some reason.  You have to do that before running bash.
 
 Maybe we should be looking into introducing a way to set the CYGWIN
 environment variable in the global environment and adding c:\cygwin\bin
 (or whatever) to the global PATH as well.

I would really like to avoid that.  The question is, which CYGWIN
settings are really needed before an application starts?  Apart from the
debugging the Cygwin DLL scenario, the only one I can think of is the
tty setting, and that's about to go away.

IMHO it would be quite helpful if a setenv (CYGWIN, ...) or putenv
(CYGWIN=...) would change the CYGWIN settings for the calling process
as well.

Well, unless you make that change, all of the other Cygwin environment
variables (not just tty) need to be set before the first Cygwin
process in a tree is started.  Parsing the CYGWIN environment variable
on the fly is trivial but I don't know for sure if there are some
settings which only work right when set during program initialization.

cgf

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Andy Koppe

On 23 May 2011 17:04, Corinna Vinschen wrote:
On May 23 11:33, Charles Wilson wrote:
Uhm, maybe? :-)

In the former, I see pseudo-line drawing characters (e.g hyphens and
plus signs, etc), but in the latter I see real line draw characters.

Why?

I suspect the reason is the terminfo settings for mintty (e.g. for
xterm-256color) specifies
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
(inherited via terminfo 'use' statements from xterm-basic), while the
terminfo settings for cygwin specify
acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

e.g. the cygwin entry explicitly uses high codepoints for various line
draw stuff, (and cgywin's own terminal handling code does the magic to
replace them with unicode linedraw? or something?)

Whatever that is, I guess it may not be overly tricky to implement in
mintty as well, *if* somebody takes the time to report the problem.

Mintty does support that already. The feature was introduced by a
certain three-letter PC Unix company, and the Linux console supports
it too.

The DEC vtXXX series did not have that, however, which is why xterm
doesn't either. Instead, they have the DEC Special Character and Line
Drawing Set. When activated, character codes 0x60 to 0x7E map to
those special characters, as shown here:
http://vt100.net/docs/vt102-ug/table5-13.html. Mintty supports that
one too.

My point: there are some things that don't yet seem to work right in
mintty, and I'm not really sure where the problem is.

Chuck, what font are you using in mintty? It could just be that it
doesn't have glyphs for the relevant codepoints, in which case mintty
falls back to ASCII replacements. The default Lucida Console does have
the linedrawing glyphs needed for the vt100 set.

If it's not that, then the xterm terminfo entry would indeed need a closer look.

You can test support for the CP437 alternate charset, the vt100
graphics, and also direct Unicode line drawing by catting the attached
file created by Thomas Wolff.

Andy

xgraphics
Description: Binary data

Re: setup and mintty (was Re: New setup.exe release?)

2011-05-23 Thread Andy Koppe

On 23 May 2011 12:50, Corinna Vinschen wrote:
 On May 20 17:09, Yaakov (Cygwin/X) wrote:
 The setup.exe download is still 2.738.  Could it be updated to 2.749
 to include jturney's recent bug fixes?

 I'd like to fix the mintty issue first.

 So, do we swtch to mintty as default terminal, yes or no?

 If we switch to mintty we don't need the Cygwin.bat file anymore.  But,
 shouldn't we keep it anyway for people who maintain some handmade symlink
 to it?

Yes, I think so.

 If so, should we stick to the content of Cygwin.bat as is, or should
 we change it to call mintty, too?

Better not, so as not to change people's existing setup. And because
it would flash up a console for the .bat.

 And who's going to create the patches?

I suppose that should be me, but my spare time is rather limited at
the moment and I still owe a patch or two for other things.

 Last but not least, shouldn't we add mintty to the Base package
 anyway, independently of what we do to setup?

Seems sensible.

Further all this, if the change to mintty as the default is going
ahead, there's the question of what the desktop shortcut should do and
what it should be called.

What it should do:
1) Invoke the user's default shell as set in /etc/passwd as a login
shell. (This is what the mintty start menu shortcut currently does)
2) Invoke bash as a login shell.

What it should be called:
a) mintty: Few are going to know what that is.
b) Cygwin Bash Shell: That's the current name of course. Not
compatible with option 1 above.
c) Cygwin Shell: Shell-neutral, but encourages the confusion between
terminal and shell.
d) Cygwin Terminal: Linux desktops usually have Terminal entries
in their menus.
e) something else?

I also think the console's start menu entry in the Cygwin folder
should be kept, perhaps with a new name. Console vs Terminal?

Andy

Re: setup and mintty (was Re: New setup.exe release?)