From:	sos AT prospect DOT com DOT ru (Sergey Okhapkin)
Subject:	RE: BugView updated.
11 Jul 1997 16:03:12 -0700 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<01BC8E11.A9214790.cygnus.gnu-win32@sos>
Original-To:	"'David Coe'" <david AT coent DOT demon DOT co DOT uk>
Original-Cc:	"'gnu-win32'" <gnu-win32 AT cygnus DOT com>
Encoding:	51 TEXT
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

David Coe wrote:
> The principle of CYGWIN_NOTTY seem a good idea. Although of course it is
> possible to re-port back to gnu-win32 all those old unix apps (less,
> ncftp, micro emacs, emacs -nw, beav, elvis) it would be a shame to lose
> the ability to launch their existing native console-direct
> implementations from the same command window.

Re-porting to gnu-win32 seems to me the best solution - you're able to run 
direct-console applications in a console only, but re-ported - in a console 
(with the same functionality), in a telnet session, in Xterm window and via 
communication port/modem. What is better?-)

>
> Unless I'm doing something wrong though, CYGWIN_NOTTY is not doing quite
> the thing I would expect (at least on NT4). Setting it before launching
> bash is fine - I get a cygwin environment that allows console direct but
> not pseudo-tty. Setting it within bash, however, does not switch to
> allow launching of console direct apps; in fact, even things like ls no
> longer produce output!!

Bash started without CYGWIN_NOTTY creates control tty threads and redirects 
standard handles of a childs to a pipes, connected to ctty. But childs do 
not makes connection to ctty because CYGWIN_NOTTY is set. There is no way 
to fall back to notty mode. At least, for a now... The main troubles are in 
standard handles redirection.

>
> Have you also made some changes to the reporting and use of ownership?
> Ls -l now reports usernames rather than numerical IDs. There is, for

There was a bug in /etc/passwd reading code, but you had to see usernames 
with this bug. I never had such a problem.

> example, some impact (which I don't yet understand) on the operation of
> the command line in mc-4.0 which works fine (with a # prompt) using your
> cygwin.dll from 06 Jul but only works under an Administrator account
> using the 10 Jul dll. From a User account it gives (correctly) a $
> prompt but (incorrectly) will launch nothing from it ... just like with
> the unpatched B18 cygwin.dll.

Try to remove <cr>s from /etc/passwd. If it will not help, remove shell 
fields from /etc/passwd and set environment variable SHELL to /bin/sh.

> Anyway, it's all very exciting.

Thank You!

--
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -