Re: forked before bash subshell

[L. A. Walsh]

Daniel Colascione wrote:
> On 10/15/2016 12:23 AM, L. A. Walsh wrote:
>
>
> Daniel Colascione wrote:
> One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
> has an old-fashioned non-COW fork, and to add insult to injury,
> process creation generally is very slow (~100ms). It pays to eliminate
> subshells in that environment.
> > Given what Cygwin has to work around in Windows -- it is very contrived.
>
> Maybe the internals. From the perspective of programs like bash, 
> Cygwin is a mostly ordinary POSIX environment, one with lots of users 
> and that deserves full support.
---
   Oh?  It's a hack to bring POSIX-like functionality to allow for programs
and scripts to be run on a Windows machine.  FWIW, I've used it for 
about 15+
years.  I use almost identical bash-login+startup scripts on my windows
box as I do on my Linux box.  The scripts do check if they are running
on cygwin and define a function for later ease-of-use:

 if ! type -f cygwin 2>/dev/null ; then
   read SYSTEM_KERNEL HOSTNAME OSTYPE <<<"$($_prg_uname -sno)"
   if [[ $OSTYPE =~ Cygwin ]]; then cygwin () { return 0; }
   else cygwin () { return 1; }
   fi
   export -f cygwin
 fi

Later I use 'cygwin' to setup a proxy for my winhost and read a few
win/cygwin specific aliases in (like mklink):

if cygwin ; then
 source /etc/local/cygwin/aliases.sh
fi


> > MS has copy-on-write available to MS processes, that it's not usable in
> > Cygwin isn't surprising given that most of Windows is closed-source.
>
> It has nothing to do with being closed source and everything to do 
> with the win32 subsystem (under which Cygwin runs) not being designed 
> to cope with process duplication.
---
I'm fairly sure that the win32 API is insufficient for emulating the POSIX
environment and that cygwin uses other Windows NT calls to get its job done.
CoW is available in the NT-kernel, but since windows processes don't
"fork" (they issues a request to a process-spawner to create a new 
process --
an expensive and clumsy task (windows has a high overhead for creating
new processes, but last I saw any statistics (some time ago), it was
faster in creating new threads compared to linux. 

That's partly due to linux not having threads as a separate kernel object,
but emulating them via processes.  I.e. - a linux thread is, _basically_,
another process (though, *very* slightly lighter weight) with more common
areas shared with the parent processes than a normal fork call would share.

The fact that cygwin has done so much is a testament to the teams hard
work at looking under the covers of the closed-source OS, since much of
what they need to do, not only isn't part of the Win32 API, but isn't
officially published by MS anywhere.
> > But if you really want bash on your windows, use a native copy.  It's
> > not as likely to have the same problems
> > (https://techcrunch.com/2016/03/30/be-very-afraid-hell-has-frozen-over-bash-is-coming-to-windows-10/) 
>
> It doesn't do the same thing. Cygwin is an integrated POSIXish 
> environment.
----
   Nothing ever does the exact same thing as anything else -- even 
itself. However, if you look at the pics it shows the drives mounted 
under a directory
(they used /mnt) just like in cygwin (which uses /cygwin by default), but I
find better integration twixt cygwin & windows by using '/' as my 
prefix-dir,
putting my drives at /c, /d, /s ... and my bin+lib dirs @ /bin and /lib on
C.

   Also the MS-bash instance is running in the same file-system 
namespace as
Windows.  A directory listing of /mnt/c shows a permission denied error for
a few Admin-only files, and then shows the normal C:-drive root contents.

And just like in cygwin, they use '/' as the file-separator (since NT 
can use
either).  Note, the article says this:

 While Microsoft pitches this feature as “Bash shell” environment, it’s
 actually an underlying compatibility layer that allows you to run Linux
 software on Windows. That means you can run other shells instead of Bash,
 if you prefer them.
---
I.e. MS's bash will run on a compatibility layer -- just like bash running
under cygwin.


> > Apparently there is a Windows Subsystem for Linux that is currently 
> > in Beta
> > for Win10:
> > http://www.howtogeek.com/265900/everything-you-can-do-with-windows-10s-new-bash-shell/ 
>
> SFU and similar do not interact with the win32 subsystem as closely as 
> Cygwin and so can't provide the same experience. IMHO, you might as 
> well run a VM.
----
   SFU is no longer available -- and this is not using that subsystem.
BTW -- to respond to this statement:


Daniel Colascione wrote:
> It pays to eliminate subshells in that environment.
---
   You really want bash to function differently on cygwin than it does on
any other platform?  Or, you would really suggest that bash re-architect 
itself
on all platforms to support it running on cygwin, when, at the same time,
MS is bringing their own version of bash to windows?  That seems like
a very risky proposition with little to no payout.  There's no
guarantee that cygwin will run on Windows 11 or 12, or that you will even be
allowed to load your own SW when MS requires Secureboot for all MSWin-logo
computers.

   But if you have enough funds to donate to the project, who knows, 
you might
be able to change their mind...

   They also, usually welcome well-thought out patches or contributions 
to their code -- so if it is something you really want, you might consider
offering patches to bash and/or cygwin...

Cheers!
-l