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 Content-Type: text/plain To: "'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".