From:	John DOT Wiersba AT medstat DOT com (John Wiersba)
Subject:	Re: shell escape...and more questions/utility bugs
22 Oct 1998 14:12:44 -0700 :
Message-ID:	<03F4742D8225D21191EF00805FE62B9993C660.cygnus.gnu-win32@mail.medstat.com>
Mime-Version:	1.0
To:	"'gnu-win32 AT cygnus DOT com'" <gnu-win32 AT cygnus DOT com>

>I'm very new at gnu-win32.  From within vim, I try :!sh and get
>   Cannot execute shell /bin/bash^M
>Same for trying to execute other programs from within vim.  
>This is using both version 5.2f ALPHA and 5.0p ALPHA of vim.  I have
>installed (some) version of coolview -- uname -a shows
>   CYGWIN32_NT machine 4.0 19.3 i686 unknown
>
>When I searched the mailing list archives, I found some headers which
>apparently matched from about March, but the engine couldn't retrieve
>the body of the messages.

Thanks to a clue from Larry Hall, I managed to fix this.  The problem
was that I was starting bash from a .bat file which was in dos (CRLF)
format.  For some reason, bash set the SHELL environment variable to
SHELL=/bin/bash^M.  Changing the .bat file to unix (LF) format fixed
this.  Can bash be fixed in subsequent versions to prevent this problem?

Q1) After rebooting, I see that SHELL=/bin/sh.  How does bash determine
whether to assign /bin/sh or /bin/bash as the value of SHELL?

Q2) I'm getting some strange behavior from less 3.22 (from
ftp.franken.de) along with ncurses 4.1 (also from ftp.franken.de) with
TERM=linux.  When ever it wraps a line, it generates an extra blank
line, so I get output looking like:
   pretend that this is a line longer than 80 chara
   
   cters
Less works with TERM=ansi, however.  Why is this?  I've also experienced
this with another version of less (I forget where I got it) which
doesn't require ncurses.  With this other version, neither ansi nor
linux worked.

Q3) If I set CYGWIN32=tty, then execute bash from a bash command line,
the subshell is blocked as if it were a background job.  Once I bring it
to the foreground (fg %1), it works normally.  Why is this?  It's forced
me to turn off tty, but I understand that tty is necessary to work
around other problems.

Q4) Apparently, not using NTFS, the UID:GID for files is always read as
0:0, even when UID != 0.  This doesn't seem right.

Q5) Symlinks doen't seem to be working quite right, yet.  I have the
following symlinks set:
   /jrw -> d:/jrw
   /qub -> /jrw/binu/qub
When I "cd /qub", my pwd is "/qub".  However, when my current directory
is /, "cd qub" produces a pwd
of "//d/jrw/binu/qub".  This is not elegant.  Also, from /jrw, "cd
.../qub" produces "bash: cd: ../qub: Permission denied".  Does anyone
know what's going on?  The third case, I think I understand (bash is not
treating .. as the logical parent, but as the physical parent -- this
seems like a bash bug).  But I would think that from the root, qub and
/qub should always be treated identically.

John Wiersba (john DOT wiersba AT medstat DOT com)

P.S. With or without bugs, I'm very happy to have a real shell and some
utilities to use under WinNT.  Thanks, guys!
-
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 -