On Dec  4 04:20, Linda Walsh wrote:
> Andrey Repin wrote:
> >Greetings, cyg Simple!
> >>>>Don't forget that CMD will not create a second connection to a
> >>>>\\host\share if Cygwin already has one open.
> >>>What do you mean by that?
> >
> >>$ cd //somehost/someshare
> >>$ cmd /c start cmd
> >
> >>cmd will complain about UNC paths and start in %WINDIR% instead.
> ----
> Try it the other way around.  You'll get the same result.
> 
> It has nothing to do with cygwin opening it first.  It has
> to do with cmd not handling a "\\network\share" style address.
> 
> MS was too lazy to deal with command.com's "1-CurDir / drive"
> scenario that is embedded in the Win32 interface.  If you cd to
> //host/<currentdir>, //host isn't a drive letter.

It will get interesting with the new CMD from Windows 10.  MSFT has a
whole team now working on pulling CMD into the 21st century of CLIs.
Allowing UNC paths as CWD is apparently on their radar, though the
current latest CMD in the W10 preview is still missing this feature.

> So what happens when the user uses an absolute path?  "/tmp"...
> where is that /tmp?   Ends up at the root of each drive, but on
> a UNC-based-net-connection?  Undefined.  So cmd.exe can't be used
> on a UNC-based path, only on DOS compatible (drive letter
> assummed) based-path.

Allowing CMD as shell wouldn't change how Cygwin tools see the world.
Yes, with current CMDs you won't be able to utilize network paths as
CWD, among other restrictions.  Still, evaluating "db_shell: windows" as
using CMD, rather than being a no-op might hvae some value.  I would
never use it myself, but there may be some people, or, let's assume,
special maintainance accounts, for which this might come in handy.

Would it hurt to implement it, even only for symmetry with the other
options?  I'm not sure.


Corinna

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