Understanding program startup

Understanding program startup

[DG Ellis]

  I am not new to C programming, however, I am new to writing programs 
that run under a unix shell like bash.  For history, I found that single 
quotes are not respected by applications that use cygwin.dll when the 
program is invoked from outside bash. I chased down the code to the 
winsup/dcrt0.cc source file and was busy modifying it when I decided to 
check on the behavior of "normal" command lines under bash and under NT.
Well, I see where the code should behave certain ways and does when run 
under NT command processor, but does not behave at all the same when 
under bash.  Now here is my question:
  My suspicion is that the routine dll_crt0_1 is not called if the 
program is run under the shell. Is this correct?  I will try to check on 
libc's crt0 to see if this is true (if I can find the source).  It looks 
like there are a lot of important things in the dll_crt0_1 routine that 
should be done in each case. If they don't get done, what happens?
Could this be the ctrl-C crash problem???

   Dave Ellis
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: What is a "forward slash"

[Michael Hirmke]

Glenn Spell [glenn@gs.fay.nc.us] wrote:

>On 5 Mar 2000 around 12:47PM (+0200) Michael Hirmke wrote:
>
>> Use forward slashes for the mount command.
>
[...]
>Actually, I'm waiting for folks to start using the phrase "backward
>slash"... then it will really get interesting.

Excuse me, the above quoted text should read:

>> Don't use backward slashes for the mount command.

:))

>
>-glenn

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: various packages

[Michael Hirmke]

Chris Faylor [cgf@cygnus.com] wrote:

[...]
>>the background. Anybody interested in this and if yes, can anybody help
>>in providing an ftp server for the distribution ?
>>
>>I am also an (old fashioned :-) user of AT&T's/Lucent's 'sam' editor and
>>have ported that to NT. Any interest in this ?
>
>Michael Hirmke (mh@mike.franken.de) maintains a site which has lots of
>cygwin ports.  He'll probably be glad to host your ports.

I would be glad, indeed.
If you wish to, please follow these steps:

------------------------< snip snip snip >-----------------------------
   - This site does not only collect Cygwin packages, but packages for
     all available Unix emulation layers or subsystems for Windows
     32bit. For that reason the name did not change to Cygwin, but
     remains GNUWin32! At the moment there are packages for Cygwin and
     Mingw32 available.
   - How to upload to our German GNUWin32 site:
  
         site: ftp.franken.de
         user: ftp/anonymous
     password: <email address>
  
     To get directly to the GNUWin32 upload/incoming directory type
     "cd gnuwin32:" (note the colon following "gnuwin32") and then
     "cd incoming"
  
     Please always add a short readme on what you've uploaded. Please
     do also provide the appropriate source package with exactly the
     same source you used to build your binary package. This is
     absolutely necessary to satisfy the GPL under which the Cygwin
     libraries are distributed. These are the ones you presumably
     linked your package against.
  
     I'd like best, if the description would follow this format:
  
     ----------------------< snip snip snip >-------------------------
     *<package name>*
     --------------
  
     - what is it?
       - <short package description>
  
     - system
       - <system type, i.e. Windows NT4, Windows 95, ...>
  
     - Cygwin/Mingw
       - for <which Cygwin/Mingw version>
   
     - preliminaries
       - get the source package
         - <name of the source package>
         it can be found
         - on <server name>
         - in <path name>
         - as <package name>
       - <which other arrangements to make>
  
     - configure
       - <which changes and parameters are necessary for configure>
  
     - make
       - <which changes and parameters are necessary for make>
  
     - make install
       - <which changes and parameters are necessary for make install>
  
     - notes
       - <what else might be interesting to know>
  
     - package availability
       - on <site name>
       - in <path>
       - as <package name>
  
     - contributed by
       - <email address> (<your name>)
     ----------------------< snip snip snip >-------------------------
  
     There is no need to tell me, that you have uploaded something,
     because I'll get informed automatically.
  
     Please note:
     *I will delete anything, which does not look like a useful*
     *GNUWin32 package !*
     *So please don't upload any warez, spam or similar garbage !*
------------------------< snip snip snip >-----------------------------

>cgf

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: new install of cygwin with pdksh doesn't work

[Earnie Boyd]

--- "David M. Karr" <dkarr@tcsi.com> wrote:
> >>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>   Earnie> --- "David M. Karr" <dkarr@tcsi.com> wrote:
>   >> 
>   >> I'm sure this has something to do with line endings, but I don't
>   >> understand what has to be done.
> 
>   Earnie> Then use setup to install Cygwin on the other machine.  It does all
> that needs
>   Earnie> to be done for those who don't know what to do.
> 
> I did.  I installed Cygwin with "setup", then installed "pdksh".  The
> given error is what I get when I try to execute "ksh".  I don't get
> that when I try to use "bash".  

Cygwin bash has been modified to handle this crap.

> However, on my own PC, where I
> installed Cygwin & pdksh a couple of months ago, I don't see this
> problem at all.
> 

Compare the differences of the output of `cygcheck -s -r -v' from both systems.
 I'm guessing you have mixed text vs binary mounts somewhere.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

cygcheck output from \"good\" installation
cygcheck output from \"bad\" installation
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


[-- Attachment #2: nachos.cygcheck.out --]
[-- Type: text/x-Algol68, Size: 7865 bytes --]


Cygnus Win95/NT Configuration Diagnostics
Current System Time: Wed Dec 20 17:26:23 2000

WinNT Ver 4.0 build 1381 Service Pack 6

Path:	/cygdrive/d/jdk1.3/bin
	/usr/bin
	/cygdrive/c/WINNT4/SYSTEM32
	/cygdrive/c/WINNT4
	/cygdrive/c/atria/bin
	/cygdrive/d/emacs-20.7/bin
	/cygdrive/d/gnuserv
	/cygdrive/c/WINDOWS
	/cygdrive/c/WINDOWS/COMMAND
	/cygdrive/c/shiva
	/cygdrive/c/PROGRA~1/SSHCOM~1/SSHSEC~1
	.
	//d/dmk/lisp/jde-2.1.8/lisp
	/usr/local/bin

SysDir: C:\WINNT4\System32
WinDir: C:\WINNT4

PWD = `/cygdrive/d/dmk/java/propmaster/demo/guitest'
USER = `dkarr'
MAKE_MODE = `unix'
HOME = `/cygdrive/d/dmk'

NUMBER_OF_PROCESSORS = `1'
PROMPT = `$p$g'
LOGONSERVER = `\\ALYSSA'
OS2LIBPATH = `C:\WINNT4\system32\os2\dll;'
TMPDIR = `/cygdrive/c/TEMP'
COMSPEC = `C:\WINNT4\system32\cmd.exe'
PAGER = `less'
SYSTEMDRIVE = `C:'
HOSTNAME = `NACHOS'
PROCESSOR_REVISION = `0502'
EMACSLOCKDIR = `D:/emacs-20.7/lock'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
COMPUTERNAME = `NACHOS'
JAVAHELP_HOME = `d:/jh1.1'
WINDIR = `C:\WINNT4'
USERPROFILE = `C:\WINNT4\Profiles\dkarr'
PROPMASTER_HOME = `d:/dmk/java/propmaster'
EMACSPATH = `D:/emacs-20.7/bin'
WINBOOTDIR = `C:\WINDOWS'
ENV = `/cygdrive/d/dmk/.bashrc'
EMACSDOC = `D:/emacs-20.7/etc'
MACHTYPE = `i686-pc-cygwin'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 2, GenuineIntel'
EMACS = `t'
SBOOTP = `c:\shiva'
OS = `Windows_NT'
OLDPWD = `/cygdrive/d/dmk'
PROCESSOR_ARCHITECTURE = `x86'
TEMP = `/cygdrive/c/TEMP'
SHIVA = `c:\shiva'
TERMCAP = `emacs:co#80:tc=unknown:'
PROCESSOR_LEVEL = `6'
SYSTEMROOT = `C:\WINNT4'
TMP = `/cygdrive/c/TEMP'
HOMEDRIVE = `C:'
EMACS_DIR = `D:/emacs-20.7'
EMACSDATA = `D:/emacs-20.7/etc'
SHLVL = `1'
TP_OPTS = `-m DRAFT -i --n -C --f --F -S 2 -4'
HOMEPATH = `\'
USERDOMAIN = `BOTHELL'
MPAGE = `-4 -b Letter -H -X -c -f -z lp'
SHELL = `bash'
USERNAME = `dkarr'
EM_PARENT_PROCESS_ID = `340'
HOSTTYPE = `i686'
EMACSLOADPATH = `D:/emacs-20.7/site-lisp;D:/emacs-20.7/lisp;D:/emacs-20.7/leim'
OSTYPE = `cygwin'
HISTSIZE = `64'
TERM = `emacs'
JDKHOME = `d:/jdk1.3'
LOG4J_HOME = `d:/log4j-v0.9.1'
PATHSEP = `;'
_ = `/usr/bin/cygcheck'
TZ = `PST8PDT7,M4.1.0/2,M10.5.0/2'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000022
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `d:/cygwin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `d:/cygwin/bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `d:/cygwin/lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

a:  fd           N/A    N/A                    
c:  hd  FAT     2047Mb  83% CP    UN           
d:  hd  NTFS    6008Mb  40% CP CS UN PA FC     
e:  cd           N/A    N/A                    
f:  cd           N/A    N/A                    
g:  net NTFS    4282Mb  20% CP CS UN PA FC     Dev
m:  net MVFS    1000Mb  50% CP CS              CCase

d:\cygwin\bin  /usr/bin  system  binmode
d:\cygwin\lib  /usr/lib  system  binmode
d:\cygwin  /        system  binmode

Found: d:\cygwin\bin\bash.exe
Found: d:\cygwin\bin\cat.exe
Found: d:\cygwin\bin\cpp.exe
Found: d:\cygwin\bin\find.exe
Found: c:\WINDOWS\COMMAND\find.exe
Warning: d:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe
Found: d:\cygwin\bin\gcc.exe
Found: d:\cygwin\bin\gdb.exe
Found: d:\cygwin\bin\ld.exe
Found: d:\cygwin\bin\ls.exe
Found: d:\cygwin\bin\make.exe
Found: d:\cygwin\bin\sh.exe

   56k 2000/12/03 d:\cygwin\bin\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz21.0.dll" v0.0 ts=2000/11/20 15:53
   45k 2000/12/07 d:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
                  "cygform5.dll" v0.0 ts=2000/12/6 22:41
   18k 2000/10/23 d:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
                  "cyggdbm.dll" v0.0 ts=2000/10/22 19:26
   17k 2000/11/30 d:\cygwin\bin\cyghistory4.dll - os=4.0 img=1.0 sys=4.0
                  "cyghistory4.dll" v0.0 ts=2000/11/29 18:28
   14k 2000/10/23 d:\cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl.dll" v0.0 ts=2000/10/23 12:02
   81k 2000/12/05 d:\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=2000/11/25 17:43
   35k 2000/12/05 d:\cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=2000/11/25 17:43
   45k 2000/10/22 d:\cygwin\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
                  "cygjbig1.dll" v0.0 ts=2000/10/22 16:06
  119k 2000/10/23 d:\cygwin\bin\cygjpeg6b.dll - os=4.0 img=1.0 sys=4.0
                  "cygjpeg6b.dll" v0.0 ts=2000/10/22 17:58
   26k 2000/12/07 d:\cygwin\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu5.dll" v0.0 ts=2000/12/6 22:40
  159k 2000/12/07 d:\cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++5.dll" v0.0 ts=2000/12/6 22:42
  225k 2000/12/07 d:\cygwin\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses5.dll" v0.0 ts=2000/12/6 22:39
   15k 2000/12/07 d:\cygwin\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel5.dll" v0.0 ts=2000/12/6 22:40
  162k 2000/10/23 d:\cygwin\bin\cygpng2.dll - os=4.0 img=1.0 sys=4.0
                  "cygpng2.dll" v0.0 ts=2000/10/22 17:40
  108k 2000/11/30 d:\cygwin\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0
                  "cygreadline4.dll" v0.0 ts=2000/11/29 18:28
  390k 2000/12/05 d:\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=2000/11/25 17:39
    5k 2000/12/05 d:\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 2000/12/05 d:\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=2000/11/25 17:39
  243k 2000/10/23 d:\cygwin\bin\cygtiff3.dll - os=4.0 img=1.0 sys=4.0
                  "cygtiff3.dll" v0.0 ts=2000/10/22 18:14
  623k 2000/12/05 d:\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=2000/11/25 17:43
   41k 2000/11/20 d:\cygwin\bin\cygXpm-noX4.dll - os=4.0 img=1.0 sys=4.0
                  "cygXpm-noX4.dll" v0.0 ts=2000/11/19 18:41
   45k 2000/11/20 d:\cygwin\bin\cygXpm-X4.dll - os=4.0 img=1.0 sys=4.0
                  "cygXpm-X4.dll" v0.0 ts=2000/11/19 18:45
   49k 2000/10/23 d:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
                  "cygz.dll" v0.0 ts=2000/10/22 17:22
  609k 2000/11/22 d:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/11/21 18:00
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 6
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 30
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix: 
        build date: Tue Nov 21 21:00:16 EST 2000
        shared id: cygwin1S3

Use -h to see help about each section



-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


[-- Attachment #3: popcorn.cygcheck.out --]
[-- Type: text/x-Algol68, Size: 10289 bytes --]


Cygnus Win95/NT Configuration Diagnostics
Current System Time: Wed Dec 20 17:18:57 2000

WinNT Ver 4.0 build 1381 Service Pack 6

Path:	/cygdrive/d/IONA/BIN
	/cygdrive/d/JDK1.3/BIN
	/cygdrive/d/DMK/BIN
	/usr/bin
	/cygdrive/c/WINNT/SYSTEM32
	/cygdrive/c/WINNT
	/cygdrive/c/atria/bin
	/cygdrive/d/winvi
	/cygdrive/d/emacs-20.7/bin
	/cygdrive/d/gnuserv
	/cygdrive/d/mpage
	/cygdrive/d/miscbins
	.
	/cygdrive/d/dmk/lisp/jde-2.1.8/lisp
	/usr/local/bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

HOME = `/cygdrive/d/dmk'
MAKE_MODE = `unix'
PWD = `/cygdrive/d/dmk/java'
USER = `dkarr'

ACME_HOME = `d:/dmk/java'
CLASSPATH = `d:\jdk1.3\lib\tools.jar;d:\xerces-1_1_3\xerces.jar;.;d:\jakarta-tomcat\lib\jasper.jar;d:\jakarta-tomcat\lib\xml.jar;d:\jakarta-tomcat\lib\servlet.jar;d:\jakarta-tomcat\lib\webserver.jar;d:\jakarta-tomcat\classes'
COMPUTERNAME = `POPCORN'
COMSPEC = `C:\WINNT\system32\cmd.exe'
EMACS = `t'
EMACSDATA = `D:/emacs-20.7/etc'
EMACSDOC = `D:/emacs-20.7/etc'
EMACSLOADPATH = `D:/emacs-20.7/site-lisp;D:/emacs-20.7/lisp;D:/emacs-20.7/leim'
EMACSLOCKDIR = `D:/emacs-20.7/lock'
EMACSPATH = `D:/emacs-20.7/bin'
EMACS_DIR = `D:/emacs-20.7'
EM_PARENT_PROCESS_ID = `597'
ENV = `/cygdrive/d/dmk/.bashrc'
GETOPT_HOME = `d:/dmk/java/propmaster/java-getopt'
HISTSIZE = `64'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `POPCORN'
HOSTTYPE = `i586'
IT_CONFIG_PATH = `d:/Iona/config'
IT_ERRORS = `d:\iona\config\ErrorMsgs'
JAVAHELP_HOME = `d:/jh1.1'
JAVA_HOME = `d:/jdk1.3'
JDKHOME = `d:/jdk1.3'
JHHOME = `d:/jh1.1'
LOG4J_HOME = `d:/log4j-v0.8.5b'
LOGONSERVER = `\\ALYSSA'
MACHTYPE = `i586-pc-cygwin'
MPAGE = `-4 -b Letter -H -X -c -f -z lp'
NUMBER_OF_PROCESSORS = `1'
OLDPWD = `/cygdrive/d/dmk/java/linebreak'
ORBIXWEB_HOME = `d:\Iona'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `cygwin'
PAGER = `less'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PATHSEP = `;'
PRIMARY_CLEARCASE_GROUP = `gtenmo'
PRINTER = `"\\ALYSSA\steel"'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 2, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0502'
PROPMASTER_HOME = `d:/dmk/java/propmaster'
SHELL = `bash'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `/cygdrive/c/TEMP'
TERM = `emacs'
TERMCAP = `emacs:co#81:tc=unknown:'
TMP = `/cygdrive/c/TEMP'
TMPDIR = `/cygdrive/c/TEMP'
TOMCAT_HOME = `d:\jakarta-tomcat'
TP_OPTS = `-m DRAFT -i --n -C --f --F -S 2 -4'
USERDOMAIN = `BOTHELL'
USERNAME = `dkarr'
USERPROFILE = `C:\WINNT\Profiles\dkarr'
WINDIR = `C:\WINNT'
XALAN_HOME = `d:/xalanj-1.2'
XERCES_HOME = `d:/xerces-1_1_3'
_ = `/usr/bin/cygcheck'
dospathinbash = `() {  echo $(cygpath -w $1) | sed -e 's,\\,/,g'
}'
TZ = `PST8PDT7,M4.1.0/2,M10.5.0/2'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `d:\cygwin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `d:/cygwin/bin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `d:/cygwin/lib'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
  (default) = `C:'
  unix = `/'
  fbinary = 0x00000000
  fsilent = 0x00000000
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Installed Components
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Installed Components\d:/cygwin
  (default) = `20000517'
  bash = `0002.0004.0001'
  binutils = `19990818.0002'
  bison = `0000'
  byacc = `0000'
  bzip = `0000'
  clear = `0001.0000'
  cygwin = `0001.0001.0002'
  dejagnu = `0000'
  diff = `0000'
  expect = `0000'
  fileutils = `0000'
  findutils = `0000'
  flex = `0000'
  gawk = `0003.0000.0004'
  gcc = `0002.0095.0002.0002'
  gdb = `20000610'
  gperf = `0000'
  grep = `0000'
  groff = `0001.011a.0001'
  gzip = `0000'
  inetutils = `0001.0003.0002.0004'
  less = `0000'
  libpng = `0001.0000.0006.0001'
  login = `0001.0003'
  m = `0000'
  make = `0003.0079.0002'
  man = `0001.005g.0002'
  opengl = `0001.0002.0001.0001'
  patch = `0000'
  sed = `0003.0002.0001'
  shellutils = `0000'
  tar = `0000'
  tcltk = `20000610'
  termcap = `20000618.0001'
  texinfo = `0000'
  textutils = `0000'
  time = `0000'
  zlib = `0001.0001.0003.0001'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\03
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\04
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\05
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\06
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\07
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\08
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\09
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0E
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\0F
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\10
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\11
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\12
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\13
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\14
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\15
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\16
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\17
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\18
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\19
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1A
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1B
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1C
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\1D
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
  (default) = `d:\cygnus-b20\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnus Cygwin B20
  (default) = `C:\WINNT\IsUninst.exe -fd:\cygnus-b20\cygwin-b20\Uninst.isu'
  DisplayName = `Cygwin B20'

a:  fd           N/A    N/A                    
c:  hd  FAT     1498Mb  83% CP    UN           
d:  hd  NTFS    6557Mb  44% CP CS UN PA FC     
e:  cd           N/A    N/A                    
f:  net NTFS    4282Mb  20% CP CS UN PA FC     Dev
m:  net MVFS    1000Mb  50% CP CS              CCase
z:  net MVFS    1000Mb  50% CP CS              CCase

d:\cygwin\bin  /usr/bin  user    binmode
d:\cygwin\lib  /usr/lib  user    binmode
d:\cygwin  /        user    binmode

Found: d:\cygwin\bin\bash.exe
Found: d:\cygwin\bin\cat.exe
Found: d:\cygwin\bin\cpp.exe
Found: d:\cygwin\bin\find.exe
Found: d:\cygwin\bin\gcc.exe
Found: d:\cygwin\bin\gdb.exe
Found: d:\cygwin\bin\ld.exe
Found: d:\cygwin\bin\ls.exe
Found: d:\cygwin\bin\make.exe
Found: d:\cygwin\bin\sh.exe

   83k 2000/06/11 d:\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=2000/6/10 20:34
   35k 2000/06/11 d:\cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=2000/6/10 20:34
  402k 2000/06/11 d:\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=2000/6/10 20:30
    5k 2000/06/11 d:\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 2000/06/11 d:\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=2000/6/10 20:30
  639k 2000/06/11 d:\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=2000/6/10 20:34
  586k 2000/08/04 d:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/8/3 17:53
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 4
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        api major: 0
        api minor: 26
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        build date: Thu Aug 3 20:53:46 EDT 2000
        CVS tag: cygwin-1-1-4
        shared id: cygwin1S3

Use -h to see help about each section

Re: new install of cygwin with pdksh doesn't work

[Chris Abbey]

As Earnie suggested, comparing the outputs, with attention to the mount
point information will show that /cygdrive/? is mounted differently between
the two machines, popcorn (I'll guess is the working one) mount with the
flags as 0x0020 while nachos (I'll guess doesn't work) mounts with 0x0022.
I'll venture a guess that you're accessing the scripts from /cygdrive/?/...
right? (because the other mounts are the same for both.

a solution, as Christopher suggested, is to remove the ^M from the files.
the easiest way I know of to do this is to pipe the script through "tr -d '\r'"
so for example:

tr -d '\r' < /cygdrive/c/myscript > /tmp/myscript
mv -f /tmp/myscript /cygdrive/c/myscript

the other would be to mount the location of the script in an explictly
controlled mount point (text mode), or to change the default mount
mode.



now the forces of openness
     have a powerful and
     unexpected new ally
    http://ibm.com/linux/


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Earnie Boyd]

--- "David M. Karr" <dkarr@tcsi.com> wrote:
> 
> I don't understand the option of setting text mode mount points.  I
> have no idea what the ramifications of that would be.
> 

Sigh.  How long have you been on this list?  I'll now suggest that you refer to
the documentation, FAQ and mail archives for which you can find URL pointers at
http://cygwin.com .

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  Earnie> --- "David M. Karr" <dkarr@tcsi.com> wrote:
  >> 
  >> I don't understand the option of setting text mode mount points.  I
  >> have no idea what the ramifications of that would be.

  Earnie> Sigh.  How long have you been on this list?  I'll now suggest that you refer to
  Earnie> the documentation, FAQ and mail archives for which you can find URL pointers at
  Earnie> http://cygwin.com .

Ok, fine.  I apologize.  I have unpacked and printed the user's guide.
I'll read it.  I've already looked through the FAQ and found nothing
very useful.  I'll look through the mail archives later.

In the meantime, can someone verify whether rerunning setup and
setting the "DOS" text file type should resolve my problem?  When I
tried that, it appeared to have no effect.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  Earnie> --- "David M. Karr" <dkarr@tcsi.com> wrote:
  >> 
  >> I don't understand the option of setting text mode mount points.  I
  >> have no idea what the ramifications of that would be.

  Earnie> Sigh.  How long have you been on this list?  I'll now suggest that you refer to
  Earnie> the documentation, FAQ and mail archives for which you can find URL pointers at
  Earnie> http://cygwin.com .

Ok, after reading the user's guide, I did the following on the new
system:

   mount -t d: /d

After this, the output of "mount" is the following:

    Device              Directory           Type         Flags
    d:\cygwin\bin       /usr/bin            system       binmode
    d:\cygwin\lib       /usr/lib            system       binmode
    d:\cygwin           /                   system       binmode
    d:                  /d                  user         textmode

I now find that my original .bash* files work fine, even with ^Ms.

Is this the correct solution for this?  All of the files I create will
be stored on the D: partition, but I guess any files that I read from
directories which map to the three "binmode" mounts will be
interpreted differently.  I don't know how much of an issue that is.

The mount table from the original installation just has the first
three, with the only difference being the "Type" is "user" instead of
"system".  From my reading of the UG, that shouldn't matter.

I guess this means that the default mode for unmapped directories is
"text" on my original installation, and "binary" for the second
installation.  Since directories like "d:/dmk" (my home directory) are
not covered by the original mount table, I would get the default.

So, when I install it again, if I select the "DOS" text file type, I
won't have to add this mount to get files on the "D:/" drive to use
DOS text file mode, correct?

What exactly in the "cygcheck" output (or any other place, for that
matter) tells me what the default text file type is?

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Larry Hall (RFK Partners, Inc)]

At 03:15 PM 12/21/2000, David M. Karr wrote:
> >>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>   Earnie> --- "David M. Karr" <dkarr@tcsi.com> wrote:
>   >> 
>   >> I don't understand the option of setting text mode mount points.  I
>   >> have no idea what the ramifications of that would be.
>
>   Earnie> Sigh.  How long have you been on this list?  I'll now suggest that you refer to
>   Earnie> the documentation, FAQ and mail archives for which you can find URL pointers at
>   Earnie> http://cygwin.com .
>
>Ok, after reading the user's guide, I did the following on the new
>system:
>
>    mount -t d: /d
>
>After this, the output of "mount" is the following:
>
>     Device              Directory           Type         Flags
>     d:\cygwin\bin       /usr/bin            system       binmode
>     d:\cygwin\lib       /usr/lib            system       binmode
>     d:\cygwin           /                   system       binmode
>     d:                  /d                  user         textmode
>
>I now find that my original .bash* files work fine, even with ^Ms.


Right.


>Is this the correct solution for this?  All of the files I create will
>be stored on the D: partition, but I guess any files that I read from
>directories which map to the three "binmode" mounts will be
>interpreted differently.  I don't know how much of an issue that is.


If you had selected "DOS" originally in setup, all these mounts would have
been set to text.  If that's what you wanted, set them that way now and 
you don't need your added entry.  Otherwise, mount all the other drives you
want to act "DOS" drives with the "text" setting.


>The mount table from the original installation just has the first
>three, with the only difference being the "Type" is "user" instead of
>"system".  From my reading of the UG, that shouldn't matter.


If you want your settings to affect only you, that's correct.


>I guess this means that the default mode for unmapped directories is
>"text" on my original installation, and "binary" for the second
>installation.  Since directories like "d:/dmk" (my home directory) are
>not covered by the original mount table, I would get the default.


You should be able to reset your default mode for unmapped drives using
the --change-cygdrive-prefix setting for mount but specify the "-t" flag
too.  I haven't tried this myself so I don't know if it actually works.


>So, when I install it again, if I select the "DOS" text file type, I
>won't have to add this mount to get files on the "D:/" drive to use
>DOS text file mode, correct?


Right.


>What exactly in the "cygcheck" output (or any other place, for that
>matter) tells me what the default text file type is?


Nothing.  cygcheck doesn't output that yet.

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Earnie Boyd]

--- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
> 
> >I guess this means that the default mode for unmapped directories is
> >"text" on my original installation, and "binary" for the second
> >installation.  Since directories like "d:/dmk" (my home directory) are
> >not covered by the original mount table, I would get the default.
> 
> 
> You should be able to reset your default mode for unmapped drives using
> the --change-cygdrive-prefix setting for mount but specify the "-t" flag
> too.  I haven't tried this myself so I don't know if it actually works.
> 

If you chose the "Everyone" radio button, add a -s to that.

> 
> >So, when I install it again, if I select the "DOS" text file type, I
> >won't have to add this mount to get files on the "D:/" drive to use
> >DOS text file mode, correct?
> 
> 
> Right.
> 
> 
> >What exactly in the "cygcheck" output (or any other place, for that
> >matter) tells me what the default text file type is?
> 
> 
> Nothing.  cygcheck doesn't output that yet.
> 

That's not true.  The output of the registry data can tell you.  0x00000020 is
text mode 0x00000022 is binary mode.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  Earnie> --- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
  >> 
  >> >I guess this means that the default mode for unmapped directories is
  >> >"text" on my original installation, and "binary" for the second
  >> >installation.  Since directories like "d:/dmk" (my home directory) are
  >> >not covered by the original mount table, I would get the default.
  >> 
  >> You should be able to reset your default mode for unmapped drives using
  >> the --change-cygdrive-prefix setting for mount but specify the "-t" flag
  >> too.  I haven't tried this myself so I don't know if it actually works.

  Earnie> If you chose the "Everyone" radio button, add a -s to that.

  >> >So, when I install it again, if I select the "DOS" text file type, I
  >> >won't have to add this mount to get files on the "D:/" drive to use
  >> >DOS text file mode, correct?
  >> 
  >> Right.
  >> 
  >> >What exactly in the "cygcheck" output (or any other place, for that
  >> >matter) tells me what the default text file type is?
  >> 
  >> Nothing.  cygcheck doesn't output that yet.

  Earnie> That's not true.  The output of the registry data can tell you.  0x00000020 is
  Earnie> text mode 0x00000022 is binary mode.

Sorry for needing to rehash this, but could someone tell me EXACTLY
what I need to execute to permanently change the default text file
type to DOS?  I've tried numerous variations of what's described here,
and I can't get it to work on a third installation of this (where the
user neglected to select "DOS" on the initial install).

I've tried the following:

mount -ts --change-cygdrive-prefix /cygdrive
mount -ts --change-cygdrive-prefix /d
mount -t --change-cygdrive-prefix /d

These all just echo the usage message.

After the following:

      mount -t d: /d

I get "mount: warning - /d does not exist".  Doing "mount" after this
shows a new mount entry in textmode, but running "ksh" still gets the
usual error.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Larry Hall (RFK Partners, Inc)]

At 12:53 PM 1/3/2001, David M. Karr wrote:
> >>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>   Earnie> --- "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com> wrote:
>   >> 
>   >> >I guess this means that the default mode for unmapped directories is
>   >> >"text" on my original installation, and "binary" for the second
>   >> >installation.  Since directories like "d:/dmk" (my home directory) are
>   >> >not covered by the original mount table, I would get the default.
>   >> 
>   >> You should be able to reset your default mode for unmapped drives using
>   >> the --change-cygdrive-prefix setting for mount but specify the "-t" flag
>   >> too.  I haven't tried this myself so I don't know if it actually works.
>
>   Earnie> If you chose the "Everyone" radio button, add a -s to that.
>
>   >> >So, when I install it again, if I select the "DOS" text file type, I
>   >> >won't have to add this mount to get files on the "D:/" drive to use
>   >> >DOS text file mode, correct?
>   >> 
>   >> Right.
>   >> 
>   >> >What exactly in the "cygcheck" output (or any other place, for that
>   >> >matter) tells me what the default text file type is?
>   >> 
>   >> Nothing.  cygcheck doesn't output that yet.
>
>   Earnie> That's not true.  The output of the registry data can tell you.  0x00000020 is
>   Earnie> text mode 0x00000022 is binary mode.
>
>Sorry for needing to rehash this, but could someone tell me EXACTLY
>what I need to execute to permanently change the default text file
>type to DOS?  I've tried numerous variations of what's described here,
>and I can't get it to work on a third installation of this (where the
>user neglected to select "DOS" on the initial install).
>
>I've tried the following:
>
>mount -ts --change-cygdrive-prefix /cygdrive
>mount -ts --change-cygdrive-prefix /d
>mount -t --change-cygdrive-prefix /d
>
>These all just echo the usage message.


AFAICT, mount doesn't accept combined flag options, at least for 
--change-cygdrive-prefix.  Use -t -s.  Also its best to make sure that
you invoke the --change-cygdrive-prefix option without the -s flag, since
you may have set the option for your personal login to something other 
than text in your attempts.  Do the following:

mount -t -s --change-cygdrive-prefix /cygdrive
mount -t --change-cygdrive-prefix /cygdrive

That should do it.  BTW, I don't recommend using a path like "/d" for your
cygdrive path.  Since many people tend to mount their D: drive to /d, this
may become confusing for you.  Whatever suits you is fine, providing you 
understand what you're doing.


>After the following:
>
>       mount -t d: /d
>
>I get "mount: warning - /d does not exist".  Doing "mount" after this
>shows a new mount entry in textmode, but running "ksh" still gets the
>usual error.


As you said, you got the warning.  Mount really wants the POSIX path you 
mount to exist, but it doesn't force it to.  Type "mkdir /d" before the 
mount to remove this warning.


>-- 
>===================================================================
>David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
>dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Earnie Boyd]

--- Chris Abbey <cabbey@bresnanlink.net> wrote:
> As Earnie suggested, comparing the outputs, with attention to the mount
> point information will show that /cygdrive/? is mounted differently between
> the two machines, popcorn (I'll guess is the working one) mount with the
> flags as 0x0020 while nachos (I'll guess doesn't work) mounts with 0x0022.
> I'll venture a guess that you're accessing the scripts from /cygdrive/?/...
> right? (because the other mounts are the same for both.
> 

Yep, that be it.  The HOME directory is /cygdrive/d/dmk on both.

> a solution, as Christopher suggested, is to remove the ^M from the files.
> the easiest way I know of to do this is to pipe the script through "tr -d
> '\r'"
> so for example:
> 
> tr -d '\r' < /cygdrive/c/myscript > /tmp/myscript
> mv -f /tmp/myscript /cygdrive/c/myscript
> 
> the other would be to mount the location of the script in an explictly
> controlled mount point (text mode), or to change the default mount
> mode.
> 

And the other would be to rerun setup and choose the DOS radio button.  Just
rerun setup, no need to redownload anything.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  >> a solution, as Christopher suggested, is to remove the ^M from the files.
  >> the easiest way I know of to do this is to pipe the script through "tr -d
  >> '\r'"
  >> so for example:
  >> 
  >> tr -d '\r' < /cygdrive/c/myscript > /tmp/myscript
  >> mv -f /tmp/myscript /cygdrive/c/myscript
  >> 
  >> the other would be to mount the location of the script in an explictly
  >> controlled mount point (text mode), or to change the default mount
  >> mode.

  Earnie> And the other would be to rerun setup and choose the DOS radio button.  Just
  Earnie> rerun setup, no need to redownload anything.

As I still have to work with other applications (Emacs, etc.) which
will continue to write files with DOS line endings, removing the ^Ms
is not a practical option, as I'd have to do that constantly.

I understand the option of rerunning setup and setting the DOS radio
button, but I actually already tried that.  After going through a few
dialogs, it said "Nothing to update" (or something like that), and it
seemed like it had no effect.  However, based on my limited
understanding of this, I think this would probably be the best option
(if I can get it to work).

I don't understand the option of setting text mode mount points.  I
have no idea what the ramifications of that would be.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Markus Hoenicka]

David M. Karr writes:
 > As I still have to work with other applications (Emacs, etc.) which
 > will continue to write files with DOS line endings, removing the ^Ms
 > is not a practical option, as I'd have to do that constantly.

If Emacs is your major concern, stick the following into your .emacs:

(setq-default buffer-file-coding-system 'undecided-unix)

New files will then be unix-style. Works great here.

regards,
Markus

-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
Markus.Hoenicka@uth.tmc.edu
http://ourworld.compuserve.com/homepages/hoenicka_markus/


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Markus" == Markus Hoenicka <Markus.Hoenicka@uth.tmc.edu> writes:
  Markus> David M. Karr writes:
  >> As I still have to work with other applications (Emacs, etc.) which
  >> will continue to write files with DOS line endings, removing the ^Ms
  >> is not a practical option, as I'd have to do that constantly.

  Markus> If Emacs is your major concern, stick the following into your .emacs:

  Markus> (setq-default buffer-file-coding-system 'undecided-unix)

  Markus> New files will then be unix-style. Works great here.

Emacs is a major concern, but not my only one.  I don't think it's
practical to try to fix every Windows program to produce Unix line
endings.  I have to focus on getting Cygwin to work with DOS line
endings.

My original installation works fine.  When I ran the second
installation, I think I probably left the "Unix" flag on.  Is it
conceivable that I'll have to uninstall completely so I can reinstall
with the "DOS" flag set?  Rerunning it and setting that flag had no
effect.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Larry Hall (RFK Partners, Inc)]

At 11:46 AM 12/21/2000, David M. Karr wrote:
> >>>>> "Markus" == Markus Hoenicka <Markus.Hoenicka@uth.tmc.edu> writes:
>   Markus> David M. Karr writes:
>   >> As I still have to work with other applications (Emacs, etc.) which
>   >> will continue to write files with DOS line endings, removing the ^Ms
>   >> is not a practical option, as I'd have to do that constantly.
>
>   Markus> If Emacs is your major concern, stick the following into your .emacs:
>
>   Markus> (setq-default buffer-file-coding-system 'undecided-unix)
>
>   Markus> New files will then be unix-style. Works great here.
>
>Emacs is a major concern, but not my only one.  I don't think it's
>practical to try to fix every Windows program to produce Unix line
>endings.  I have to focus on getting Cygwin to work with DOS line
>endings.
>
>My original installation works fine.  When I ran the second
>installation, I think I probably left the "Unix" flag on.  Is it
>conceivable that I'll have to uninstall completely so I can reinstall
>with the "DOS" flag set?  Rerunning it and setting that flag had no
>effect.


David, you should find the background to answer your question in the 
Cygwin User's Guide in the sections discussing mounts and the binary/text
issue.  Setting the "DOS" flag in the installation only indicates whether
mount uses the "-b" (binary) flag or not by default.  This applies to all
mounts setup makes as well as the /cgydrive notation.  There's no other
"magic" going on here.

Good luck,




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Jari Aalto+mail.emacs]

* Thu 2000-12-21 Markus Hoenicka <Markus.Hoenicka@uth.tmc.edu> list.cygwin
* Message-Id: < 14914.6314.575000.452009@gargle.gargle.HOWL >
| David M. Karr writes:
|
|  > As I still have to work with other applications (Emacs, etc.) which
|  > will continue to write files with DOS line endings, removing the ^Ms
|  > is not a practical option, as I'd have to do that constantly.
|
| If Emacs is your major concern, stick the following into your .emacs:
|
| (setq-default buffer-file-coding-system 'undecided-unix)
|
| New files will then be unix-style. Works great here.

But that Idiot CVS pulls the ^M back from he CVS server if you
run it in DOS. (under NT Emacs)

I would appreciate if bash could tolerate ^M in the end of lines.

Jari


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Corinna Vinschen]

On Friday 22 December 2000 01:11, Jari Aalto+mail.emacs wrote:
> I would appreciate if bash could tolerate ^M in the end of lines.

It does.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Christopher Faylor]

On Fri, Dec 22, 2000 at 01:22:27AM +0100, Corinna Vinschen wrote:
>On Friday 22 December 2000 01:11, Jari Aalto+mail.emacs wrote:
>> I would appreciate if bash could tolerate ^M in the end of lines.
>
>It does.
>
>Corinna

LOL.  I responded almost exactly the same way before I read your email.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Christopher Faylor]

On Fri, Dec 22, 2000 at 02:11:38AM +0200, Jari Aalto+mail.emacs wrote:
>* Thu 2000-12-21 Markus Hoenicka <Markus.Hoenicka@uth.tmc.edu> list.cygwin
>* Message-Id: < 14914.6314.575000.452009@gargle.gargle.HOWL >
>| David M. Karr writes:
>|
>|  > As I still have to work with other applications (Emacs, etc.) which
>|  > will continue to write files with DOS line endings, removing the ^Ms
>|  > is not a practical option, as I'd have to do that constantly.
>|
>| If Emacs is your major concern, stick the following into your .emacs:
>|
>| (setq-default buffer-file-coding-system 'undecided-unix)
>|
>| New files will then be unix-style. Works great here.
>
>But that Idiot CVS pulls the ^M back from he CVS server if you
>run it in DOS. (under NT Emacs)
>
>I would appreciate if bash could tolerate ^M in the end of lines.

It can.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Markus Hoenicka]

I don't use CVS here. Is there a specific reason why do you run it in
DOS under NT Emacs?  Bash and ash run just fine as interactive and
non-interactive shells in NT Emacs.

Markus

Jari Aalto+mail.emacs writes:
 > But that Idiot CVS pulls the ^M back from he CVS server if you
 > run it in DOS. (under NT Emacs)
 > 
 > I would appreciate if bash could tolerate ^M in the end of lines.
 > 
 > Jari
 > 
 > 
 > --
 > Want to unsubscribe from this list?
 > Check out: http://cygwin.com/ml/#unsubscribe-simple
 > 

-- 
Markus Hoenicka, PhD
UT Houston Medical School
Dept. of Integrative Biology and Pharmacology
6431 Fannin MSB4.114
Houston, TX 77030
(713) 500-6313, -7477
(713) 500-7444 (fax)
Markus.Hoenicka@uth.tmc.edu
http://ourworld.compuserve.com/homepages/hoenicka_markus/


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Jari Aalto+mail.linux]

* Fri 2000-12-22 Markus Hoenicka <Markus.Hoenicka@uth.tmc.edu> list.cygwin
* Message-Id: < 14915.26523.510000.202002@gargle.gargle.HOWL >
| I don't use CVS here. Is there a specific reason why do you run it in
| DOS under NT Emacs?  Bash and ash run just fine as interactive and
| non-interactive shells in NT Emacs.

I run both: DOS and BASH shells and sometimes I forgot.

And pcl-cvs.el, runs Emacs call-process, which I think is native 98
kernel, and CVS yanks the ^M to the perfect unix-files that I store in
Linux end.

I hate it :-) I want always plain \n, no matter what platform 
I use CVS on.

I have to push the CVS developers more to really understand that 
"automatic" and non-user-controllable end-of-line conversions
are bad.

Maybe they hear if I request it long enough, or find the time
to offer them a patch...time to go clone myself to get more
job done.

Jari


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

QT

[chris]

Hi;

Just a quick query - has anyone had any luck compiling QT 1.x with
CygWin? I'm assured it's possible (I'm trying to build 1.45, I think) but
the moc meta-object parser thing keeps breaking it - bison won't parse the
.y file at all, and byacc seems to generate broken code.

The source itself claims it won't compile with gnu bison, but I know
someone who claims to have got it to compile...

Anybody got any ideas?
Chris
-- 
Chris Whitworth   |   "I'm not ashamed of the Gospel" -- Deliriou5?
chris@parm.net    |              http://www.parm.net/


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: QT

[Dr. Volker Zell]

>>>>> "chris" == chris  <chris@parm.net> writes:

    chris> Hi;
    chris> Just a quick query - has anyone had any luck compiling QT 1.x with
    chris> CygWin? I'm assured it's possible (I'm trying to build 1.45, I think) but
    chris> the moc meta-object parser thing keeps breaking it - bison won't parse the
    chris> .y file at all, and byacc seems to generate broken code.

I just compiled

 o qt-x11-2.2.4 - http://www.trolltech.com/

I copied

 /usr/local/qt/configs/linux-g++-static to /usr/local/qt/configs/cygwin-g++-static

and added platform support in /usr/local/qt/configure

     CYGWIN_NT-4.0:*)
	PLATFORM=cygwin-g++
	;;

In /usr/local/qt/src/kernel/qapplication_x11.cpp I added

#if defined(_OS_CYGWIN_)
#  include <sys/socket.h> // for FIONREAD on Cygwin
#endif

In /usr/local/qt/src/network
the file qdns.cpp needed the header files from bind to compile.

And for the examples (ftpclient, httpd, mail and networkprotocol) I added
 -L/usr/local/bind/lib -lbind 
in the appropriate Makefile.

All examples and tutorials are working

Ciao
  Volker


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: QT

[Jonathan Fosburgh]

At 12:46 AM 2/12/01 +0100, Dr. Volker Zell wrote:


>In /usr/local/qt/src/network
>the file qdns.cpp needed the header files from bind to compile.
>
>And for the examples (ftpclient, httpd, mail and networkprotocol) I added
>  -L/usr/local/bind/lib -lbind
>in the appropriate Makefile.
>

I've been waiting to see this for awhile. :) Question, did you install bind 
or just the headers? I am assuming you did install it, so what version did 
you use and how did you get it to build? So far, I am not finding anything 
on the website. Thanks.


Jonathan Fosburgh
Open Systems
Communications and Computer Services
UT MD Anderson Cancer Center


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: QT

[Dr. Volker Zell]

>>>>> "Jonathan" == Jonathan Fosburgh <syjef@mail.mdanderson.org> writes:

    Jonathan> At 12:46 AM 2/12/01 +0100, Dr. Volker Zell wrote:
    >> In /usr/local/qt/src/network
    >> the file qdns.cpp needed the header files from bind to compile.
    >> 
    >> And for the examples (ftpclient, httpd, mail and networkprotocol) I added
    >> -L/usr/local/bind/lib -lbind
    >> in the appropriate Makefile.
    >> 

    Jonathan> I've been waiting to see this for awhile. :) Question, did you install
    Jonathan> bind or just the headers? I am assuming you did install it, so what
    Jonathan> version did you use and how did you get it to build? So far, I am not
    Jonathan> finding anything on the website. Thanks.

 o bind-8.2.2p7 - ftp://ftp.isc.org/isc/bind/src/8.2.2-P7/

with a patch from Stephen C.Biggs ( http://sources.redhat.com/ml/cygwin/2000-12/msg00930.html )

 o ftp://ftp.franken.de/pub/win32/develop/gnuwin32/incoming

    Jonathan> Jonathan Fosburgh

Ciao
  Volker


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: QT - request for bind cygwin patch file

[Kevin Wright]

Hello,

I've been trying unsuccessfully to get Stephen Biggs bind patch since 
I saw this email. Since the files are in the incoming directory they
are forbidden to download. I sent Michael Hirmke a request to move
them to a porters directory but he's waiting for a proper readme file
from Stephen.

I've tried getting the patch directly from Stephen but apparently 
he's swamped at the moment. 

Is there anyone else out there you can forward it to the list. I just
want the patch file not the binaries.  

Thanks,

--Kevin


> -----Original Message-----
> From: cygwin-owner@sources.redhat.com
> [ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Dr. Volker Zell
> Sent: Monday, February 12, 2001 10:40 AM
> To: Jonathan Fosburgh
> Cc: chris@parm.net; cygwin@sources.redhat.com
> Subject: Re: QT
> 
> 
> >>>>> "Jonathan" == Jonathan Fosburgh <syjef@mail.mdanderson.org> writes:
> 
>     Jonathan> At 12:46 AM 2/12/01 +0100, Dr. Volker Zell wrote:
>     >> In /usr/local/qt/src/network
>     >> the file qdns.cpp needed the header files from bind to compile.
>     >> 
>     >> And for the examples (ftpclient, httpd, mail and 
> networkprotocol) I added
>     >> -L/usr/local/bind/lib -lbind
>     >> in the appropriate Makefile.
>     >> 
> 
>     Jonathan> I've been waiting to see this for awhile. :) 
> Question, did you install
>     Jonathan> bind or just the headers? I am assuming you did 
> install it, so what
>     Jonathan> version did you use and how did you get it to 
> build? So far, I am not
>     Jonathan> finding anything on the website. Thanks.
> 
>  o bind-8.2.2p7 - ftp://ftp.isc.org/isc/bind/src/8.2.2-P7/
> 
> with a patch from Stephen C.Biggs 
> ( http://sources.redhat.com/ml/cygwin/2000-12/msg00930.html )
> 
>  o ftp://ftp.franken.de/pub/win32/develop/gnuwin32/incoming
> 
>     Jonathan> Jonathan Fosburgh
> 
> Ciao
>   Volker
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Understanding program startup

[Jim Balter]

DG Ellis wrote:
> 
>   I am not new to C programming, however, I am new to writing programs
> that run under a unix shell like bash.  For history, I found that single
> quotes are not respected by applications that use cygwin.dll when the
> program is invoked from outside bash.

That bug has been discussed here.

> I chased down the code to the
> winsup/dcrt0.cc source file and was busy modifying it when I decided to
> check on the behavior of "normal" command lines under bash and under NT.
> Well, I see where the code should behave certain ways and does when run
> under NT command processor, but does not behave at all the same when
> under bash.

bash does its own command line processing, so doing it in dcrt0
for programs run under bash would just mess things up.

> Now here is my question:
> My suspicion is that the routine dll_crt0_1 is not called if the
> program is run under the shell. Is this correct?

No, not at all.  Note the code in dll_crt0_1:

  if (! u->self->cygwin_parent_p)
    globify (&argc, &argv);

That does wildcard expansion if cygwin_parent_p isn't set.
cygwin_parent_p is set in pinfo_init (which is called a bit earlier
in dll_crt0_1) if the PID environment variable is set and matches
the corresponding process table (pinfo) entry.  That will be the
case if this process was execed by a cygwin process, such as bash.
There are of course other messy and confusing details.

> I will try to check on
> libc's crt0 to see if this is true (if I can find the source).

cygwin_crt0 in winsup/libccrt0.c, which is linked into the application
code, calls the dll_crt0 in dcrt0.cc in cygwin.dll.

> It looks
> like there are a lot of important things in the dll_crt0_1 routine that
> should be done in each case. If they don't get done, what happens?

Nothing useful, since dll_crt0_1 calls main, among its other important
functions.

> Could this be the ctrl-C crash problem???

Nope, sorry.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: Linking with .LIB files

[David W Palmer]

Text item: 


     For those who are watching: Colin Peter's text is left justified, mine is 
     indented.


David W Palmer[SMTP:David_W_Palmer@ccm.jf.intel.com] wrote:
>     So, I have a simple program which uses OpenGL and I link with the 
>     following:
>
>     link simple.o libuser32.a glu32.lib opengl32.lib libgdi32.a 
>     /subsystem:windows /machine:i386
     
Although this may be secondary to your concerns, or in fact may be 
totally off topic, I notice that libglu32.a and libopengl32.a are 
both included with the beta 17.1 distribution. I'm not sure about 
the header files, but if you can get your code to compile you should 
be able to link it with ld. Of course this doesn't help if what you 
really want is DirectX or some other thing that comes with .lib 
files you can't convert to .a files.
     
     Actually, that is interesting.  From the distribution I downloaded, 
     libglu32.a and libopengl32.a are not available.  However, I am 
     interested in the general problem of linking with MS lib's (ie, 
     glaux.lib).
     
     I suspect that I could use dlltool to generate an import library for 
     glu32.dll and opengl32.dll.  I'll give it a try.
     
     
>      LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup 
>      simple.exe : fatal error LNK1120: 1 unresolved externals
>      make: *** [simple.exe] Error 25 
>
>     No .EXE is generated.  And the answer is... what?
     
This suggests to me that you need to include crt0.o in your link line 
explicitly, since that's where _WinMainCRTStartup should be resolved. 
Well, actually in the Cygnus sources it's not, but you could just add 
a _WinMainCRTStartup entry point which calls the _mainCRTStartup 
entry point and it should work OK I think.
     
     Yes, I thought of that too.
     
     //f/pgming/OpenGL/simple$ make
     link simple.o crt0.o libuser32.a glu32.lib opengl32.lib libgdi32.a 
     /subsystem:windows /machine:i386
     Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
     Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
     
     crt0.o : error LNK2001: unresolved external symbol _cygwin_crt0
     LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
     simple.exe : fatal error LNK1120: 2 unresolved externals
     make: *** [simple.exe] Error 25
     //f/pgming/OpenGL/simple$
     
     
     So, I can trade WinMainCRTStartup() for cygwin_crt0().  Not much 
     progress.  Though, this has to be defined somewhere!  Which library?  
     Unfortunately, I don't know how to list the functions in a library. 
     (how embarrassing) :+(
     
     BTW: instead of defining WinMainCRTStartup(), it's easier to use the 
     link option /ENTRY:mainCRTStartup.


Sorry for the rampant uncertainty,

     Hay, at least it's better than calling me crazy for not using MSVC.  
     Actually, I am using VC++ 5.0 but I'd rather not.
     
     Dave

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Date: Wed, 26 Mar 1997 13:48:48 +0900
Subject: RE: Linking with .LIB files
Cc: "'GNU-Win32'" <gnu-win32@cygnus.com>
To: "'David W Palmer'" <David_W_Palmer@ccm.jf.intel.com>
From: Colin Peters <colin@bird.fu.is.saga-u.ac.jp>
Message-ID: < 01BC39EC.6F6FE340@gbird0 >
Received: by gbird0 with Microsoft Mail
     id < 01BC39EC.6F6FE340@gbird0 >; Wed, 26 Mar 1997 13:48:50 +0900
Received: from gbird0 ([133.49.23.250]) by bird.fu.is.saga-u.ac.jp (8.8.2/3.3W7-
bird) with SMTP id NAA19950; Wed, 26 Mar 1997 13:49:13 +0900 (JST)
Received: from bird.fu.is.saga-u.ac.jp (bird.fu.is.saga-u.ac.jp [133.49.23.129])

          by ormail.intel.com (8.8.4/8.8.4) with ESMTP
       id UAA05410 for <David_W_Palmer@ccm.jf.intel.com>; Tue, 25 Mar 1997 20:51
:50 -0800 (PST)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.6/8.7.3) with ESMTP id UAA04374 for <David_W_Palmer@ccm.jf.intel.c
om>; Tue, 25 Mar 1997 20:52:03 -0800 (PST)
Return-Path: colin@bird.fu.is.saga-u.ac.jp
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Linking with .LIB files

[David W Palmer]

     
     Yes, I know this has been covered before.  Unfortunately, I can't find 
     the necessary information to get this to work other than to use 
     link.exe and it might work.
     
     So, I have a simple program which uses OpenGL and I link with the 
     following:
     
     link simple.o libuser32.a glu32.lib opengl32.lib libgdi32.a 
     /subsystem:windows /machine:i386
     
     And of course, I get the following:
     
      Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
      Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
      
      LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
      simple.exe : fatal error LNK1120: 1 unresolved externals
      make: *** [simple.exe] Error 25
     
     No .EXE is generated.  And the answer is... what?
     
     Dave
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linking with .LIB files

[Nick Ing-Simmons]

David W Palmer <David_W_Palmer@ccm.jf.intel.com> writes:
>     
>     link simple.o libuser32.a glu32.lib opengl32.lib libgdi32.a 
>     /subsystem:windows /machine:i386
>     
>     And of course, I get the following:
>     
>      Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
>      Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
>      
>      LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
>      simple.exe : fatal error LNK1120: 1 unresolved externals
>      make: *** [simple.exe] Error 25
>     
>     No .EXE is generated.  And the answer is... what?


      link /entry:whatever_it_is_forGNU 


-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linking with .LIB files

[Jim Balter]

David W Palmer wrote:
> 
> Text item:
> 
>      For those who are watching: Colin Peter's text is left justified, mine is
>      indented.
> 
> David W Palmer[SMTP:David_W_Palmer@ccm.jf.intel.com] wrote:
> >     So, I have a simple program which uses OpenGL and I link with the
> >     following:
> >
> >     link simple.o libuser32.a glu32.lib opengl32.lib libgdi32.a
> >     /subsystem:windows /machine:i386

> >      LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
> >      simple.exe : fatal error LNK1120: 1 unresolved externals
> >      make: *** [simple.exe] Error 25
> >
> >     No .EXE is generated.  And the answer is... what?

Just what sort of thing is simple.o?  If it is a POSIXish
thing that has a main() and uses the POSIXish stuff provided by
cygwin.dll then you need crt0.o and libcygwin.a and possibly others, and
tell the linker that the entry point is _mainCRTStartup.  If it's a
win32ish thing then you should be providing your own _WinMainCRTStartup
or tell the linker just what *is* your entry point.

> This suggests to me that you need to include crt0.o in your link line
> explicitly, since that's where _WinMainCRTStartup should be resolved.
> Well, actually in the Cygnus sources it's not, but you could just add
> a _WinMainCRTStartup entry point which calls the _mainCRTStartup
> entry point and it should work OK I think.
> 
>      Yes, I thought of that too.
> 
>      //f/pgming/OpenGL/simple$ make
>      link simple.o crt0.o libuser32.a glu32.lib opengl32.lib libgdi32.a

You still haven't told the linker what the entry point is or
provided a _WinMainCRTStartup; read Colin's comments above again.

>      /subsystem:windows /machine:i386
>      Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
>      Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
> 
>      crt0.o : error LNK2001: unresolved external symbol _cygwin_crt0
>      LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
>      simple.exe : fatal error LNK1120: 2 unresolved externals
>      make: *** [simple.exe] Error 25
>      //f/pgming/OpenGL/simple$
> 
> 
>      So, I can trade WinMainCRTStartup() for cygwin_crt0().

No, now you are missing both.

>      Not much
>      progress.  Though, this has to be defined somewhere!  Which library?

libcygwin.a.  cygwin_crt0 calls dll_crt0 in cygwin.dll.

>      Unfortunately, I don't know how to list the functions in a library.

nm for *.a

>      BTW: instead of defining WinMainCRTStartup(), it's easier to use the
>      link option /ENTRY:mainCRTStartup.

But you didn't.  You need to tell the linker your entry point or provide
a _WinMainCRTStartup.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: Linking with .LIB files

[David W Palmer]

Text item: 


     Okay, the 'ol linking problem.
     
     I tried declaring the following in simple.c:

void (*__CTOR_LIST__)(void) = 0;
void (*__DTOR_LIST__)(void) = 0;
char _data_start__, _data_end__, _bss_start__, _bss_end__;

     It compiled!  But would exit immediately when ran.
     
     "gdb simple.exe" faulted, dumped the stack, and exited before running the 
     program.  (ouch!)
     
     So, I tried the next suggestion: since the sample doesn't use any cygwin 
     functions, use MS libraries instead.  This worked to the extent of linking. 
      Simple.exe again exits immediately after running.
     
     "gdb simple.exe" shows that it runs, but gets a 0 from CreateWindow().  So, 
     I compared this behavior against what cl.exe does.  Here's as far as I've 
     gotten:
     
     case 1: compile using
         gcc -c simple.c -o simple.o -DWIN32 -D_DEBUG -D_WINDOWS
     
     case 2: compile using
         cl   /D "WIN32" /D "_DEBUG" /D "_WINDOWS"    /c simple.c
         mv simple.obj simple.o

     In both cases, link using:
        link /NOD simple.o libc.lib kernel32.lib user32.lib gdi32.lib
     winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
     uuid.lib odbc32.lib odbccp32.lib opengl32.lib glu32.lib /nologo 
     /subsystem:windows /debug /machine:I386 /out:"Simple.exe"
     
     I removed the "\"s for formatting reasons in this e-mail.  And yes, I know 
     I don't need the majority of those .lib's - I just grabbed it from a 
     working simple.mak generated by VC 5.0.
     
     Both methods generate a simple.exe that will run.  However, case 2 
     successfully creates a window and the program runs fine.  Case 1 gets a 0 
     return code from CreateWindow().  (sigh)
     
     BTW, the GNU-Win32 FAQ at 
       http://www.cygnus.com/misc/gnu-win32/faq.html#SEC57
     
     says:
     -----
     Can I mix objects compiled with msvc++ and gcc?
     
     Yes, this supposedly works. The key seems to be using MS's LINK.EXE to do 
     the linking instead of GNU ld. There may be issues with constructor calls 
     for C++/Obj C.
     -----
     I see no evidence that could possibly support this claim.  Though I have 
     not tried all possible combinations, I'm inclined to believe that gcc and 
     link are incompatible as suggested by Wiljan.  If this is not the case, I'd 
     appreciate seeing a sample that works.  Regardless, the FAQ should be 
     updated.
     
     Dave

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <Thu, 27 Mar 97 12:33:08 PST_2@ccm.jf.intel.com>
Subject: Re: Linking with .LIB files
CC: gnu-win32@cygnus.com, colin@bird.fu.is.saga-u.ac.jp
To: David W Palmer <David_W_Palmer@ccm.jf.intel.com>
MIME-Version: 1.0
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Organization: JQB Enterprises
From: Jim Balter <jqb@netcom.com>
Date: Thu, 27 Mar 1997 13:20:09 -0800
Message-ID: < 333AE489.3ED1@netcom.com >
Received: from sba-ca1-24.ix.netcom.com(204.32.201.56) by dfw-ix10.ix.netcom.com
 via smap (V1.3)
     id sma006293; Thu Mar 27 15:23:33 1997
Received: (from smap@localhost)
          by dfw-ix10.ix.netcom.com (8.8.4/8.8.4)
       id PAA06304; Thu, 27 Mar 1997 15:23:58 -0600 (CST)
Received: from dfw-ix10.ix.netcom.com (dfw-ix10.ix.netcom.com [206.214.98.10]) b
y mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id NAA20601 for <David_W_Palmer@
ccm.jf.intel.com>; Thu, 27 Mar 1997 13:32:57 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id NAA24313 for <David_W_Palmer@ccm.jf
.intel.com>; Thu, 27 Mar 1997 13:30:39 -0800 (PST)
Return-Path: jqb@netcom.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Linking with .LIB files

[Jim Balter]

David W Palmer wrote:
> 
> Text item:
> 
> 
>      Okay, I've pulled together the feedback and made a few more attempts.
> 
>      I compile the program using:
>         gcc -o simple.c
> 
>      and link using:
> 
>      link simple.o libc.a libcygwin.a libkernel32.a libuser32.a glu32.lib
>      opengl32.lib libgdi32.a /subsystem:windows /machine:i386
>      /entry:mainCRTStartup
> 
>      The output:
> 
> //f/pgming/opengl/simple$ make
> link simple.o libc.a libcygwin.a libkernel32.a libuser32.a glu32.lib opengl32.li
> b libgdi32.a /subsystem:windows /machine:i386 /entry:mainCRTStartup
> Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
> Copyright (C) Microsoft Corp 1992-1997. All rights reserved.
> 
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol ___CTOR_LIST
> __
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol ___DTOR_LIST
> __
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __data_start
> __
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __data_end__
> 
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __bss_start_
> _
> libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __bss_end__
> simple.exe : fatal error LNK1120: 6 unresolved externals
> make: *** [simple.exe] Error 25
> //f/pgming/opengl/simple$
> 
>      I greped the contents of every .a I could find and there's no trace of a
>      __data_start__ tag anywhere.  I grep them by doing the following:

I believe (but have not verified) that ld generates these.
So, if link doesn't produce some equivalent that can be
massaged/converted
into what cygwin.dll is expecting (libccrt0.o just stashes them for use
later
by cygwin.dll) you may be out of luck.  However, the _start_ and _end_
symbols
are only used by fork, which you probably aren't using, and the LISTs
are C++
ConstrucTOR and DesstrucTOR lists, which you probably also don't need. 
So, try
just defining all these to null in the link command line or script file,
or
define them in simple.c, and see how that goes.  You need to strip one
'_' if
you define them in a .c file on a x86 box (but not on a PowerPC box).
i.e., add

void (*__CTOR_LIST__)(void) = 0;
void (*__CTOR_LIST__)(void) = 0;
char _data_start__, _data_end__, _bss_start__, _bss_end__;

to simple.c and fire 'er up.

--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: Linking with .LIB files

[David W Palmer]

Text item: 

     
     Okay, I've pulled together the feedback and made a few more attempts.
     
     I compile the program using:
        gcc -o simple.c
     
     and link using:
     
     link simple.o libc.a libcygwin.a libkernel32.a libuser32.a glu32.lib 
     opengl32.lib libgdi32.a /subsystem:windows /machine:i386 
     /entry:mainCRTStartup
     
     The output:
     
//f/pgming/opengl/simple$ make
link simple.o libc.a libcygwin.a libkernel32.a libuser32.a glu32.lib opengl32.li
b libgdi32.a /subsystem:windows /machine:i386 /entry:mainCRTStartup
Microsoft (R) 32-Bit Incremental Linker Version 5.00.7022
Copyright (C) Microsoft Corp 1992-1997. All rights reserved.

libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol ___CTOR_LIST
__
libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol ___DTOR_LIST
__
libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __data_start
__
libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __data_end__

libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __bss_start_
_
libcygwin.a(libccrt0.o) : error LNK2001: unresolved external symbol __bss_end__
simple.exe : fatal error LNK1120: 6 unresolved externals
make: *** [simple.exe] Error 25
//f/pgming/opengl/simple$
     
     I greped the contents of every .a I could find and there's no trace of a 
     __data_start__ tag anywhere.  I grep them by doing the following:
     
        mkdir out
        for x in *.a; do nm $x > out/$x; done;
        cd out
        egrep data_start *
     
     This has the advantage of telling me which file any matches are found.  It 
     worked quite well for finding _GetModuleHandleA@4.  I also checked crt0.o 
     just in case.  Maybe the compiler was suppose to generate these symbols?  
     Or maybe it's something ld understands but link doesn't?
     
     Simple.c is a very simple windows program (with a WinMain) that calls 
     OpenGL primitives.  I copied it from a companion CD of a book to use for 
     testing this out.
     
     The GNU-Win32 I'm using I pulled from 
        ftp://ftp.cygnus.com/pub/gnu-win32/latest/all.tar.gz
     
     Apparently this is b17, not b17.1.  Sounds like getting the patches to 
     b17.1 should resolve the issue of using OpenGL.  Though I'm still 
     interested in getting this to work.  (call me stubborn if you like)
     
     So, any ideas about why I'm missing these symbols and what can I do about 
     it?
     
     Thanks, for the help guy's!  I do appreciate it!
     
     Dave

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <Wed, 26 Mar 97 10:42:13 PST_6@ccm.jf.intel.com>
Subject: Re: Linking with .LIB files
CC: gnu-win32@cygnus.com, colin@bird.fu.is.saga-u.ac.jp
To: David W Palmer <David_W_Palmer@ccm.jf.intel.com>
MIME-Version: 1.0
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Organization: JQB Enterprises
From: Jim Balter <jqb@netcom.com>
Date: Thu, 27 Mar 1997 00:46:40 -0800
Message-ID: < 333A33F0.4F58@netcom.com >
Received: from sba-ca1-24.ix.netcom.com(204.32.201.56) by dfw-ix16.ix.netcom.com
 via smap (V1.3)
     id sma025517; Thu Mar 27 02:49:47 1997
Received: (from smap@localhost)
          by dfw-ix16.ix.netcom.com (8.8.4/8.8.4)
       id CAA25617; Thu, 27 Mar 1997 02:50:13 -0600 (CST)
Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) b
y mailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id AAA23068 for <David_W_Palmer@
ccm.jf.intel.com>; Thu, 27 Mar 1997 00:59:15 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id AAA28751 for <David_W_Palmer@ccm.jf
.intel.com>; Thu, 27 Mar 1997 00:56:55 -0800 (PST)
Return-Path: jqb@netcom.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: DLL to lib*.a?

[David W Palmer]

Text item: 


     Has this made it to the FAQ yet?  Try the following:
     
     dlltool --dllname ouch.dll --output-lib libouch.a
     
     Replace "ouch" with the DLL's base name for both ouch.dll and 
     libouch.a.
     
     Dave

Is there any tool or something available to turn a DLL into a lib*.a? 
Or any other way to use functions in a DLL?
     
     
-
For help on using this list, send a message to 
"gnu-win32-request@cygnus.com" with one line of text: "help".

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Precedence: bulk
Sender: owner-gnu-win32@cygnus.com
X-mailer: Pegasus Mail for Win32 (v2.53/R1)
Priority: normal
Subject: DLL to lib*.a?
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII
MIME-Version: 1.0
Date: Mon, 31 Mar 1997 21:10:51 +0000
To: gnu-win32@cygnus.com
Comments: Authenticated sender is <kunglao@prairienet.org>
Message-Id: <199704010308.VAA06062@bluestem.prairienet.org>
Received: from bozo (slip232.ice.net [206.102.146.232])
     by bluestem.prairienet.org (8.8.5/8.8.5) with SMTP id VAA06062
     for <gnu-win32@cygnus.com>; Mon, 31 Mar 1997 21:08:32 -0600 (CST)
From: kunglao@prairienet.org
Received: from bluestem.prairienet.org (root@bluestem.prairienet.org [192.17.3.4
])
     by cygnus.com (8.8.5/8.8.5) with ESMTP id TAA25001
     for <gnu-win32@cygnus.com>; Mon, 31 Mar 1997 19:12:14 -0800 (PST)
Received: (from daemon@localhost)
     by cygnus.com (8.8.5/8.8.5) id TAA25006
     for gnu-win32-outgoing; Mon, 31 Mar 1997 19:12:20 -0800 (PST)
Received: from cygnus.com (cygnus.com [205.180.230.20]) by mailbag.jf.intel.com
(8.8.5/8.7.3) with ESMTP id DAA02241; Tue, 1 Apr 1997 03:37:11 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id DAA07146; Tue, 1 Apr 1997 03:34:52
-0800 (PST)
Return-Path: gnu-win32-owner@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: globbing feature in 17.1 when not under bash issue (b

[DG Ellis]

Text item: 

I agree. I have just been looking at the code in .....
   cdksrc/winsup/dcrt0.cc  where the globing takes place.

There is code to "de-quote" and double quoted string in all cases when
argc/argv is being created and code to glob if not invoked under another 
cygwin32 app. The problem is, these are done in this order and in 2 
different routines.  My take at it is that the shell (bash) removes the 
outer set of quotes 'barfl more' or "bore me to" (assume normal unix 
behavior right?) and then calls the app with these sanitized strings. 
Thus the normal take would be to do no quote handling at all in the 
under-bash condition. However, if not, then should do whatever and as 
much as you want that the shell would have done had it been there:
  1: quote removal
  2: environ string expansion
  3: globing
  4: more?
I am hard pressed to find an elegant (read simple) way to convey that 
the argv entry was quoted after leaving the "build_argv" routine and as 
it goes into the "globify".  I vote for sending in the flag
 u->self->cygwin_parent_p  (set only if spawned from another cygwin app 
I assume) and combining the build_argv and globify into one routine.

I do it. You doit. Other ideas?
    Dave Ellis


______________________________ Reply Separator _________________________________
Subject: Re: globbing feature in 17.1 when not under bash issue (bug)
Author:  jqb@netcom.com at SMTPGATE
Date:    2/22/97 1:08 PM


Sergey Okhapkin wrote:
>
> David Ellis wrote:
> > that quoting of arguments was overlooked. Here is the test case 
> >
> >   find . -name '*.doc'
> >
> > Works great under bash but does a glob under cmd.exe and comes up 
> > with an effective comand line like:
> >   find . -name barf.doc two.doc more.doc

Not with single quotes it doesn't.

> In the last case globbing is performed by cmd.exe.

Huh? cmd.exe does not do globbing.  Under DOS/Windows, globbing 
is up to the individual commands to do.

David Ellis is right that cygwin doesn't handle quotes properly, 
but he's wrong about the argument being expanded in single quotes.

Under cmd.exe:

 ls *.doc    -> a.doc b.doc c.doc

 ls "*.doc"  -> a.doc b.doc c.doc
    BOGUS cygwin expands

 ls '*.doc'  -> ls '*.doc': no such file or directory
    BOGUS cygwin fails to strip single quotes

--
<J Q B>

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: < 01BC20F1.2025DA10@sos >
Subject: Re: globbing feature in 17.1 when not under bash issue (bug)
CC: "gnu-win32@cygnus.com" <gnu-win32@cygnus.com>,
        "'David Ellis'" <dg_ellis@ccm.jf.intel.com>
To: Sergey Okhapkin <sos@prospect.com.ru>
MIME-Version: 1.0
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Organization: JQB Enterprises
From: Jim Balter <jqb@netcom.com>
Date: Sat, 22 Feb 1997 13:08:04 -0800
Message-ID: < 330F6034.67A9@netcom.com >
Received: from sba-ca1-16.ix.netcom.com(204.32.201.48) by dfw-ix14.ix.netcom.com
 via smap (V1.3)
     id sma023365; Sat Feb 22 15:10:01 1997
Received: (from smap@localhost)
          by dfw-ix14.ix.netcom.com (8.8.4/8.8.4)
       id PAA23390; Sat, 22 Feb 1997 15:10:09 -0600 (CST)
Received: from dfw-ix14.ix.netcom.com (dfw-ix14.ix.netcom.com [206.214.98.14])
          by ormail.intel.com (8.8.4/8.8.4) with ESMTP
       id NAA10494 for <dg_ellis@ccm.jf.intel.com>; Sat, 22 Feb 1997 13:17:55 -0
800 (PST)
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.6/8.7.3) with ESMTP id NAA12839 for <dg_ellis@ccm.jf.intel.com>; S
at, 22 Feb 1997 13:18:04 -0800 (PST)
Return-Path: jqb@netcom.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: Understanding program startup

[DG Ellis]

Text item: 

Hello,
 I went and looked at libccrt0.cc and was able to figure out exactly what you 
where saying. However I still did not know how bash could pass the command line 
to an app when it was in the form of a string (and not an argv vector). I then 
decided to look at spawn.cc and found the code that I was hoping for. In that 
code, an argv is passed and is then processed into a "cooked" command line. This
cooking includes space detecting and quoting. It also doubles up on d-quotes 
(which are undone in dcrt0 build_argv). So I see where the process is done and 
complete. Now that I see the role of the code in dcrt0 for normal command lines,
I can now figure the "correct" path to take to help in the s-quote being ignored
etc behavior when the program is invoked outside a cygwin process.  Here is my 
proposal:

Move the "globify" call to before the compute_argc/build_argv sequence and 
operate on the original command line. Also within the confines of this "run only
if not under cygwin32" condition, pre-process the command line similar to the 
work done in spawn.cc that will respect d-quotes and s-quotes and wrap 
parameters with quoted spaces in d-quotes as spawn.cc does. This would not be a 
perfect process because this code would be working on the command string instead
of the original argv vector as in spawn. This code could also determine if the 
globbing characters are within quotes or not and not glob those. This "cooked" 
command line then could be passed on to compute_argc/build_argv as normal.  This
should bring the behavior in line (at least closer) with the operation under the
shell.

 Now the hard part, I probably won't be able to do this in the short term. I 
have worked around my original problem by just using d-quotes where I was using 
s-quotes.

   Thanks for the encouragement to look further into the process taken by a 
command in bash.

    Dave


______________________________ Reply Separator _________________________________
Subject: Re: Understanding program startup
Author:  jqb@netcom.com at SMTPGATE
Date:    3/19/97 8:14 PM


DG Ellis wrote:
>
>   I am not new to C programming, however, I am new to writing programs
> that run under a unix shell like bash.  For history, I found that single
> quotes are not respected by applications that use cygwin.dll when the
> program is invoked from outside bash.

That bug has been discussed here.

> I chased down the code to the
> winsup/dcrt0.cc source file and was busy modifying it when I decided to
> check on the behavior of "normal" command lines under bash and under NT.
> Well, I see where the code should behave certain ways and does when run
> under NT command processor, but does not behave at all the same when
> under bash.

bash does its own command line processing, so doing it in dcrt0
for programs run under bash would just mess things up.

> Now here is my question:
> My suspicion is that the routine dll_crt0_1 is not called if the
> program is run under the shell. Is this correct?

No, not at all.  Note the code in dll_crt0_1:

  if (! u->self->cygwin_parent_p)
    globify (&argc, &argv);

That does wildcard expansion if cygwin_parent_p isn't set.
cygwin_parent_p is set in pinfo_init (which is called a bit earlier
in dll_crt0_1) if the PID environment variable is set and matches
the corresponding process table (pinfo) entry.  That will be the
case if this process was execed by a cygwin process, such as bash.
There are of course other messy and confusing details.

> I will try to check on
> libc's crt0 to see if this is true (if I can find the source).

cygwin_crt0 in winsup/libccrt0.c, which is linked into the application
code, calls the dll_crt0 in dcrt0.cc in cygwin.dll.

> It looks
> like there are a lot of important things in the dll_crt0_1 routine that
> should be done in each case. If they don't get done, what happens?

Nothing useful, since dll_crt0_1 calls main, among its other important
functions.

> Could this be the ctrl-C crash problem???

Nope, sorry.

--
<J Q B>

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
References: <Wed, 19 Mar 97 18:00:22 PST_2@ccm.hf.intel.com>
Subject: Re: Understanding program startup
CC: gnu-win32@cygnus.com
To: DG Ellis <DG_Ellis@ccm.jf.intel.com>
MIME-Version: 1.0
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Organization: JQB Enterprises
From: Jim Balter <jqb@netcom.com>
Date: Wed, 19 Mar 1997 20:14:32 -0800
Message-ID: < 3330B9A8.2546@netcom.com >
Received: from sba-ca1-20.ix.netcom.com(204.32.201.52) by dfw-ix6.ix.netcom.com
via smap (V1.3)
     id sma000876; Wed Mar 19 22:16:59 1997
Received: (from smap@localhost)
          by dfw-ix6.ix.netcom.com (8.8.4/8.8.4)
       id WAA00922; Wed, 19 Mar 1997 22:17:24 -0600 (CST)
Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by m
ailbag.jf.intel.com (8.8.5/8.7.3) with ESMTP id UAA24266 for <DG_Ellis@ccm.jf.in
tel.com>; Wed, 19 Mar 1997 20:26:27 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id UAA21160 for <DG_Ellis@ccm.jf.intel
.com>; Wed, 19 Mar 1997 20:24:08 -0800 (PST)
Return-Path: jqb@netcom.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Windows API calls that don't work? (Was RE: Stupid stupi

[David W Palmer]

Text item: 

     
     Colin, 
      
     I just tried Smith's code under WinNT 4.0 using GNU-Win32 with no 
     source modifications.
     
     It compiled and ran properly with commented out code.  However, it 
     failed as he described with the code included.
     
     I also compiled it under VC++ 5.0 (though I had to change STDCALL to 
     WINAPI).  It worked fine in all cases.  The modified sample program 
     still wouldn't work when compiled with GCC.
     
> Are you using a completely vanilla version of GNU-Win32 or have you 
made changes to things (like the startup code for example)? Could you 
send me a copy of your silently failing binary?
     
     Out of the box GNU-Win32.  I'll send you a mime encoded version of my 
     gcc generated exe.  It's a little large to send to the mailing list.
     
> PS. Any confirmations on that statement about NT from other readers?
    Does stripping an executable make it work? Do you *have* to strip 
    on NT? Is there a difference between the -s link option and using 
    strip after linking?

     I tried the following commands:
        strip test.exe
     and 
        strip test.exe -o tests.exe
     
     Neither cases made any difference.
     
     Running the program from BASH under NTEmacs produces the 
     following stack dump:
     
     //f/pgming/cygtest$ ./test
     (test.exe 1279) In cygwin_except_handler
     (test.exe 1279) Exception trapped!
     (test.exe 1279) exception C0000005 at 4194
     (test.exe 1279) exception: ax 0 bx 240FB00 cx 240FDFC dx A00115C
     (test.exe 1279) exception: si 5 di 100113BF bp 240F258 sp 240F24C
     (test.exe 1279) exception is: STATUS_ACCESS_VIOLATION
     (test.exe 1279) Stack trace:
     (test.exe 1279) frame 0: sp = 0x240F080, pc = 0x1001282A
     (test.exe 1279) frame 1: sp = 0x240F09C, pc = 0x77F94072
     (test.exe 1279) frame 2: sp = 0x240F0C0, pc = 0x77F88A53
     (test.exe 1279) frame 3: sp = 0x240F14C, pc = 0x77F75E82
     (test.exe 1279) frame 4: sp = 0x240F258, pc = 0x10011BEB
     (test.exe 1279) frame 5: sp = 0x240FF9C, pc = 0x10011BFF
     (test.exe 1279) frame 6: sp = 0x240FFA8, pc = 0x4011B0
     (test.exe 1279) frame 7: sp = 0x240FFB8, pc = 0x401012
     (test.exe 1279) frame 8: sp = 0x240FFC0, pc = 0x77F1AFC1
     (test.exe 1279) frame 9: sp = 0x240FFF0, pc = 0x0
     (test.exe 1279) End of stack trace
     //f/pgming/cygtest$ 
     
     I compiled with symbols "-O -g" with gcc, then using GDB I set a brake 
     point on GetTopWindow().  The access violation was generated before it 
     got to the break point.
     
     BTW: DRS chill.  Phill is just trying to help.
     
     Dave

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Precedence: bulk
Sender: owner-gnu-win32@cygnus.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Date: Mon, 24 Mar 1997 15:52:54 +0900
Subject: Windows API calls that don't work? (Was RE: Stupid stupid question :/)
Cc: "'GNU-Win32'" <gnu-win32@cygnus.com>
To: "'A. Phillip Smith'" <asmith@www.aeinc.com>
From: Colin Peters <colin@bird.fu.is.saga-u.ac.jp>
Message-ID: < 01BC386B.709FACA0@gbird0 >
Received: by gbird0 with Microsoft Mail
     id < 01BC386B.709FACA0@gbird0 >; Mon, 24 Mar 1997 15:52:56 +0900
Received: from gbird0 ([133.49.23.250]) by bird.fu.is.saga-u.ac.jp (8.8.2/3.3W7-
bird) with SMTP id PAA10839; Mon, 24 Mar 1997 15:53:11 +0900 (JST)
Received: from bird.fu.is.saga-u.ac.jp (bird.fu.is.saga-u.ac.jp [133.49.23.129])

     by cygnus.com (8.8.5/8.8.5) with ESMTP id WAA08904
     for <gnu-win32@cygnus.com>; Sun, 23 Mar 1997 22:54:42 -0800 (PST)
Received: (from daemon@localhost)
     by cygnus.com (8.8.5/8.8.5) id WAA08913
     for gnu-win32-outgoing; Sun, 23 Mar 1997 22:54:59 -0800 (PST)
Received: from cygnus.com (cygnus.com [205.180.230.20]) by mailbag.jf.intel.com
(8.8.5/8.7.3) with ESMTP id GAA20943; Mon, 24 Mar 1997 06:25:38 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id GAA06921; Mon, 24 Mar 1997 06:23:18
 -0800 (PST)
Return-Path: gnu-win32-owner@cygnus.com
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: DLL to lib*.a?

[kunglao]

> 
>      Has this made it to the FAQ yet?  Try the following:
>      
>      dlltool --dllname ouch.dll --output-lib libouch.a
>      
>      Replace "ouch" with the DLL's base name for both ouch.dll and 
>      libouch.a.
>      
>      Dave

Tried that.  It made a very small lib (1514 bytes).  I have read 
about needing a .def and/or export file.  But nothing about how to 
make them, either :).

thanks
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re[2]: env command does not work correctly.

[DG Ellis]

Text item: 


Simple minor note that the $foo in the command below is interpreted by the
original command line interpreter before the actual statement is executed.
This is why this example will not work. The example given in the post by
Fabio is correct in its use.
  You could try:

  foo=hi eval echo '$foo'

This would cause $foo to be protected first time arround, then let
eval evaluate the command after the assignment and do the echo.

    FWIW  Dave Ellis
______________________________ Reply Separator _________________________________
Subject: Re: env command does not work correctly.
Author:  gnu-win32-owner@cygnus.com at SMTPGATE
Date:    4/4/97 3:30 PM


     env is a command typically used in csh-like shells. With bash, you can
     just say:

     ONE=one TWO=two echo_1_2

     This also does not work with cygwin32 17.1.

     The simple statement: foo=hello echo $foo
     doesn't work.

     Also I am not real familiar with unix so I don't know if this is a bug
     or not:  Only uppercase environment variables can be exported.

     +------------------------------+------------------------------------+
     | Scott A. Mintz               | voice: (216) 646-4805              |
     | Allen-Bradley Company        | fax:   (216) 646-4961              |
     | 1 Allen-Bradley Drive        | email: scott.mintz@po.cle.ab.com   |
     | Mayfield Hts., OH 44124-6118 | CIS:   71461,632                   |
     +------------------------------+------------------------------------+




______________________________ Reply Separator ________________________________
_
Subject: env command does not work correctly.
Author:  Fabio@Colorado.EDU at Internet
Date:    4/3/97 2:02 PM


>>>>> "JDR" == John D Robertson <john@rrci.com> writes:

 JDR> Platform: Win95 / Intel Release: B17.1

 JDR> The "env" command does not set environmental variables as it is
 JDR> supposed to.  For example:

 JDR>    env ONE=one TWO=two echo_1_2

 JDR> where echo_1_2 is a sh script:

env is a command typically used in csh-like shells. With bash, you
can just say:

  ONE=one TWO=two echo_1_2

Under Linux, env works fine with both tcsh and bash.  I haven't tried
env with cygwin---I wasn't even aware of its inclusion---and right now
I have no access to my Win95 laptop. But it looks like a bug.

Fabio

--
Fabio Somenzi          | Phone: 303-492-3466
University of Colorado | Fax:   303-492-2758
ECE Dept.              | Email: Fabio@Colorado.EDU
Boulder CO 80309-0425  | WWW:   http://vlsi.colorado.edu/~fabio
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list, send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Precedence: bulk
Sender: owner-gnu-win32@cygnus.com
Content-Description: cc:Mail note part
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Cc: gnu-win32@cygnus.com
To: "John D. Robertson" <john@rrci.com>, Fabio@Colorado.EDU
Subject: Re: env command does not work correctly.
From: Scott.Mintz@po.cle.ab.com (Scott Mintz)
Message-ID: < 00037E4E.1893@po.cle.ab.com >
Date: Fri, 4 Apr 1997 15:30:58 -0500
Mime-Version: 1.0
Received: from ccMail by po.cle.ab.com
  (IMA Internet Exchange 2.1 (Gold Candidate) Enterprise) id 00037E4E; Fri, 4 Ap
r 97 15:35:40 -0500
Received: from po.cle.ab.com (po.cle.ab.com [130.151.192.20]) by po.ab.com (8.7.
1/RA1.1) with SMTP id PAA18225; Fri, 4 Apr 1997 15:38:42 -0500 (EST)
Received: from po.ab.com(130.151.128.20) by extfw.cle.ra.rockwell.com via smap (
3.2)
     id xma010199; Fri, 4 Apr 97 15:44:17 -0500
Received: by extfw.cle.ra.rockwell.com; id PAA10250; Fri, 4 Apr 1997 15:44:34 -0
500
Received: from extfw.cle.ra.rockwell.com (firewall-user@extfw.cle.ra.rockwell.co
m [192.159.76.10])
     by cygnus.com (8.8.5/8.8.5) with SMTP id MAA25963
     for <gnu-win32@cygnus.com>; Fri, 4 Apr 1997 12:44:41 -0800 (PST)
Received: (from daemon@localhost)
     by cygnus.com (8.8.5/8.8.5) id MAA25968
     for gnu-win32-outgoing; Fri, 4 Apr 1997 12:44:48 -0800 (PST)
Received: from cygnus.com (cygnus.com [205.180.230.20]) by mailbag.jf.intel.com
(8.8.5/8.7.3) with ESMTP id DAA24047; Sat, 5 Apr 1997 03:15:33 -0800 (PST)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id DAA25843; Sat, 5 Apr 1997 03:13:19
-0800 (PST)
Return-Path: gnu-win32-owner@cygnus.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Installing b18 usertools

[Brett A Carter]

     I'm having trouble installing b18 of the usertools.exe.  When I run 
     usertools.exe I get a message saying that it needs the wapi.dll.  I 
     can't find this file anywhere.  I am trying to install on a 486/50 
     with 16megs of ram and win95 ver. 4.00.95a.  Any suggestions?
     -Brett Carter
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

>>>ADVERTISE TO 11,759,000 PEOPLE FREE!

[FreeEmailSoftware1]

Dear cygwin@cygwin.com,

              
                 ***********************************************************
                 Would you like to send an Email Advertisement to
                   OVER 11 MILLION PEOPLE DAILY for FREE?
                 ***********************************************************
 
Do you have a product or service to sell?
Do you want an extra 100 orders per week?

NOTE: (If you do not already have a product or service to sell, we can 
supply you with one).

=========================================================
1) Let's say you... Sell a $24.95 PRODUCT or SERVICE.
2) Let's say you... Broadcast Email to only 500,000 PEOPLE.
3) Let's say you... Receive JUST 1 ORDER for EVERY 2,500 EMAILS.

CALCULATION OF YOUR EARNINGS BASED ON THE ABOVE STATISTICS:

[Day 1]: $4,990  [Week 1]: $34,930  [Month 1]: $139,720

========================================================
To find out more information, Do not respond by email. Instead, Please 
visit our web site at: 

http://www.bigcashtoday.com/package1.htm



List Removal Instructions:
We hope you enjoyed receiving this message. However, if you'd rather 
not receive future e-mails of this sort from Internet Specialists, send an
email to freeemailsoftware3@excite.com and type "remove" in the 
"subject" line and you will be removed from any future mailings.

We hope you have a great day!
Internet Specialists


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Problem with Windows .lnk files treated as Symlinks

[Martin Oberhuber]

Hello,

since cygwin-1.3, Windows *.lnk files are treated as UNIX
symbolic links by default.

We rean into a problem where we wanted to use the "cp" 
command to copy a Windows *.lnk shortcut to a new place.
This worked alright with previous cygwin versions, but
with 1.3, the file referenced was copied instead of the
*.lnk file. 

One problem with this behavour is that additional attributes
of the *.lnk file (like parameters passed to the program
referenced, or an icon associated) are not copied in that 
case.

Looking at options of the CYGWIN environment variable as
well as options of the "cp" command, I found NO WAY of
copying the *.lnk file instead of the file referenced!
Even "cp -d", which is documented to preserve symbolic
links (and works like that on Linux) did not work.
Setting CYGWIN=nowinsymlinks only affects link creation,
but not link interpretation by "cp".

Taking into account that Windows Shortcuts are more than
UNIX symbolic links, and that thus a one-to-one mapping
is always problematic, I would suggest the following to
preserve a clean environment as well as backward
compatibility:

1.) Only *.lnk files created by Cygwin (with the special
    cygwin header), should be treated as symbolic links when 
    they are read. If the *.lnk file is not a "cygwin *.lnk"
    with its special header, it should be treated as a plain 
    file.
    If this is not observed, important information may be lost 
    (also think about programs like tar that cannot reproduce 
    an exact image of the original file system if *.lnk files 
    are not completely copied).

2.) If CYGWIN=nowinsymlinks is set, not only symbolic link
    creation but also symbolic link interpretation should
    be "classical", i.e. *.lnk files are treated as files.

Please keep me informed on your plans regarding this issue.

Thanks in advance,
Martin Oberhuber

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with Windows .lnk files treated as Symlinks

[Larry Hall (RFK Partners, Inc)]

At 09:27 AM 5/3/2001, Martin Oberhuber wrote:
>Hello,
>
>since cygwin-1.3, Windows *.lnk files are treated as UNIX
>symbolic links by default.
>
>We rean into a problem where we wanted to use the "cp" 
>command to copy a Windows *.lnk shortcut to a new place.
>This worked alright with previous cygwin versions, but
>with 1.3, the file referenced was copied instead of the
>*.lnk file. 
>
>One problem with this behavour is that additional attributes
>of the *.lnk file (like parameters passed to the program
>referenced, or an icon associated) are not copied in that 
>case.
>
>Looking at options of the CYGWIN environment variable as
>well as options of the "cp" command, I found NO WAY of
>copying the *.lnk file instead of the file referenced!
>Even "cp -d", which is documented to preserve symbolic
>links (and works like that on Linux) did not work.
>Setting CYGWIN=nowinsymlinks only affects link creation,
>but not link interpretation by "cp".
>
>Taking into account that Windows Shortcuts are more than
>UNIX symbolic links, and that thus a one-to-one mapping
>is always problematic, I would suggest the following to
>preserve a clean environment as well as backward
>compatibility:
>
>1.) Only *.lnk files created by Cygwin (with the special
>     cygwin header), should be treated as symbolic links when 
>     they are read. If the *.lnk file is not a "cygwin *.lnk"
>     with its special header, it should be treated as a plain 
>     file.
>     If this is not observed, important information may be lost 
>     (also think about programs like tar that cannot reproduce 
>     an exact image of the original file system if *.lnk files 
>     are not completely copied).


Since the goal of making Cygwin symbolic links use the Windows short-cut 
mechanism was to allow Windows and Cygwin to interoperate in this area, I
don't see any benefit to trying to break this with your suggestion.  
Certainly, this is the way things worked prior to this change since short-cuts
were not understood by Cygwin and Cygwin symbolic links were not understood
by Windows.  If you need this division, you want to use the old mechanism.


>2.) If CYGWIN=nowinsymlinks is set, not only symbolic link
>     creation but also symbolic link interpretation should
>     be "classical", i.e. *.lnk files are treated as files.


This may be indicative of a bug.


>Please keep me informed on your plans regarding this issue.


Watch the list and you'll see any discussion of this.  Or send in a patch for
(2) for consideration.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Problem with Windows .lnk files treated as Symlinks

[Christopher Faylor]

On Thu, May 03, 2001 at 10:48:05AM -0400, Larry Hall (RFK Partners, Inc) wrote:
>>2.) If CYGWIN=nowinsymlinks is set, not only symbolic link
>>     creation but also symbolic link interpretation should
>>     be "classical", i.e. *.lnk files are treated as files.
>
>This may be indicative of a bug.

This isn't a bug.  The setting is only to force creation of old style symlinks.
Either style is supposed to be recognized on "reading".  I suppose the option
could have been "nocreatewinsymlinks"...

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

KSH is pdksh

[Galen Boyer]

After reviewing some archives, I find that pdksh is cygwin's
version of ksh.  Is this still available and where do I get it?
My c:/cygwin/bin doesn't contain it.

Thanks.
-- 
Galen Boyer
Fingers and toes, fingers and toes, forty things we share.
Forty one if you include, the fact that we don't care.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Larry Hall (RFK Partners, Inc)]

At 04:36 PM 1/24/2001, Galen Boyer wrote:
>After reviewing some archives, I find that pdksh is cygwin's
>version of ksh.  Is this still available and where do I get it?
>My c:/cygwin/bin doesn't contain it.


pdksh is not Cygwin's version of ksh but rather an open-source version of
ksh which can be built and used under Cygwin.  You can check the Cygwin 
home page for pointers to related sites with ported software and you can
also look in the mail archives for indications that others have ported it
and made it available.  Alternatively, you can just download the source 
from your favorite GNU site and build it yourself.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[David Feustel]

The ATT Korn Shell is now open source and should
compile with Cygwin. Get it at http://www.kornshell.com/

----- Original Message ----- 
From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
To: "Galen Boyer" <galenboyer@yahoo.com>; <cygwin@sourceware.cygnus.com>
Sent: Wednesday, January 24, 2001 5:31 PM
Subject: Re: KSH is pdksh


> At 04:36 PM 1/24/2001, Galen Boyer wrote:
> >After reviewing some archives, I find that pdksh is cygwin's
> >version of ksh.  Is this still available and where do I get it?
> >My c:/cygwin/bin doesn't contain it.
> 
> 
> pdksh is not Cygwin's version of ksh but rather an open-source version of
> ksh which can be built and used under Cygwin.  You can check the Cygwin 
> home page for pointers to related sites with ported software and you can
> also look in the mail archives for indications that others have ported it
> and made it available.  Alternatively, you can just download the source 
> from your favorite GNU site and build it yourself.
> 
> 
> 
> Larry Hall                              lhall@rfk.com
> RFK Partners, Inc.                      http://www.rfk.com
> 118 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
> 
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Corinna Vinschen]

On Wed, Jan 24, 2001 at 04:36:33PM -0500, Galen Boyer wrote:
> After reviewing some archives, I find that pdksh is cygwin's
> version of ksh.  Is this still available and where do I get it?
> My c:/cygwin/bin doesn't contain it.

Ooops, pdksh is _not_ the Cygwin version of ksh. Pdksh is an open
source implementation of ksh which isn't bound to a specific OS.
Latest sources are available in ftp://ftp.cs.mun.ca/pub/pdksh , an
OLD Cygwin binary which only supports binmode mounts is available in
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Vinschen_Corinna/B20

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[David M. Karr]

>>>>> "Galen" == Galen Boyer <galenboyer@yahoo.com> writes:
  Galen> After reviewing some archives, I find that pdksh is cygwin's
  Galen> version of ksh.  Is this still available and where do I get it?
  Galen> My c:/cygwin/bin doesn't contain it.

As Larry explained, this is something different.

However, as I've come to discover after much pain, if you're already
using Cygwin, there isn't much point to installing pdksh.  It's easy
enough to create a symlink from "/usr/bin/ksh.exe" to
"/usr/bin/bash.exe".  Poof.  You have Korn shell.  As far as I can
tell, Bash can substitute for Korn shell in every area I'm familiar
with.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Earnie Boyd]

"David M. Karr" wrote:
> 
> >>>>> "Galen" == Galen Boyer <galenboyer@yahoo.com> writes:
>   Galen> After reviewing some archives, I find that pdksh is cygwin's
>   Galen> version of ksh.  Is this still available and where do I get it?
>   Galen> My c:/cygwin/bin doesn't contain it.
> 
> As Larry explained, this is something different.
> 
> However, as I've come to discover after much pain, if you're already
> using Cygwin, there isn't much point to installing pdksh.  It's easy
> enough to create a symlink from "/usr/bin/ksh.exe" to
> "/usr/bin/bash.exe".  Poof.  You have Korn shell.  As far as I can
> tell, Bash can substitute for Korn shell in every area I'm familiar
> with.
> 

I knew that once upon a time.  Thanks for reminding me.  Hey miss bash
maintainer how about a postinstall script to ln -s bash.exe ksh.exe?

Cheers,
Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Mumit Khan]

On Wed, 24 Jan 2001, Earnie Boyd wrote:

> "David M. Karr" wrote:
> > "/usr/bin/bash.exe".  Poof.  You have Korn shell.  As far as I can
> > tell, Bash can substitute for Korn shell in every area I'm familiar
> > with.
> > 

Nope, bash is not ksh. There are quite a few ksh93 features that are not
implemented in bash (and possibly quite a few from ksh88 days, but I
don't have details on those).

> I knew that once upon a time.  Thanks for reminding me.  Hey miss bash
> maintainer how about a postinstall script to ln -s bash.exe ksh.exe?

Please don't. I personally very much dislike misleading links. If people
want ksh, they should go and port it using the AT&T's now open source
ksh93.

Regards,
Mumit




--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[David M. Karr]

>>>>> "Mumit" == Mumit Khan <khan@nanotech.wisc.edu> writes:
  Mumit> On Wed, 24 Jan 2001, Earnie Boyd wrote:

  >> "David M. Karr" wrote:
  >> > "/usr/bin/bash.exe".  Poof.  You have Korn shell.  As far as I can
  >> > tell, Bash can substitute for Korn shell in every area I'm familiar
  >> > with.

  Mumit> Nope, bash is not ksh. There are quite a few ksh93 features that are not
  Mumit> implemented in bash (and possibly quite a few from ksh88 days, but I
  Mumit> don't have details on those).

I'm not going to dispute that, but could you please give us some
examples of ksh88 and ksh93 features that aren't transparently
available in bash?  I'd like to know exactly what problems I could run
into.  I haven't noticed anything yet.  Does someone know which
canonical ksh version (ksh88 or ksh93) the Solaris ksh matches?

  Mumit> Please don't. I personally very much dislike misleading links. If people
  Mumit> want ksh, they should go and port it using the AT&T's now open source
  Mumit> ksh93.

It would sure be nice to bring a maintainable ksh into the Cygwin
fold, just for the sake of increased Unix compatibility.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Larry Hall (RFK Partners, Inc)]

At 11:21 AM 1/25/2001, David M. Karr wrote:
>   Mumit> Please don't. I personally very much dislike misleading links. If people
>   Mumit> want ksh, they should go and port it using the AT&T's now open source
>   Mumit> ksh93.
>
>It would sure be nice to bring a maintainable ksh into the Cygwin
>fold, just for the sake of increased Unix compatibility.


Volunteers welcome!:-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Matthew Smith]

For what it's worth, I started taking a stab at compiling AT&T's ksh.  Man,
they certainly do use some wacky packaging tools.  At any rate, here are
some of the problems that I encountered, and what I did about them.

1) The 'package' script wants to see getopts.  Thus, I made sh a link to
bash to work around this.

2) The 'package' script always seemed to fail, complaining about not being
in the package root (when it was).  I solved this by editing the package
script to not exit if that particular error happened.

3) I made a link from gcc->cc for convenience sake (read: laziness).

At this point the 'mamake' utility seems to start configuring/making things.
However, it spits out the following errors:

/home/matts/att/src/lib/libast/include/ast_std.h:672: conflicting types for
`rea
d'
/usr/include/sys/unistd.h:72: previous declaration of `read'
/home/matts/att/src/lib/libast/include/ast_std.h:690: conflicting types for
`wri
te'
/usr/include/sys/unistd.h:99: previous declaration of `write'

Can anyone suggest an elegant way around this?

thanks,
-Matt Smith


> >
> >It would sure be nice to bring a maintainable ksh into the Cygwin
> >fold, just for the sake of increased Unix compatibility.
>
>
> Volunteers welcome!:-)
>



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Earnie Boyd]

Matthew Smith wrote:
> 
> Can anyone suggest an elegant way around this?
> 

Fix the code.  Remove the redefinitions.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Newlib's non-posix'ness [Re: KSH is pdksh]

[Mumit Khan]

On Thu, 25 Jan 2001, Earnie Boyd wrote:

> Matthew Smith wrote:
> > 
> > Can anyone suggest an elegant way around this?
> > 
> 
> Fix the code.  Remove the redefinitions.

FYI, it's newlib that provides the incorrect declaration. It's one of 
those cases where newlib's declarations don't quite match POSIX/UNIX98, 
but small enough that nobody has bothered to fix those. Mostly has to 
do with signed vs unsigned (eg., size_t vs ssize_t) and those little
nits. Interestingly enough, someone, quite possibly Joel Scherrill, had 
gone through newlib and fixed most of these, if not all, but only for 
RTEMS! 

POSIX:
    ssize_t read (int, void *, size_t);

newlib:
    #ifdef __rtems__
      ssize_t read (int, void *, size_t);
    #else
      int read (int, void *, size_t);
    #endif

Perhaps Chris and/or DJ know why that is the case.

When you have a conflict between Glenn Fowler's AT&T AST and another 
library, chances are that AST is doing the right thing.

Regards,
Mumit



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Newlib's non-posix'ness [Re: KSH is pdksh]

[Earnie Boyd]

Mumit Khan wrote:
> 
> On Thu, 25 Jan 2001, Earnie Boyd wrote:
> 
> > Matthew Smith wrote:
> > >
> > > Can anyone suggest an elegant way around this?
> > >
> >
> > Fix the code.  Remove the redefinitions.
> 
> FYI, it's newlib that provides the incorrect declaration. It's one of
> those cases where newlib's declarations don't quite match POSIX/UNIX98,
> but small enough that nobody has bothered to fix those. Mostly has to
> do with signed vs unsigned (eg., size_t vs ssize_t) and those little
> nits. Interestingly enough, someone, quite possibly Joel Scherrill, had
> gone through newlib and fixed most of these, if not all, but only for
> RTEMS!
> 
> POSIX:
>     ssize_t read (int, void *, size_t);
> 
> newlib:
>     #ifdef __rtems__
>       ssize_t read (int, void *, size_t);
>     #else
>       int read (int, void *, size_t);
>     #endif
> 
> Perhaps Chris and/or DJ know why that is the case.
> 
> When you have a conflict between Glenn Fowler's AT&T AST and another
> library, chances are that AST is doing the right thing.
> 

There's been other chatter about problems with __rtems__ and Cygwin on
the newlib list; but, it was wrt pthreads.  I've CCed newlib on this.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Newlib's non-posix'ness [Re: KSH is pdksh]

[Christopher Faylor]

On Thu, Jan 25, 2001 at 04:30:52PM -0600, Mumit Khan wrote:
>On Thu, 25 Jan 2001, Earnie Boyd wrote:
>
>> Matthew Smith wrote:
>> > 
>> > Can anyone suggest an elegant way around this?
>> > 
>> 
>> Fix the code.  Remove the redefinitions.
>
>FYI, it's newlib that provides the incorrect declaration. It's one of 
>those cases where newlib's declarations don't quite match POSIX/UNIX98, 
>but small enough that nobody has bothered to fix those. Mostly has to 
>do with signed vs unsigned (eg., size_t vs ssize_t) and those little
>nits. Interestingly enough, someone, quite possibly Joel Scherrill, had 
>gone through newlib and fixed most of these, if not all, but only for 
>RTEMS! 
>
>POSIX:
>    ssize_t read (int, void *, size_t);
>
>newlib:
>    #ifdef __rtems__
>      ssize_t read (int, void *, size_t);
>    #else
>      int read (int, void *, size_t);
>    #endif
>
>Perhaps Chris and/or DJ know why that is the case.

Because the only thing that Joel cares about is RTEMS, basically.  He
broke Cygwin builds a couple of times with his changes and, I assume,
rather than try to build Cygwin after a change, opted to just
conditionalize everything.

>When you have a conflict between Glenn Fowler's AT&T AST and another 
>library, chances are that AST is doing the right thing.

Probably, but any package that doesn't build because it relies on read
being defined as ssize_t is not exactly portable.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Galen Boyer]

On 24 Jan 2001, dkarr@tcsi.com wrote:

> However, as I've come to discover after much pain, if you're
> already using Cygwin, there isn't much point to installing
> pdksh.  It's easy enough to create a symlink from
> "/usr/bin/ksh.exe" to "/usr/bin/bash.exe".  Poof.  You have
> Korn shell.  As far as I can tell, Bash can substitute for Korn
> shell in every area I'm familiar with.

Well, if I could find the equivalent to getopts, I think I could
get along without kornshell.  I found this feature to be
extremely useful when I was a heavy-duty KSH programmer, and now
I am coding a few scripts again and would like to take advantage
of it.

-- 
Galen Boyer
Fingers and toes, fingers and toes, forty things we share.
Forty one if you include, the fact that we don't care.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: KSH is pdksh

[Galen Boyer]

On 25 Jan 2001, galenboyer@yahoo.com wrote:

> Well, if I could find the equivalent to getopts, I think I
> could get along without kornshell.  I found this feature to be
> extremely useful when I was a heavy-duty KSH programmer, and
> now I am coding a few scripts again and would like to take
> advantage of it.

I got notified of the man pages for bash.  It looks really nice
for scripting.  getopts is just how I expected.  Whoa!  Cygwin is
excellent!

Thanks a WHOLE BUNCH!
-- 
Galen Boyer
Fingers and toes, fingers and toes, forty things we share.
Forty one if you include, the fact that we don't care.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Which of cygwin32's design goals does ascii file conversion fulfil?

[David Fox]

As I have noted before, there are two types of cygwin32 users, those
who are trying to make their Windows box feel more Unixy, and those
who are porting Unix code to Windows.  It seems to me that neither of
these groups has any need for DOS ``text mode'' conversion (where
lines are terminated by CR-LF.)  Why not make binary mode the one and
only default once and for all?

There's probably a good reason that I'm not aware of...
-- 
David Fox           http://hci.ucsd.edu/dsf             xoF divaD
UCSD HCI Lab                                         baL ICH DSCU
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Which of cygwin32's design goals does ascii file conversion fulfil?

[Larry Hall]

At 12:51 PM 10/23/98 -0700, David Fox wrote:
>As I have noted before, there are two types of cygwin32 users, those
>who are trying to make their Windows box feel more Unixy, and those
>who are porting Unix code to Windows.  It seems to me that neither of
>these groups has any need for DOS ``text mode'' conversion (where
>lines are terminated by CR-LF.)  Why not make binary mode the one and
>only default once and for all?
>
>There's probably a good reason that I'm not aware of...
>-- 
>David Fox           http://hci.ucsd.edu/dsf             xoF divaD
>UCSD HCI Lab                                         baL ICH DSCU

People who use Notepad will be bummed.  I'll leave it to you to determine
whether or not this is a good enough reason to support Windows text mode 
by default...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Which of cygwin32's design goals does ascii file conversion fulfil?

[Olle Olsson]

Larry Hall wrote:

> At 12:51 PM 10/23/98 -0700, David Fox wrote:
> >As I have noted before, there are two types of cygwin32 users, those
> >who are trying to make their Windows box feel more Unixy, and those
> >who are porting Unix code to Windows.  It seems to me that neither of
> >these groups has any need for DOS ``text mode'' conversion (where
> >lines are terminated by CR-LF.)  Why not make binary mode the one and

> >only default once and for all?--

The question as spelled out in the subject line is of course important. The
discussion of text vs. binary is not very productive, unless one states the
intention of providing the cygwin package.

I can see two camps around:
- those that want a Unix to run on the hardware that typically supports a
Windows system. But wouldn't it be better to go for a Linux, FreeBSD, NetBSD
or something like that. I.e. a true Unix system

-those that want Unix functionality to gracefully coexist *and_cooperate*
with functionality provided by a Windows platform. This cannot be provided
by a Linux at al. solution

Cooperation between Unix functionality and Windows functionality has two
implications: (a) to be able to share data between these two goups of
functionalities (i.e. programs) without necessarily bothering about
representatiuonal issues, and (b) to be able to have programs of the
different groups interact "seamlessly".

Enforcing a binary approach to data in Cygwin applications would make it
difficult to fulfill either of these two goals. Imagine using Netscape as a
browser and wanting to have Cygwin-based applications handling some types of
documents. If such applications could directly handle native Windows
representations, it would make life much more simple.

My understanding has been that Cygwin tries to achieve the "peaceful
coexistence and cooperation" goal. If Cygwin tools require a full binary
mount, then we do have some problems in achieveing the goal.

So, what are the Cygwin design goals really? Are we hoping for something
that cannot be fulfilled?

Or is it, as some have suggested, not the design goals of the Cygwin
infrastructure that is limiting us. Is it the design goals of the tool
porters that might restrict us?

/olle


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

Re: Which of cygwin32's design goals does ascii file conversion fulfil?

[Geoffrey Noer]

On Mon, Oct 26, 1998 at 12:21:10PM +0100, Olle Olsson wrote:
[...]
> -those that want Unix functionality to gracefully coexist *and_cooperate*
> with functionality provided by a Windows platform. This cannot be provided
> by a Linux at al. solution

This is the primary goal.  In my personal uses of Cygwin, I have never
needed to use binary mounts.  Instead, I have added the requisite
binary mode flags to open calls, etc.  Usually, it's not very
difficult.  Some of the text utilities that should be able to be used
in either text or binary mode still need binary flags added though,
that's about has hard as it gets (still not very)...

> Or is it, as some have suggested, not the design goals of the Cygwin
> infrastructure that is limiting us. Is it the design goals of the tool
> porters that might restrict us?

Ernie Boyd has written at length describing the typical changes to get
everything working correctly with text mode mounts (a version of which
will appear in the upcoming b20 FAQ) so I won't repeat it here.

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

Re: Which of cygwin32's design goals does ascii file conversion fulfil?

[Darren Cook]

>As I have noted before, there are two types of cygwin32 users, those
>who are trying to make their Windows box feel more Unixy, and those
>who are porting Unix code to Windows.  It seems to me that neither of

I'm trying mingw to see if it's a viable alternative to Visual C++.

>these groups has any need for DOS ``text mode'' conversion (where
>lines are terminated by CR-LF.)  Why not make binary mode the one and
>only default once and for all?

The main reason is writing a program that has to read or write files that
have to be used on Windows.

Actually I see you're just referring to what the default should be. I
always explicitly define "b" or "t", but I wonder how much existing code
would break if the default changed?

Darren

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

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Michael Hirmke]

Chris Faylor [cgf@cygnus.com] wrote:

[...]
>>>I don't think that announcements of (alternative) Posix-over-Win32 layers
>>>are on topic here but if everyone else disagrees, my opinion can be
>>>changed. 
>>
>>As long as an announcement is the only traffic generated by such an
>>alternative to Cygwin I'd be interested to read it in here.
>
>There is no way to guarantee that.

There is no way to guarantee anything regarding mail or news.
But the original poster could point to an appropriate location for
discussion - as Paul did. If anyone does not follow these instructions
you always can "kill" this guy.

>
>cgf
>

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Chris Faylor]

On Tue, Mar 14, 2000 at 12:28:00AM +0200, Michael Hirmke wrote:
>Chris Faylor [cgf@cygnus.com] wrote:
>[...]
>>>>I don't think that announcements of (alternative) Posix-over-Win32 layers
>>>>are on topic here but if everyone else disagrees, my opinion can be
>>>>changed. 
>>>
>>>As long as an announcement is the only traffic generated by such an
>>>alternative to Cygwin I'd be interested to read it in here.
>>
>>There is no way to guarantee that.
>
>There is no way to guarantee anything regarding mail or news.
>But the original poster could point to an appropriate location for
>discussion - as Paul did. If anyone does not follow these instructions
>you always can "kill" this guy.

My point is that you either disallow discussion or you allow it.
Saying "It's ok to post but nobody follow up!" is fairly unusual
for a mailing list.

It's usually "This is off-topic" please don't do that again.

The first way you get to (potentially) correct one person.  The second
way you get to correct many people.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Michael Hirmke]

Hi Chris,

[...]
>My point is that you either disallow discussion or you allow it.
>Saying "It's ok to post but nobody follow up!" is fairly unusual
>for a mailing list.
>
>It's usually "This is off-topic" please don't do that again.
>
>The first way you get to (potentially) correct one person.  The second
>way you get to correct many people.

Got your point!

>
>cgf

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

help on compiling perl/ nt with cygwin. gnu c lib missing

[john z]

im trying to install perl5.05_54 on a brand new nt box. it has a vanilla
setup. b20.1 full was installed and it seemed ok.

when i try the cygwin installation for perl, i get an error that 'gnu c
libary' not found. i modified ld2, and gcc2 and it seemed to pass that test.

can somebody tell me what i am missing. i did NOT install the gnu c library
(thought enough of it came over with full/ egcs.

am i missing some symbols?

(and please dont tell me i should switch to activestate perl). as is just
fine, but i want to use modules not yet supported.

tks
john z.
zephyr@wesell.com.NoJunkPad

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

Re: help on compiling perl/ nt with cygwin. gnu c lib missing

[Michael Hirmke]

Hi John,

>im trying to install perl5.05_54 on a brand new nt box. it has a vanilla

Can't answer your question, but:
5.005_54 is a developers release, not a production release - is that,
what you want ?
AFAIK the latest production release is 5.005_02 (perhaps 03 meanwhile).

[...]
>tks
>john z.

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: help on compiling perl/ nt with cygwin. gnu c lib missing

[Peter Moulder]

I think when I compiled perl, I supplied ,the path of directory
containing libc` in response to one of the configuration questions,
i.e. the default answer did not include this information.

I don't know whether or not that is the solution to your problem.

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

Re: help on compiling perl/ nt with cygwin. gnu c lib missing

[Peter Moulder]

john z <zephyr@wesell.com> writes:

> tks for the idea.  i just tried it and got a ton of messages before
> it hung.  and the messages are kinda nasty.  so i think maybe
> something else is going on.  betcha the cygwin feature was working
> before but got broken.  cause on the perl side it makes references
> to i386 instead of ther new i586 labeling.

Oh yes, another thing I did was to create some symlinks to satisfy
the perl configuration scripts.

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

Re: OpenGL and glut with B20.1

[Suhaib M. Siddiqi]

Brian Kasper last week sent me a set of Mesa 3.0 libraries for
Cygwin-B-20.
He did a really good job in porting Mesa to Cygwin-B20.

You can find precompiled LessTif 0.87 at
ftp://ftp.lesstif.org/pub/hungry/lesstif/bindir for
Cygnus-B-20.  I compiled them.  LessTif organization requested to
redistribute them
through LessTif ftp server instead of a third party site.  The Cygnus
precompiled version in that
archive is missing libXlt.a and libXlt.dll.  If you need Xlt port for
Cygnus-B20, let me know and I will
send it to you.  Beware, it is a 1.78 MB big file.

Suhaib




----- Original Message -----
From: Levon Saldamli <levon@lysator.liu.se>
To: <gnu-win32@cygnus.com>
Sent: Monday, February 01, 1999 6:39 PM
Subject: OpenGL and glut with B20.1


>
>I'd like to use OpenGL and glut with cygwin32 B20.1, possibly together
>with lesstif. What OpenGL and glut libraries and include files should
>I use to make it work? I've tried different set of files without
>success, and I feel I didn't find the most update versions (found in
>mailing list archive at cygnus). I'd appreciate some links to
>information and/or download places for this.
>
>Thanks in advance.
>
>--
>/Levon Saldamli
>-
>For help on using this list (especially unsubscribing), send a message
to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

Re: OpenGL and glut with B20.1

[Levon Saldamli]

> Brian Kasper last week sent me a set of Mesa 3.0 libraries for
> Cygwin-B-20.
> He did a really good job in porting Mesa to Cygwin-B20.

Where can I find these libraries?

-- 
/Levon Saldamli

Re: OpenGL and glut with B20.1

[Theodore Jump]

>Where can I find these libraries?

I've posted them on my WWW site here:

	http://www.i21.com/~tjump/files/#cygwin32

They're at the bottom of the table, you'll probably have to scroll down some to
see them.

Regards,
-Ted
______________________________________________________________________
http://www.i21.com/~tjump                   http://www.fighterduel.com

The train stops at the train station, the bus stops at the bus station,
So why am I sitting at a work station? -Ralph Hempel

Re: OpenGL and glut with B20.1

[Theodore Jump]

>Where can I find these libraries?

I've posted them on my WWW site here:

	http://www.i21.com/~tjump/files/#cygwin32

They're at the bottom of the table, you'll probably have to scroll down some to
see them.

Regards,
-Ted
______________________________________________________________________
http://www.i21.com/~tjump                   http://www.fighterduel.com

The train stops at the train station, the bus stops at the bus station,
So why am I sitting at a work station? -Ralph Hempel

unsubscribe

[john z]

unsubscribe

tks
john z.
zephyr@wesell.com.NoJunkPad

unsubscribe

[john z]

unsubscribe

tks
john z.
zephyr@wesell.com.NoJunkPad

Re: OpenGL and glut with B20.1

[Levon Saldamli]

> Brian Kasper last week sent me a set of Mesa 3.0 libraries for
> Cygwin-B-20.
> He did a really good job in porting Mesa to Cygwin-B20.

Where can I find these libraries?

-- 
/Levon Saldamli

Re: OpenGL and glut with B20.1

[Suhaib M. Siddiqi]

Brian Kasper last week sent me a set of Mesa 3.0 libraries for
Cygwin-B-20.
He did a really good job in porting Mesa to Cygwin-B20.

You can find precompiled LessTif 0.87 at
ftp://ftp.lesstif.org/pub/hungry/lesstif/bindir for
Cygnus-B-20.  I compiled them.  LessTif organization requested to
redistribute them
through LessTif ftp server instead of a third party site.  The Cygnus
precompiled version in that
archive is missing libXlt.a and libXlt.dll.  If you need Xlt port for
Cygnus-B20, let me know and I will
send it to you.  Beware, it is a 1.78 MB big file.

Suhaib




----- Original Message -----
From: Levon Saldamli <levon@lysator.liu.se>
To: <gnu-win32@cygnus.com>
Sent: Monday, February 01, 1999 6:39 PM
Subject: OpenGL and glut with B20.1


>
>I'd like to use OpenGL and glut with cygwin32 B20.1, possibly together
>with lesstif. What OpenGL and glut libraries and include files should
>I use to make it work? I've tried different set of files without
>success, and I feel I didn't find the most update versions (found in
>mailing list archive at cygnus). I'd appreciate some links to
>information and/or download places for this.
>
>Thanks in advance.
>
>--
>/Levon Saldamli
>-
>For help on using this list (especially unsubscribing), send a message
to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

First Cygwin Installation

[Hough, Louis F]

Cygwin,

	Will any version work as a first time install or
	do I have to have something else ??

	My e-mail is
	louhough@home.com

Louis Hough
206-655-6386 (206-416-4138 pager)
MS 4J-06
Louis.Hough@PSS.Boeing.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[DJ Delorie]

> 	Will any version work as a first time install or
> 	do I have to have something else ??

For a first-time install, go to http://cygwin.com/ and click on the
"Install Cygwin Now" icon.  The only choices you should have to make
are (0) that you want to install from the internet, (1) where to
install it on your machine, and (2) whether to use IE5, a direct
connection, or a proxy to access the internet.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[David M. Karr]

>>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:

  >> Will any version work as a first time install or
  >> do I have to have something else ??

  DJ> For a first-time install, go to http://cygwin.com/ and click on the
  DJ> "Install Cygwin Now" icon.  The only choices you should have to make
  DJ> are (0) that you want to install from the internet, (1) where to
  DJ> install it on your machine, and (2) whether to use IE5, a direct
  DJ> connection, or a proxy to access the internet.

Note that the "Default text file type" might be important, depending
on what you're using this for.  It will default to "Unix", as opposed
to "DOS".  If you have non-cygwin programs that expect DOS line
endings, and they might be reading files you would create while using
Cygwin, then they might not work properly if you set it to "Unix".
Just make sure you understand the choice.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[Larry Hall (RFK Partners, Inc)]

At 04:19 PM 1/4/2001, David M. Karr wrote:
> >>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:
>
>   >> Will any version work as a first time install or
>   >> do I have to have something else ??
>
>   DJ> For a first-time install, go to http://cygwin.com/ and click on the
>   DJ> "Install Cygwin Now" icon.  The only choices you should have to make
>   DJ> are (0) that you want to install from the internet, (1) where to
>   DJ> install it on your machine, and (2) whether to use IE5, a direct
>   DJ> connection, or a proxy to access the internet.
>
>Note that the "Default text file type" might be important, depending
>on what you're using this for.  It will default to "Unix", as opposed
>to "DOS".  If you have non-cygwin programs that expect DOS line
>endings, and they might be reading files you would create while using
>Cygwin, then they might not work properly if you set it to "Unix".
>Just make sure you understand the choice.
>
>-- 
>===================================================================
>David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
>dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)



An example list of applications that have some trouble reading files with
only UNIX line endings (newline only) include notepad, just about any old
DOS (and I mean DOS, not Windows) program, and VC++ if the file in question 
will also be edited by the class wizard.  With the exception of the VC++ 
issue, which is rather obscure, there's a solution to each of the other 
problems (i.e. replace them with programs that understand UNIX style line 
endings - there's lots of good alternatives here).  Every other Windows 
program I've used can read UNIX line endings just fine, because the underlying 
Win32 API call for accessing files supports reading newline-only line endings. 
I'm sure there are some other utility programs out there that still trip over 
UNIX line endings too but in general, this is pretty rare.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[David M. Karr]

>>>>> "Larry" == Larry Hall (RFK Partners, Inc) <lhall@rfk.com> writes:
  Larry> At 04:19 PM 1/4/2001, David M. Karr wrote:
  >> >>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:
  >> 
  >> >> Will any version work as a first time install or
  >> >> do I have to have something else ??
  >> 
  DJ> For a first-time install, go to http://cygwin.com/ and click on the
  DJ> "Install Cygwin Now" icon.  The only choices you should have to make
  DJ> are (0) that you want to install from the internet, (1) where to
  DJ> install it on your machine, and (2) whether to use IE5, a direct
  DJ> connection, or a proxy to access the internet.
  >> 
  >> Note that the "Default text file type" might be important, depending
  >> on what you're using this for.  It will default to "Unix", as opposed
  >> to "DOS".  If you have non-cygwin programs that expect DOS line
  >> endings, and they might be reading files you would create while using
  >> Cygwin, then they might not work properly if you set it to "Unix".
  >> Just make sure you understand the choice.

  Larry> An example list of applications that have some trouble reading files with
  Larry> only UNIX line endings (newline only) include notepad, just about any old
  Larry> DOS (and I mean DOS, not Windows) program, and VC++ if the file in question 
  Larry> will also be edited by the class wizard.  With the exception of the VC++ 
  Larry> issue, which is rather obscure, there's a solution to each of the other 
  Larry> problems (i.e. replace them with programs that understand UNIX style line 
  Larry> endings - there's lots of good alternatives here).  Every other Windows 
  Larry> program I've used can read UNIX line endings just fine, because the underlying 
  Larry> Win32 API call for accessing files supports reading newline-only line endings. 
  Larry> I'm sure there are some other utility programs out there that still trip over 
  Larry> UNIX line endings too but in general, this is pretty rare.

Unless I'm misunderstanding something, the public domain Korn shell is
another application that can't deal with Unix line endings.  For some
people, this is more likely to be an issue than notepad or vc++.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[Larry Hall (RFK Partners, Inc)]

At 04:52 PM 1/4/2001, David M. Karr wrote:
>   Larry> endings - there's lots of good alternatives here).  Every other Windows 
>   Larry> program I've used can read UNIX line endings just fine, because the underlying 
>   Larry> Win32 API call for accessing files supports reading newline-only line endings. 
>   Larry> I'm sure there are some other utility programs out there that still trip over 
>   Larry> UNIX line endings too but in general, this is pretty rare.
>
>Unless I'm misunderstanding something, the public domain Korn shell is
>another application that can't deal with Unix line endings.  For some
>people, this is more likely to be an issue than notepad or vc++.


Right.  It depends on the utilities you use, how old they are, and whether
they make use of the Win32 API for opening text files or not.  There are 
some utilities out there which are poorly ported to Windows.  Other than
utilities like these and the utilities I mentioned which are part of the
utilities that come with Windows (or its development environment), every
other Windows program that I've seen can read a text file with UNIX line 
endings, even edlin!;-)  (Yuck, who wants that!;-))  However, if you're 
concerned about some obscure program you know you need to interact with 
files created and manipulated with Cywgin tools, pick "DOS" files at Cygwin 
install time.  If you don't have reason to fear some utility you're using 
won't work with Cygwin created/manipulated files, stick with the defaults.  
Defaults exist because they generally give the best results for the majority. 
YMMV!;-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[Earnie Boyd]

"David M. Karr" wrote:
> 
> Unless I'm misunderstanding something, the public domain Korn shell is
> another application that can't deal with Unix line endings.  For some
> people, this is more likely to be an issue than notepad or vc++.
> 

A Cygwin build of pdksh produces a ksh which understands UNIX file
endings.  You may need to use the -mno-win32 switch though.

Cheers,
Earnie.

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  Earnie> "David M. Karr" wrote:
  >> 
  >> Unless I'm misunderstanding something, the public domain Korn shell is
  >> another application that can't deal with Unix line endings.  For some
  >> people, this is more likely to be an issue than notepad or vc++.

  Earnie> A Cygwin build of pdksh produces a ksh which understands UNIX file
  Earnie> endings.  You may need to use the -mno-win32 switch though.

The one I'm using is built with Cygwin, so perhaps the "-mno-win32"
option is needed.  I don't believe I used that switch when I built it.
I'll keep this in mind.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: First Cygwin Installation

[Christopher Faylor]

On Thu, Jan 04, 2001 at 02:52:58PM -0800, David M. Karr wrote:
>>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>  Earnie> "David M. Karr" wrote:
>  >> 
>  >> Unless I'm misunderstanding something, the public domain Korn shell is
>  >> another application that can't deal with Unix line endings.  For some
>  >> people, this is more likely to be an issue than notepad or vc++.
>
>  Earnie> A Cygwin build of pdksh produces a ksh which understands UNIX file
>  Earnie> endings.  You may need to use the -mno-win32 switch though.
>
>The one I'm using is built with Cygwin, so perhaps the "-mno-win32"
>option is needed.  I don't believe I used that switch when I built it.
>I'll keep this in mind.

It probably needs to be compiled with -mno-win32 and linked with
/usr/lib/textmode.o .

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Drive with cygwin moved from "E:" to "D:", how to fix?

[David M. Karr]

My colleague got a PC which was originally configured with the drive
with most of his work (including the cygwin installation) being "E:"
(the CD was "D:").  We realized it needed to be on "D:" to easily work
with some scripts we have.  We had that done, but now I see that
"mount" still thinks that Cygwin is installed on drive "E:".  This
causes some odd symptoms, although many things still work.  What is
the easiest way to reset Cygwin to know it's installed on drive "D:"?

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Drive with cygwin moved from "E:" to "D:", how to fix?

[DJ Delorie]

> causes some odd symptoms, although many things still work.  What is
> the easiest way to reset Cygwin to know it's installed on drive "D:"?

Just remount all the E: mounts to be D:, either with umount/mount or
with mount -f

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Drive with cygwin moved from "E:" to "D:", how to fix?

[David M. Karr]

>>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:

  >> causes some odd symptoms, although many things still work.  What is
  >> the easiest way to reset Cygwin to know it's installed on drive "D:"?

  DJ> Just remount all the E: mounts to be D:, either with umount/mount or
  DJ> with mount -f

Ok, after fiddling with this for a while, I finally got his new mount
table to look the same, except the "e:"s changed to "d:".  That looks
correct.

I see two odd symptoms on this new PC, however, which are probably
related.  On my PC, when I do "ls /usr", it gives me a valid listing
of what's in "d:/cygwin/usr".  On his PC, when I do "ls /usr", it says
"No such file or directory".  When I list "/usr/bin" on my PC, it also
lists fine.  When I list "/usr/bin" on his PC, it mostly is fine,
except it says "ls: ..: No such file or directory".  What could be the
cause of this?

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Drive with cygwin moved from "E:" to "D:", how to fix?

[Larry Hall (RFK Partners, Inc)]

At 04:38 PM 1/5/2001, David M. Karr wrote:
> >>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:
>
>   >> causes some odd symptoms, although many things still work.  What is
>   >> the easiest way to reset Cygwin to know it's installed on drive "D:"?
>
>   DJ> Just remount all the E: mounts to be D:, either with umount/mount or
>   DJ> with mount -f
>
>Ok, after fiddling with this for a while, I finally got his new mount
>table to look the same, except the "e:"s changed to "d:".  That looks
>correct.
>
>I see two odd symptoms on this new PC, however, which are probably
>related.  On my PC, when I do "ls /usr", it gives me a valid listing
>of what's in "d:/cygwin/usr".  On his PC, when I do "ls /usr", it says
>"No such file or directory".  When I list "/usr/bin" on my PC, it also
>lists fine.  When I list "/usr/bin" on his PC, it mostly is fine,
>except it says "ls: ..: No such file or directory".  What could be the
>cause of this?


Hard to tell.  Permissions?  cygcheck -s -r -v might help...





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Drive with cygwin moved from "E:" to "D:", how to fix?

[David M. Karr]

>>>>> "Larry" == Larry Hall (RFK Partners, Inc) <lhall@rfk.com> writes:
  Larry> At 04:38 PM 1/5/2001, David M. Karr wrote:
  >> >>>>> "DJ" == DJ Delorie <dj@delorie.com> writes:
  >> 
  >> >> causes some odd symptoms, although many things still work.  What is
  >> >> the easiest way to reset Cygwin to know it's installed on drive "D:"?
  >> 
  DJ> Just remount all the E: mounts to be D:, either with umount/mount or
  DJ> with mount -f
  >> 
  >> Ok, after fiddling with this for a while, I finally got his new mount
  >> table to look the same, except the "e:"s changed to "d:".  That looks
  >> correct.
  >> 
  >> I see two odd symptoms on this new PC, however, which are probably
  >> related.  On my PC, when I do "ls /usr", it gives me a valid listing
  >> of what's in "d:/cygwin/usr".  On his PC, when I do "ls /usr", it says
  >> "No such file or directory".  When I list "/usr/bin" on my PC, it also
  >> lists fine.  When I list "/usr/bin" on his PC, it mostly is fine,
  >> except it says "ls: ..: No such file or directory".  What could be the
  >> cause of this?

  Larry> Hard to tell.  Permissions?  cygcheck -s -r -v might help...

Ah.  I figured it out.  You probably would have seen it if I had
included the new mount table, which wasn't EXACTLY correct.  The mount
for "/" should have been "d:\cygwin", but I had it as "d:\".  Once I
redid that mount, I got "/usr" back.

Thanks again.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Drive with cygwin moved from "E:" to "D:", how to fix?

[Gerrit P. Haase]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<5 Jan 2001, 12:49 Uhr wars, als David M. Karr folgendes schrub:>
< Drive with cygwin moved from "E:" t >

> My colleague got a PC which was originally configured with the drive
> with most of his work (including the cygwin installation) being "E:"
> (the CD was "D:").  We realized it needed to be on "D:" to easily work
> with some scripts we have.  We had that done, but now I see that
> "mount" still thinks that Cygwin is installed on drive "E:".  This
> causes some odd symptoms, although many things still work.  What is
> the easiest way to reset Cygwin to know it's installed on drive "D:"?

Change the entries in windows registry by hand.

or:
delete /etc/setup/installed.db
delete setup.ini

run setup again, it will install all new, at the end of setup, when it
asks if there to make a link on the desktop and add to start menu, 
choose both, then setup should update the registry also.



-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8 -- QDPGP 2.61c
Comment: =^..^=

iQA/AwUBOlY0BzBeUmEooFE3EQK4sQCgj/dwVhUS2szXyHVQ4aftUh2p/AgAoNLS
0L6easogbePwv5T0JdWkEHRr
=umYR
-----END PGP SIGNATURE-----
-- 
=^..^=
Gerrit Peter Haase
ID: 0x28A05137
FP: 875C 745E 01CF 8A34 2767  BE39 305E 5261 28A0 5137

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Quick setup script "taxidermy.pl"

[Soren Andersen]

[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]

Hello,

I spent quite a bit of the recent holiday season setting up the latest Cygwin 
on several systems (one Win98, one Win95, one WinNT) since it is much 
more fun to work with now, that so much great effort has resulted in fewer 
bugs. Playing (*laziness*).

I noticed that I wanted to have a fast way to just mount every logical drive 
on each system to it's appropriate POSIX mount point ('X:' to '/x')  and 
that, being the incredibly *impatient* hacker I am, I disliked the repetitious 
nature of that task when done manually.

Since I tend to have Perl installed on every system I can get my hands on 
for even a few moments (*hubris*), I cooked up a little Perl script to make 
this automatic. What it doesn't yet do is check for existing mounts and 
`umount' them before re-mounting anything (or skip them entirely). That's 
a future To-Do refinement. This is just a rough script but I thought maybe 
somebody would want to use it especially on a brand-new Cygwin 
installation.

One problem, however: the script uses a Perl module that isn't standard: 
Win32::API. It's on CPAN and at http://dada.perl.it/#api (on that site is a 
PPM package to make it an easy install to ActivePerl -- *laziness*). But 
when I ran the script from Cygwin bash the perl process faulted (memory 
access violation I think). So, *don't run it in bash* but rather from cmd.exe 
(or command.com if you must use that brain-damaged shell*). I think it 
likely that a Win32::API compiled for a Cygwin Perl might not have this 
problem, but I don't know quite enough of these matters for that to be 
more than a speculation at this time. As a matter of fact, I would love to 
know if anyone else gets Win32::API -- a really powerful module to access 
arbitrary Win32 API calls from system DLLs -- built from source using 
Cygwin or MinGW.

I have attached the script to this message, since it is relative short.

   Best,
       soren andersen

* When you aren't using Cygwin.

P.S. "Why `taxidermy.pl'?" Aww come ON! "mounting"(as in hunting 
trophies or monster trout) -> taxidermy, get it?


[-- Attachment #2: taxidermy.pl --]
[-- Type: text/plain, Size: 1796 bytes --]

#!perl -w

# Perl program Copyright (c)2001 Soren Andersen
#     e-mail:    <libertador@flashmail.com>
#  Licensing: Perl Artistic License.
#  L/M 1/6/01 4:09 AM
#  requires Cygwin 1.1 or later, maybe -- has not been
#  tested on earlier Cygwin versions. `mount' and `cygpath'
#  must be in your PATH or fully qualified by hand-editing
#  this script.

use Win32::API;
use Getopt::Std;
use strict;

use vars qw[ $opt_n $opt_f $opt_t $srt ];
sub DrivesInUse;

#  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#  Options:
#      -n		dry-run only
#      -f		mount floppy drives too
#      -t		just see existing mount points and exit

 getopts( 'nft' );   $srt = 0;

#  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 if ($opt_t)   {
	 my $rcd = system("mount");
	 exit 0;
 }
my $floppies = ($opt_f)? '0' : '[a-b]';
my $cygprfx  = join q[], grep( /\/[a-z]+/i,
         `mount --show-cygdrive-prefixes` );
chomp $cygprfx;
$cygprfx =~s@^(/[a-z]+).+@$1@;
my $cygdrive = `cygpath -paw $cygprfx`;
chomp $cygdrive;
( $cygdrive =~s@^([A-Z]) \: .*@$1@xi ) or die qq[Careful, need good `cygdrive'.\n];

 for (DrivesInUse()) {
  next if /(?:$cygdrive | $floppies)/xi;
  printf(qq[  %1.3s:  mounting to %2.4s\n], $_, q[/]. lc);
 ( $srt = system( "mount -b -s -f", $_ .":","/". lc ) ) unless $opt_n;
  warn qq[\n Trouble making the mounted drive with $_ - ] .
  qq[ret code not zero: $srt\n $!] if $srt;
 }


 # from "Win32::DriveInfo.pm ver 0.03" by Mike Blazer
#===========================
sub DrivesInUse   {
#===========================
no strict 'subs';
   my (@dr, $i);
   my $h = new Win32::API("kernel32", "GetLogicalDrives", [], N);
   return undef unless $h =~/Win32::API/i;
   my $bitmask = $h->Call();
    for $i(0..25) {
       push (@dr, (A..Z)[$i]) if $bitmask & 2**$i;
    }
   return @dr;
}

NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

If I've missed this in the FAQ, user's manual, or (poorly searchable)
archives, please point me to what I've missed.  

In a shell buffer in NTEmacs configured per the shell-setup instructions 
in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 , 
control-C doesn't seem to work.

That is, typing two control-C's in Emacs (to send a control-C to bash) 
doesn't kill a long-running command (e.g., like "du /" or "sleep 10").  

Emacs does seem to flash the window title bar, but I can't tell what it's 
trying to indicate.  Does this seem to be an NTEmacs/CygWin interaction
problem, or just an NTEmacs problem (not for the CygWin list)?

Is control-C still supported in CygWin and between NTEmacs and CygWin?  (I 
just upgraded from CygWin B20 (or so), and not yet used to how things work
now.)

Thanks,
Daniel

-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[David M. Karr]

>>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:

  Daniel> If I've missed this in the FAQ, user's manual, or (poorly searchable)
  Daniel> archives, please point me to what I've missed.  

  Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions 
  Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 , 
  Daniel> control-C doesn't seem to work.

  Daniel> That is, typing two control-C's in Emacs (to send a control-C to bash) 
  Daniel> doesn't kill a long-running command (e.g., like "du /" or "sleep 10").  

  Daniel> Emacs does seem to flash the window title bar, but I can't tell what it's 
  Daniel> trying to indicate.  Does this seem to be an NTEmacs/CygWin interaction
  Daniel> problem, or just an NTEmacs problem (not for the CygWin list)?

  Daniel> Is control-C still supported in CygWin and between NTEmacs and CygWin?  (I 
  Daniel> just upgraded from CygWin B20 (or so), and not yet used to how things work
  Daniel> now.)

This bites me several times a day.  It is a known problem, but I don't
know what the status on a fix is.  I will be very glad to see it.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

"David M. Karr" wrote:
> 
> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
> 
...> 
>   Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
>   Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
>   Daniel> control-C doesn't seem to work.
...
> This bites me several times a day.  It is a known problem...

Do you mean it's a known problem that crops up (for some people), or that
it simply doesn't work at all (for anyone combining Emacs and CygWin)?

Thanks,
Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[David M. Karr]

>>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
  Daniel> "David M. Karr" wrote:
  >> 
  >> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
  >> 
  ...> 
  Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
  Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
  Daniel> control-C doesn't seem to work.
  Daniel> ...
  >> This bites me several times a day.  It is a known problem...

  Daniel> Do you mean it's a known problem that crops up (for some people), or that
  Daniel> it simply doesn't work at all (for anyone combining Emacs and CygWin)?

I don't know the full answer to that.  For me, certain shell processes
will die with ^C, some will not.  I can kill "java", but I can't kill
"tail -f" or "perl" (I have to use Task Manager).  I have seen other
people report this.

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Larry Hall (RFK Partners, Inc)]

At 02:51 PM 1/12/2001, David M. Karr wrote:
> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
>   Daniel> "David M. Karr" wrote:
>   >> 
>   >> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
>   >> 
>   ...> 
>   Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
>   Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
>   Daniel> control-C doesn't seem to work.
>   Daniel> ...
>   >> This bites me several times a day.  It is a known problem...
>
>   Daniel> Do you mean it's a known problem that crops up (for some people), or that
>   Daniel> it simply doesn't work at all (for anyone combining Emacs and CygWin)?
>
>I don't know the full answer to that.  For me, certain shell processes
>will die with ^C, some will not.  I can kill "java", but I can't kill
>"tail -f" or "perl" (I have to use Task Manager).  I have seen other
>people report this.



Recently?  Daniel's was the first report of this I've heard in months at
least (longer than that most likely but I tend to be conservative when it
comes to my memory).  I might be wrong but I don't think this is a known
problem and its certainly something that I don't see.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[David M. Karr]

>>>>> "Larry" == Larry Hall (RFK Partners, Inc) <lhall@rfk.com> writes:
  Larry> At 02:51 PM 1/12/2001, David M. Karr wrote:
  >> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
  Daniel> "David M. Karr" wrote:
  >> >> 
  >> >> >>>>> "Daniel" == Daniel Barclay <Daniel.Barclay@digitalfocus.com> writes:
  >> >> 
  ...> 
  Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
  Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
  Daniel> control-C doesn't seem to work.
  Daniel> ...
  >> >> This bites me several times a day.  It is a known problem...
  >> 
  Daniel> Do you mean it's a known problem that crops up (for some people), or that
  Daniel> it simply doesn't work at all (for anyone combining Emacs and CygWin)?
  >> 
  >> I don't know the full answer to that.  For me, certain shell processes
  >> will die with ^C, some will not.  I can kill "java", but I can't kill
  >> "tail -f" or "perl" (I have to use Task Manager).  I have seen other
  >> people report this.

  Larry> Recently?  Daniel's was the first report of this I've heard in months at
  Larry> least (longer than that most likely but I tend to be conservative when it
  Larry> comes to my memory).  I might be wrong but I don't think this is a known
  Larry> problem and its certainly something that I don't see.

Earnie Boyd indicated on 9/26 it was "fixed in snapshots", but I've
never seen any mention of a released fix for it.  I recently upgraded
my cygwin (1-2 weeks ago), so if the fix was there, I should have it
(but I don't).

-- 
===================================================================
David M. Karr     ; w:(425)487-8312     ; TCSI & Best Consulting
dkarr@tcsi.com    ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

"David M. Karr" wrote:
> 
> >>>>> "Larry" == Larry Hall (RFK Partners, Inc) <lhall@rfk.com> writes:
...
> Earnie Boyd indicated on 9/26 it was "fixed in snapshots", but I've
> never seen any mention of a released fix for it.  I recently upgraded
> my cygwin (1-2 weeks ago), so if the fix was there, I should have it
> (but I don't).

I just upgraded yesterday or Wednesday, from the ftp.sunsite.utk.edu mirror
(and the latest Emacs as of yesterday or Wednesday).

Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Larry Hall (RFK Partners, Inc)]

At 03:40 PM 1/12/2001, David M. Karr wrote:
>   >> I don't know the full answer to that.  For me, certain shell processes
>   >> will die with ^C, some will not.  I can kill "java", but I can't kill
>   >> "tail -f" or "perl" (I have to use Task Manager).  I have seen other
>   >> people report this.
>
>   Larry> Recently?  Daniel's was the first report of this I've heard in months at
>   Larry> least (longer than that most likely but I tend to be conservative when it
>   Larry> comes to my memory).  I might be wrong but I don't think this is a known
>   Larry> problem and its certainly something that I don't see.
>
>Earnie Boyd indicated on 9/26 it was "fixed in snapshots", but I've
>never seen any mention of a released fix for it.  I recently upgraded
>my cygwin (1-2 weeks ago), so if the fix was there, I should have it
>(but I don't).


Hm, I don't know why you have this problem but I can say that you have the
fix Earnie was referring to.  Anything in the nightly snapshots as of 9/26
would be in the current 1.1.7 "release", if not the 1.1.6 and 1.1.5 
"releases".  So it may be related but the problem is certainly different.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

"David M. Karr" wrote:
> 
....
> I don't know the full answer to that.  For me, certain shell processes
> will die with ^C, some will not.  I can kill "java", but I can't kill
> "tail -f" or "perl" (I have to use Task Manager).  I have seen other
> people report this.

Hmm.  I think I've seen Java behave differently, but in the opposite
direction.  On my _old_ setup (Emacs ? with CygWin 20 or so), java (Sun's) 
would sometimes print out some status dump when I tried a control-C.  
I think Java specifically catches an alternate signal (SIGQUIT? on Unix,
something else on Windows) to do that.

Maybe Emacs and/or CygWin are sending different signals at different 
times or under different configurations, or processes are vulnerable
to different signals under different conditions.


AAAAGGGGHHHH!!   Reinstalling a machine's worth of software is bad
enough without failures between critical areas (for me) like Emacs and 
Unix commands.


Could someone who has Emacs C-c C-c working working post information 
about your configuration OS version, NTEmacs version, relevant .emacs 
contents, whatever version information now characterizes CygWin, relevant 
cygwin.bat contents, environment variables, etc.)?

Here are my statistics:

- Windows NT 4.0, service pack 6a

- NT Emacs version:
  "GNU Emacs 20.7.1 (i386-*-nt4.0.1381) of Tue Jun 13 2000 on buffy"

- HOME:
  bash-2.04$ echo $HOME
  /c/Daniel

- $HOME/.emacs (excerpts):
  
  ...
  (setq exec-path (cons "C:/tools/cygwin/bin" exec-path))
  (setenv "PATH" (concat "C:\\tools\\cygwin\\bin;" (getenv "PATH")))
  
  ;;TRYING:
  (setenv "CYGWIN" (concat "tty " (getenv "CYGWIN")))

  (setq process-coding-system-alist '(("bash" . undecided-unix)))
  (setq w32-quote-process-args ?\")
  (setq shell-file-name "bash")
  (setenv "SHELL" shell-file-name) 
  (setq explicit-shell-file-name shell-file-name) 

  (add-hook 'comint-output-filter-functions
            'comint-strip-ctrl-m)
  ...
  
- C:/tools/cygwin/cygwin.bat:
  @echo off
  
  set CYGWIN=tty
  
  C:
  chdir \tools\cygwin\bin
  
  bash --login -i

- cygcheck:

  $ cygcheck  -s
  
  Cygnus Win95/NT Configuration Diagnostics
  Current System Time: Fri Jan 12 16:03:28 2001
  
  WinNT Ver 4.0 build 1381 Service Pack 6
  
  Path:	/usr/bin
  	/c/WINNT/system32
  	/c/WINNT
  
  SysDir: C:\WINNT\System32
  WinDir: C:\WINNT
  
  PWD = `/c/tools/emacs-20.7/bin'
  CYGWIN = `tty '
  HOME = `/c/Daniel'
  
  Use `-r' to scan registry
  
  a:  fd           N/A    N/A                    
  c:  hd  NTFS    4094Mb  53% CP CS UN PA FC     C
  d:  hd  NTFS    1592Mb  99% CP CS UN PA FC     D
  e:  hd  NTFS    4094Mb  85% CP CS UN PA FC     E
  f:  cd           N/A    N/A                    
  
  C:\tools\cygwin\bin  /usr/bin  system  textmode
  C:\tools\cygwin\lib  /usr/lib  system  textmode
  C:\tools\cygwin  /        system  textmode
  C:    /c       user    textmode
  D:    /d       user    textmode
  E:    /e       user    textmode
  
  Found: C:\tools\cygwin\bin\bash.exe
  Found: C:\tools\cygwin\bin\cat.exe
  Found: C:\tools\cygwin\bin\cpp.exe
  Found: C:\tools\cygwin\bin\find.exe
  Found: C:\tools\cygwin\bin\gcc.exe
  Found: C:\tools\cygwin\bin\gdb.exe
  Found: C:\tools\cygwin\bin\ld.exe
  Found: C:\tools\cygwin\bin\ls.exe
  Found: C:\tools\cygwin\bin\make.exe
  Found: C:\tools\cygwin\bin\sh.exe
  
     56k 2000/12/03 C:\tools\cygwin\bin\cygbz21.0.dll
     45k 2000/12/07 C:\tools\cygwin\bin\cygform5.dll
     18k 2000/10/23 C:\tools\cygwin\bin\cyggdbm.dll
     17k 2001/01/07 C:\tools\cygwin\bin\cyghistory4.dll
     14k 2000/10/23 C:\tools\cygwin\bin\cygintl.dll
     81k 2000/12/05 C:\tools\cygwin\bin\cygitcl30.dll
     35k 2000/12/05 C:\tools\cygwin\bin\cygitk30.dll
     45k 2000/10/22 C:\tools\cygwin\bin\cygjbig1.dll
    119k 2000/10/23 C:\tools\cygwin\bin\cygjpeg6b.dll
     26k 2000/12/07 C:\tools\cygwin\bin\cygmenu5.dll
    159k 2000/12/07 C:\tools\cygwin\bin\cygncurses++5.dll
    225k 2000/12/07 C:\tools\cygwin\bin\cygncurses5.dll
     15k 2000/12/07 C:\tools\cygwin\bin\cygpanel5.dll
    162k 2000/10/23 C:\tools\cygwin\bin\cygpng2.dll
    108k 2001/01/07 C:\tools\cygwin\bin\cygreadline4.dll
    390k 2000/12/05 C:\tools\cygwin\bin\cygtcl80.dll
      5k 2000/12/05 C:\tools\cygwin\bin\cygtclpip80.dll
     10k 2000/12/05 C:\tools\cygwin\bin\cygtclreg80.dll
    243k 2000/10/23 C:\tools\cygwin\bin\cygtiff3.dll
    623k 2000/12/05 C:\tools\cygwin\bin\cygtk80.dll
     41k 2000/11/20 C:\tools\cygwin\bin\cygXpm-noX4.dll
     45k 2000/11/20 C:\tools\cygwin\bin\cygXpm-X4.dll
     49k 2000/10/23 C:\tools\cygwin\bin\cygz.dll
    611k 2000/12/25 C:\tools\cygwin\bin\cygwin1.dll
      Cygwin DLL version info:
          dll major: 1001
          dll minor: 7
          dll epoch: 19
          dll bad signal mask: 19005
          dll old termios: 5
          dll malloc env: 28
          api major: 0
          api minor: 31
          shared data: 3
          dll identifier: cygwin1
          mount registry: 2
          cygnus registry name: Cygnus Solutions
          cygwin registry name: Cygwin
          program options name: Program Options
          cygwin mount registry name: mounts v2
          cygdrive flags: cygdrive flags
          cygdrive prefix: cygdrive prefix
          cygdrive default prefix: 
          build date: Mon Dec 25 12:39:48 EST 2000
          shared id: cygwin1S3
  
  Use -h to see help about each section
  $ 




Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Ehud Karni]

On Fri, 12 Jan 2001 14:46:36 -0500, Daniel Barclay <Daniel.Barclay@digitalfocus.com> wrote:
> 
> "David M. Karr" wrote:
> > 
> >   Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
> >   Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
> >   Daniel> control-C doesn't seem to work.
> ...
> > This bites me several times a day.  It is a known problem...
> 
> Do you mean it's a known problem that crops up (for some people), or that
> it simply doesn't work at all (for anyone combining Emacs and CygWin)?

I think he meant it is a general problem for everyone. The base of this
is that the emacs shell buffer is not a tty. You can check it by doing
`stty', you'll get: "stty: standard input: Not a character device".

And hence, it is not a tty ==> it will not generate SIGINT for ^C.

Ehud.


-- 
 @@@@@@ @@@ @@@@@@ @    @   Ehud Karni  Simon & Wiesel  Insurance agency
     @    @      @  @@  @   Tel: +972-3-6212-757    Fax: +972-3-6292-544
     @    @ @    @ @  @@    (USA)  Fax  and  voice  mail:  1-815-5509341
     @    @ @    @ @    @        Better     Safe     Than     Sorry
 http://www.simonwiesel.co.il    mailto:ehud@unix.simonwiesel.co.il

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Larry Hall (RFK Partners, Inc)]

At 04:25 PM 1/12/2001, Ehud Karni wrote:
>On Fri, 12 Jan 2001 14:46:36 -0500, Daniel Barclay <Daniel.Barclay@digitalfocus.com> wrote:
> > 
> > "David M. Karr" wrote:
> > > 
> > >   Daniel> In a shell buffer in NTEmacs configured per the shell-setup instructions
> > >   Daniel> in the CygWin FAQ at http://sources.redhat.com/cygwin/faq/faq.html#SEC5 ,
> > >   Daniel> control-C doesn't seem to work.
> > ...
> > > This bites me several times a day.  It is a known problem...
> > 
> > Do you mean it's a known problem that crops up (for some people), or that
> > it simply doesn't work at all (for anyone combining Emacs and CygWin)?
>
>I think he meant it is a general problem for everyone. The base of this
>is that the emacs shell buffer is not a tty. You can check it by doing
>`stty', you'll get: "stty: standard input: Not a character device".
>
>And hence, it is not a tty ==> it will not generate SIGINT for ^C.
>
>Ehud.



Forgive me for coming late to the party.  I didn't digest that this 
conversation was about NTEmacs (i.e. the Windows port).  I'll leave 
aside whether or not ^C should work in this context.  I really don't
know whether it should/would/ever did.  I don't use Emacs.  However, 
I can say you'll have better luck with a Cygwin version of Emacs, like
XEmacs.  You'll find Cygwin applications work much better with other 
Cygwin applications, especially in areas of detail like this.

YMMV.  Void where prohibited.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

"Larry Hall (RFK Partners, Inc)" wrote:
> 
...
> ... However,
> I can say you'll have better luck with a Cygwin version of Emacs, like
> XEmacs.  You'll find Cygwin applications work much better with other
> Cygwin applications, especially in areas of detail like this.

How different is XEmacs from GNU/NTEmacs?  

(I don't do much (any) Lisp programming, so I guess I'm just asking about 
default configuration and about compatibility of add-ons like JDE.)

Thanks,
Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Larry Hall (RFK Partners, Inc)]

At 02:15 PM 1/16/2001, Daniel Barclay wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
> > 
>...
> > ... However,
> > I can say you'll have better luck with a Cygwin version of Emacs, like
> > XEmacs.  You'll find Cygwin applications work much better with other
> > Cygwin applications, especially in areas of detail like this.
>
>How different is XEmacs from GNU/NTEmacs?  
>
>(I don't do much (any) Lisp programming, so I guess I'm just asking about 
>default configuration and about compatibility of add-ons like JDE.)



Sorry, I was a little unclear.  AFAIK, there is a Cygwin version of XEmacs
but there isn't one for NTEmacs.  My main point was that signal functionality
can be handled by Cygwin (and is) or by the O/S.  However, the signal coming
from a Win32 app doesn't get the same response out of Cygwin as one coming
from a Cygwin app.  If you have problems in this area, your best bet is to 
use Cygwin-enabled versions of apps when available.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Daniel Barclay]

"Larry Hall (RFK Partners, Inc)" wrote:
> 
> At 02:15 PM 1/16/2001, Daniel Barclay wrote:
> >"Larry Hall (RFK Partners, Inc)" wrote:
> > >
> >...
> > > ... However,
> > > I can say you'll have better luck with a Cygwin version of Emacs, like
> > > XEmacs.  You'll find Cygwin applications work much better with other
> > > Cygwin applications, especially in areas of detail like this.
> >
> >How different is XEmacs from GNU/NTEmacs?
> >
> >(I don't do much (any) Lisp programming, so I guess I'm just asking about
> >default configuration and about compatibility of add-ons like JDE.)
> 
> Sorry, I was a little unclear.  AFAIK, there is a Cygwin version of XEmacs
> but there isn't one for NTEmacs.  My main point was that signal functionality
> can be handled by Cygwin (and is) or by the O/S.  However, the signal coming
> from a Win32 app doesn't get the same response out of Cygwin as one coming
> from a Cygwin app.  If you have problems in this area, your best bet is to
> use Cygwin-enabled versions of apps when available.

I just meant how different is XEmacs from NTEmacs to the user?  If I switch 
from NTEmacs (which I'm used to) to XEmacs (which I don't know), how big a 
change is that likely to been (from the Emacs user point of view)?

Daniel


-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Larry Hall (RFK Partners, Inc)]

At 11:22 AM 1/18/2001, Daniel Barclay wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
> > 
> > At 02:15 PM 1/16/2001, Daniel Barclay wrote:
> > >"Larry Hall (RFK Partners, Inc)" wrote:
> > > >
> > >...
> > > > ... However,
> > > > I can say you'll have better luck with a Cygwin version of Emacs, like
> > > > XEmacs.  You'll find Cygwin applications work much better with other
> > > > Cygwin applications, especially in areas of detail like this.
> > >
> > >How different is XEmacs from GNU/NTEmacs?
> > >
> > >(I don't do much (any) Lisp programming, so I guess I'm just asking about
> > >default configuration and about compatibility of add-ons like JDE.)
> > 
> > Sorry, I was a little unclear.  AFAIK, there is a Cygwin version of XEmacs
> > but there isn't one for NTEmacs.  My main point was that signal functionality
> > can be handled by Cygwin (and is) or by the O/S.  However, the signal coming
> > from a Win32 app doesn't get the same response out of Cygwin as one coming
> > from a Cygwin app.  If you have problems in this area, your best bet is to
> > use Cygwin-enabled versions of apps when available.
>
>I just meant how different is XEmacs from NTEmacs to the user?  If I switch 
>from NTEmacs (which I'm used to) to XEmacs (which I don't know), how big a 
>change is that likely to been (from the Emacs user point of view)?


I, of course, am not qualified to answer that question since I don't use
Emacs at all.  Others might be able to help.  You may be better off asking
this question on some Emacs list though...



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: NTEmacs shell/CygWin: should control-C work?

[Dr. Volker Zell]

>>>>> "RFK" == RFK Partners, Inc <Larry> writes:

    RFK> At 11:22 AM 1/18/2001, Daniel Barclay wrote:
    >> "Larry Hall (RFK Partners, Inc)" wrote:
    >> > 
    >> > At 02:15 PM 1/16/2001, Daniel Barclay wrote:
    >> > >"Larry Hall (RFK Partners, Inc)" wrote:
    >> > > >
    >> > >...
    >> > > > ... However,
    >> > > > I can say you'll have better luck with a Cygwin version of Emacs, like
    >> > > > XEmacs.  You'll find Cygwin applications work much better with other
    >> > > > Cygwin applications, especially in areas of detail like this.
    >> > >
    >> > >How different is XEmacs from GNU/NTEmacs?
    >> > >
    >> > >(I don't do much (any) Lisp programming, so I guess I'm just asking about
    >> > >default configuration and about compatibility of add-ons like JDE.)
    >> > 
    >> > Sorry, I was a little unclear.  AFAIK, there is a Cygwin version of XEmacs
    >> > but there isn't one for NTEmacs.  My main point was that signal functionality
    >> > can be handled by Cygwin (and is) or by the O/S.  However, the signal coming
    >> > from a Win32 app doesn't get the same response out of Cygwin as one coming
    >> > from a Cygwin app.  If you have problems in this area, your best bet is to
    >> > use Cygwin-enabled versions of apps when available.
    >> 
    >> I just meant how different is XEmacs from NTEmacs to the user?  If I switch 
    >> from NTEmacs (which I'm used to) to XEmacs (which I don't know), how big a 
    >> change is that likely to been (from the Emacs user point of view)?


    RFK> I, of course, am not qualified to answer that question since I don't use
    RFK> Emacs at all.  Others might be able to help.  You may be better off asking
    RFK> this question on some Emacs list though...

I've done the switch a long time ago. NO big deal.
Just switch of the toolbar and it feels like Emacs.

Ciao
  Volker


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: problems with less

[Michael Hirmke]

John S Cooper [John.Cooper@eu.citrix.com] wrote:

[...]
> > > When I `less c:/etc/termcap', the top 3 lines of the file are not shown,
> > > even after typing `g' (start of file).  However, if I type 'G' (end of
> > > file) followed by 'g' then it is shown, although searching for strings
> > > doesn't display the highlighted matches (they seem to be off the top of
> > > the screen). It's pretty much unusable really.
[...]
>
>Hmm.  I am using Win2K if that makes any difference.  It seems that the
>display is always messed up for me when the file being viewed has lines that

Same here!
- W2K German
- CYGWIN_NT-5.0 MIKE 1.1.1(0.19/3/2) 2000-04-24 20:21:10 i686 unknown
- TERM=linux

[...]
>
>    --- John

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problems with less

[John S Cooper]

I think the display problems I was having with `less' disappear when I do the
following:

  1. Set TERM=cygwin rather than TERM=linux.
  2. Don't use `less -r' as an alias for `less'.

Perhaps this is something for a README/FAQ?

    --- John


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problems with less

[Chris Faylor]

On Tue, May 09, 2000 at 03:38:21PM +0100, John S Cooper wrote:
>
>I think the display problems I was having with `less' disappear when I do the
>following:
>
>  1. Set TERM=cygwin rather than TERM=linux.
>  2. Don't use `less -r' as an alias for `less'.
>
>Perhaps this is something for a README/FAQ?

So, if you don't go out of your way to use less in a non-standard way, it
works fine.  That doesn't seem like FAQ material to me.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: problems with less

[Bob McGowan]

Chris Faylor wrote:
> 
> On Tue, May 09, 2000 at 03:38:21PM +0100, John S Cooper wrote:
> >
> >I think the display problems I was having with `less' disappear when I do the
> >following:
> >
> >  1. Set TERM=cygwin rather than TERM=linux.
> >  2. Don't use `less -r' as an alias for `less'.
> >
> >Perhaps this is something for a README/FAQ?
> 
> So, if you don't go out of your way to use less in a non-standard way, it
> works fine.  That doesn't seem like FAQ material to me.

The man page for 'less' says '-r' causes the program to output ASCII
control characters found in a file as the control character rather than
a symbol sequence like '^A', etc.  This is a standard documented
feature.  What was missing in this case was an understanding of what
this means to the terminal emulator.  For instance, if a <CR> (^R) was
embedded in a line, the remainder of the line would overwrite its
beginning.  If there is a form feed (^L if I remember correctly), the
screen might be cleared (depending on the TERM type, of course).  And so
on.

I agree that this is not a FAQ item.  The feature is already
documented.  It just requires a little analysis and thought, to
understand the potential consequences.

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

[PB] "no acceptable ld" : cywin32 pb, way to handle win path ?

[Sebastien Barre]

Here are some excerpts of a problem discussed in the cywin32 mailing list.
I thought it might be interesting for the automake people too (this message
is also crossposted CC: to the cywin32 list for information).

http://www.cygnus.com/ml/gnu-win32/
http://sourceware.cygnus.com/ml/cygwin/1999-02/msg00702.html

It seems related to the way configure script handles path (many of use
encoutered the pb with different configure scripts) :

 Alex <alexl@i-france.com> :

>i tried to compile CILK ( http://supertech.lcs.mit.edu/cilk/ )
>and i got this error message:
>
>checking for ld used by GCC... no
>configure: error: no acceptable ld found in $PATH
>
>though ld.exe is in the bin directory, what can i do to solve this
>problem ?


Tolj <tolj@uni-duesseldorf.de> :

>check out the configure script itself where the test is performed, i.e.
>search for "checking for ld used by" and you may see that you'll need to
>add Win32 path style to match certain conditions within the configure
>script so ld is recognized.
>
>At least for some configure scripts this has been the problem for not
>recognizing ld in my experience.


Julian Kinraid <jkinraid@clear.net.nz>

>I had the same problem, but if you just set the LD enviroment variable,
>you mightn't need to change the configure script -
>
>export LD=/cygwin/cygwin-b20/H-i586-cygwin32/bin/ld.exe
>
>Just make sure the path is correct.


"Suhaib M. Siddiqi" <Ssiddiqi@InspirePharm.Com> :

>>export LD=/cygwin/cygwin-b20/H-i586-cygwin32/bin/ld.exe
>>
>>Just make sure the path is correct.
>>
>
>Theoretically it supposed to work.  But; it does not awlays by doing
>export... before using configure script.  Many Configure scripts apprantly
>ignore it and seach for LD="$..." whatever.  Hardcoding the ld.exe path in
>configure works at least always in my hands.


"Suhaib M. Siddiqi" <Ssiddiqi@InspirePharm.Com> :

>This problem also occurs with LessTif and many other codes.  It is because
>Cygwin has a different style.
>
>I usually search the configure script for something like "LD="$...." and
>replace all those occurances with
>LD="/usr/cygwin-b20/H-i586-cywgin32/bin/ld.exe"  This hard codes the ld.exe
>path and also include at your ./configure --with-gnu-ld if this option is
>available (check with ./configure --help).  Hard coding ld.exe path in
>configure script always has worked at least in my hands.


Any help frop the automake people would be really appreciated, sorry if it
has been discussed before...

Thanks a lot


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [PB] "no acceptable ld" : cywin32 pb, way to handle win path ?

[Gary V. Vaughan]

I should have cross-posted this to the cygwin list:

	http://egcs.cygnus.com/ml/egcs/1999-02/msg00707.html

Cheers,
	Gary V. Vaughan

Sebastien Barre wrote:
> 
> Here are some excerpts of a problem discussed in the cywin32 mailing list.
> I thought it might be interesting for the automake people too (this message
> is also crossposted CC: to the cywin32 list for information).
> 
> http://www.cygnus.com/ml/gnu-win32/
> http://sourceware.cygnus.com/ml/cygwin/1999-02/msg00702.html
> 
> It seems related to the way configure script handles path (many of use
> encoutered the pb with different configure scripts) :

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [PB] "no acceptable ld" : cywin32 pb, way to handle win path ?

[Gary V. Vaughan]

I should have cross-posted this to the cygwin list:

	http://egcs.cygnus.com/ml/egcs/1999-02/msg00707.html

Cheers,
	Gary V. Vaughan

Sebastien Barre wrote:
> 
> Here are some excerpts of a problem discussed in the cywin32 mailing list.
> I thought it might be interesting for the automake people too (this message
> is also crossposted CC: to the cywin32 list for information).
> 
> http://www.cygnus.com/ml/gnu-win32/
> http://sourceware.cygnus.com/ml/cygwin/1999-02/msg00702.html
> 
> It seems related to the way configure script handles path (many of use
> encoutered the pb with different configure scripts) :

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

[PB] "no acceptable ld" : cywin32 pb, way to handle win path ?

[Sebastien Barre]

Here are some excerpts of a problem discussed in the cywin32 mailing list.
I thought it might be interesting for the automake people too (this message
is also crossposted CC: to the cywin32 list for information).

http://www.cygnus.com/ml/gnu-win32/
http://sourceware.cygnus.com/ml/cygwin/1999-02/msg00702.html

It seems related to the way configure script handles path (many of use
encoutered the pb with different configure scripts) :

 Alex <alexl@i-france.com> :

>i tried to compile CILK ( http://supertech.lcs.mit.edu/cilk/ )
>and i got this error message:
>
>checking for ld used by GCC... no
>configure: error: no acceptable ld found in $PATH
>
>though ld.exe is in the bin directory, what can i do to solve this
>problem ?


Tolj <tolj@uni-duesseldorf.de> :

>check out the configure script itself where the test is performed, i.e.
>search for "checking for ld used by" and you may see that you'll need to
>add Win32 path style to match certain conditions within the configure
>script so ld is recognized.
>
>At least for some configure scripts this has been the problem for not
>recognizing ld in my experience.


Julian Kinraid <jkinraid@clear.net.nz>

>I had the same problem, but if you just set the LD enviroment variable,
>you mightn't need to change the configure script -
>
>export LD=/cygwin/cygwin-b20/H-i586-cygwin32/bin/ld.exe
>
>Just make sure the path is correct.


"Suhaib M. Siddiqi" <Ssiddiqi@InspirePharm.Com> :

>>export LD=/cygwin/cygwin-b20/H-i586-cygwin32/bin/ld.exe
>>
>>Just make sure the path is correct.
>>
>
>Theoretically it supposed to work.  But; it does not awlays by doing
>export... before using configure script.  Many Configure scripts apprantly
>ignore it and seach for LD="$..." whatever.  Hardcoding the ld.exe path in
>configure works at least always in my hands.


"Suhaib M. Siddiqi" <Ssiddiqi@InspirePharm.Com> :

>This problem also occurs with LessTif and many other codes.  It is because
>Cygwin has a different style.
>
>I usually search the configure script for something like "LD="$...." and
>replace all those occurances with
>LD="/usr/cygwin-b20/H-i586-cywgin32/bin/ld.exe"  This hard codes the ld.exe
>path and also include at your ./configure --with-gnu-ld if this option is
>available (check with ./configure --help).  Hard coding ld.exe path in
>configure script always has worked at least in my hands.


Any help frop the automake people would be really appreciated, sorry if it
has been discussed before...

Thanks a lot


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

strange mount behaviour...

[Sebastien Barre]

Well, sorry to post another naive question, but here is a sequence of
reproducible commands that lead to something very obscure to me : mounting
D: (the disk where cygwin and my root is located) seems to invalid some
internal behaviours (well, let's say some illogical things appear :)

Here it is. I just installed B20.1,

> GNUWIN32=d:/devel/gnuwin32; export GNUWIN32
> CYGROOT=${GNUWIN32}/cygwin-b20; export CYGROOT

- create some directories for a kind of filesystem

> cd ${GNUWIN32}
> mkdir root
> cd root
> mkdir tmp etc d

- mount

> umount /
> mount ${GNUWIN32}/root /
> mount D:/temp /tmp
> mount ${CYGROOT}/etc /etc

No pb until now, for example, let's have a look at /etc (two times)  :

> cd /
> ls
d/ etc/ tmp/
> ls etc
termcap
> ls /etc
termcap

Now here is the funny part :

> mount D: /d
> ls etc
> ls d 

!! nothing !!

> ls /etc
termcap
> cd /etc
> ls
termcap

!! now here they are, '/etc' works, 'etc' does not !!

> cd ..
> ls d
> ls /d
autoexec.bat config.sys
... etc.

Could anyone explain me why mounting D: ou D:/ ou d:/ to /d produce these
artefacts ? Doing the same thing with C: ou E: will NOT cause any problem.
Is it impossible to mount the drive where cygwin is located ? Installing
coolview did not help too. As well as binary mount.

Thanks


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Levon Saldamli]

Sebastien Barre <Sebastien.Barre@utc.fr> writes:

> > mount D: /d
> > ls etc
> > ls d 
>
> !! nothing !!
> 
> > ls /etc
> termcap

It is a good idea to check (and paste it with the other things) what
your pwd is here. Just to be sure :)

> > cd /etc
> > ls
> termcap


/Levon Saldamli.




> Well, sorry to post another naive question, but here is a sequence of
> reproducible commands that lead to something very obscure to me : mounting
> D: (the disk where cygwin and my root is located) seems to invalid some
> internal behaviours (well, let's say some illogical things appear :)
> 
> Here it is. I just installed B20.1,
> 
> > GNUWIN32=d:/devel/gnuwin32; export GNUWIN32
> > CYGROOT=${GNUWIN32}/cygwin-b20; export CYGROOT
> 
> - create some directories for a kind of filesystem
> 
> > cd ${GNUWIN32}
> > mkdir root
> > cd root
> > mkdir tmp etc d
> 
> - mount
> 
> > umount /
> > mount ${GNUWIN32}/root /
> > mount D:/temp /tmp
> > mount ${CYGROOT}/etc /etc
> 
> No pb until now, for example, let's have a look at /etc (two times)  :
> 
> > cd /
> > ls
> d/ etc/ tmp/
> > ls etc
> termcap
> > ls /etc
> termcap
> 
> Now here is the funny part :
> 
> > mount D: /d
> > ls etc
> > ls d 
> 
> !! nothing !!
> 
> > ls /etc
> termcap
> > cd /etc
> > ls
> termcap
> 
> !! now here they are, '/etc' works, 'etc' does not !!
> 
> > cd ..
> > ls d
> > ls /d
> autoexec.bat config.sys
> ... etc.
> 
> Could anyone explain me why mounting D: ou D:/ ou d:/ to /d produce these
> artefacts ? Doing the same thing with C: ou E: will NOT cause any problem.
> Is it impossible to mount the drive where cygwin is located ? Installing
> coolview did not help too. As well as binary mount.
> 
> Thanks
> 
> 
> ______________________________________________________________
> Sebastien Barre                  http://www.hds.utc.fr/~barre/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 

-- 
/Levon Saldamli

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Sebastien Barre]

At 07:20 24/02/99 +0100, Levon Saldamli wrote:
>Sebastien Barre <Sebastien.Barre@utc.fr> writes:

>> > mount D: /d
>> > ls etc
>> > ls d 
>>
>> !! nothing !!
>> 
>> > ls /etc
>> termcap

>It is a good idea to check (and paste it with the other things) what
>your pwd is here. Just to be sure :)

at that point :

> pwd
/
> mount

Device           Directory           Type        Flags
D:\temp          /tmp                native      text!=binary
d:\devel\gnuwin32\cygwin-b20\etc /etc                native      text!=binary
D:               /d                  native      text!=binary
D:\devel\gnuwin32\root /                   native      text!=binary


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Sebastien Barre]

At 07:20 24/02/99 +0100, Levon Saldamli wrote:
>Sebastien Barre <Sebastien.Barre@utc.fr> writes:

>> > mount D: /d
>> > ls etc
>> > ls d 
>>
>> !! nothing !!
>> 
>> > ls /etc
>> termcap

>It is a good idea to check (and paste it with the other things) what
>your pwd is here. Just to be sure :)

at that point :

> pwd
/
> mount

Device           Directory           Type        Flags
D:\temp          /tmp                native      text!=binary
d:\devel\gnuwin32\cygwin-b20\etc /etc                native      text!=binary
D:               /d                  native      text!=binary
D:\devel\gnuwin32\root /                   native      text!=binary


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Levon Saldamli]

Sebastien Barre <Sebastien.Barre@utc.fr> writes:

> > mount D: /d
> > ls etc
> > ls d 
>
> !! nothing !!
> 
> > ls /etc
> termcap

It is a good idea to check (and paste it with the other things) what
your pwd is here. Just to be sure :)

> > cd /etc
> > ls
> termcap


/Levon Saldamli.




> Well, sorry to post another naive question, but here is a sequence of
> reproducible commands that lead to something very obscure to me : mounting
> D: (the disk where cygwin and my root is located) seems to invalid some
> internal behaviours (well, let's say some illogical things appear :)
> 
> Here it is. I just installed B20.1,
> 
> > GNUWIN32=d:/devel/gnuwin32; export GNUWIN32
> > CYGROOT=${GNUWIN32}/cygwin-b20; export CYGROOT
> 
> - create some directories for a kind of filesystem
> 
> > cd ${GNUWIN32}
> > mkdir root
> > cd root
> > mkdir tmp etc d
> 
> - mount
> 
> > umount /
> > mount ${GNUWIN32}/root /
> > mount D:/temp /tmp
> > mount ${CYGROOT}/etc /etc
> 
> No pb until now, for example, let's have a look at /etc (two times)  :
> 
> > cd /
> > ls
> d/ etc/ tmp/
> > ls etc
> termcap
> > ls /etc
> termcap
> 
> Now here is the funny part :
> 
> > mount D: /d
> > ls etc
> > ls d 
> 
> !! nothing !!
> 
> > ls /etc
> termcap
> > cd /etc
> > ls
> termcap
> 
> !! now here they are, '/etc' works, 'etc' does not !!
> 
> > cd ..
> > ls d
> > ls /d
> autoexec.bat config.sys
> ... etc.
> 
> Could anyone explain me why mounting D: ou D:/ ou d:/ to /d produce these
> artefacts ? Doing the same thing with C: ou E: will NOT cause any problem.
> Is it impossible to mount the drive where cygwin is located ? Installing
> coolview did not help too. As well as binary mount.
> 
> Thanks
> 
> 
> ______________________________________________________________
> Sebastien Barre                  http://www.hds.utc.fr/~barre/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 

-- 
/Levon Saldamli

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Michael Hirmke]

Sebastien Barre [Sebastien.Barre@utc.fr] wrote:

[...]
>Device           Directory           Type        Flags
>D:\temp          /tmp                native      text!=binary
>d:\devel\gnuwin32\cygwin-b20\etc /etc                native      text!=binary
>D:               /d                  native      text!=binary
>D:\devel\gnuwin32\root /                   native      text!=binary

To avoid problems, you shouldn't mount directories from the same
partition, if it isn't absolutely nescessary.
Instead use

Device                       Directory     Type        Flags
D:\devel\gnuwin32\cygwin-b20 /             native      text!=binary

and then
ln -s //d/temp /tmp

and use //d/ instead of /d

>
>
>______________________________________________________________
>Sebastien Barre                  http://www.hds.utc.fr/~barre/

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: strange mount behaviour...

[Michael Hirmke]

Sebastien Barre [Sebastien.Barre@utc.fr] wrote:

[...]
>Device           Directory           Type        Flags
>D:\temp          /tmp                native      text!=binary
>d:\devel\gnuwin32\cygwin-b20\etc /etc                native      text!=binary
>D:               /d                  native      text!=binary
>D:\devel\gnuwin32\root /                   native      text!=binary

To avoid problems, you shouldn't mount directories from the same
partition, if it isn't absolutely nescessary.
Instead use

Device                       Directory     Type        Flags
D:\devel\gnuwin32\cygwin-b20 /             native      text!=binary

and then
ln -s //d/temp /tmp

and use //d/ instead of /d

>
>
>______________________________________________________________
>Sebastien Barre                  http://www.hds.utc.fr/~barre/

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

strange mount behaviour...

[Sebastien Barre]

Well, sorry to post another naive question, but here is a sequence of
reproducible commands that lead to something very obscure to me : mounting
D: (the disk where cygwin and my root is located) seems to invalid some
internal behaviours (well, let's say some illogical things appear :)

Here it is. I just installed B20.1,

> GNUWIN32=d:/devel/gnuwin32; export GNUWIN32
> CYGROOT=${GNUWIN32}/cygwin-b20; export CYGROOT

- create some directories for a kind of filesystem

> cd ${GNUWIN32}
> mkdir root
> cd root
> mkdir tmp etc d

- mount

> umount /
> mount ${GNUWIN32}/root /
> mount D:/temp /tmp
> mount ${CYGROOT}/etc /etc

No pb until now, for example, let's have a look at /etc (two times)  :

> cd /
> ls
d/ etc/ tmp/
> ls etc
termcap
> ls /etc
termcap

Now here is the funny part :

> mount D: /d
> ls etc
> ls d 

!! nothing !!

> ls /etc
termcap
> cd /etc
> ls
termcap

!! now here they are, '/etc' works, 'etc' does not !!

> cd ..
> ls d
> ls /d
autoexec.bat config.sys
... etc.

Could anyone explain me why mounting D: ou D:/ ou d:/ to /d produce these
artefacts ? Doing the same thing with C: ou E: will NOT cause any problem.
Is it impossible to mount the drive where cygwin is located ? Installing
coolview did not help too. As well as binary mount.

Thanks


______________________________________________________________
Sebastien Barre                  http://www.hds.utc.fr/~barre/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin commands crashes after ssh login

[Christer.H.Jansson]

I have Windows NT4-SP6+different security patches box with latest 
cygwin/openssh versions.

When logging in with ssh (Yes, I have tried different clients) first of 
all id.exe crashes. After confirming Dr. Watson message on console I 
get logged in. If I try cygwin commands (id, hostname, ls, ps...) I get 
Dr. Watson crash. However I can still run echo and pwd commands.

I have tried re-installing several times. Both on NT Server and 
Workstation.

Is this a known problem? I have seen someone writing about id.exe crash 
problem before.

If I change to older version cygwin-1.1.5.7 everythings works nicely.

I can provice Dr. Watson logs if needed.

Regards,

Christer Jansson
Telia Mobile AB




--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Erdely, Michael]

I've noticed this a lot.  With Windows 2000 Pro and Server, with and without
SP1, as well (so it's not the specific version of NT/2000).  I've also
noticed this when running sshd as part of inetd (running as both a specific
account & SYSTEM) and with srvany (running as both a specific account &
SYSTEM).

So far, switching back to Cygwin DLL version 1.1.5-7 is the only solution
I've found.

One thought I had after reading
http://cygwin.com/ml/cygwin/2001-01/msg00714.html was that it may be a
problem with BASH and not with Cygwin.  So, I was wondering if anyone who
_IS_ having this problem is _NOT_ using BASH as their shell in /etc/passwd.
Also, if anyone is _NOT_ having this problem and _IS_ running BASH as their
shell in /etc/passwd.  If you fall under the previous two categories, how
are you running SSHD (SRVANY, INETD, specific account, SYSTEM, CYGWIN=ntsec,
. . .).

Mike Erdely
mailto:mike@erdelynet.com
http://mike.erdelynet.com/
SSH-L: http://mike.erdelynet.com/maillist-ssh-l.asp

----- Original Message -----
From: <Christer.H.Jansson@telia.se>
To: <cygwin@sources.redhat.com>
Cc: <Christer.H.Jansson@telia.se>
Sent: Tuesday, January 16, 2001 3:07 AM
Subject: Cygwin commands crashes after ssh login


> I have Windows NT4-SP6+different security patches box with latest
> cygwin/openssh versions.
>
> When logging in with ssh (Yes, I have tried different clients) first of
> all id.exe crashes. After confirming Dr. Watson message on console I
> get logged in. If I try cygwin commands (id, hostname, ls, ps...) I get
> Dr. Watson crash. However I can still run echo and pwd commands.
>
> I have tried re-installing several times. Both on NT Server and
> Workstation.
>
> Is this a known problem? I have seen someone writing about id.exe crash
> problem before.
>
> If I change to older version cygwin-1.1.5.7 everythings works nicely.
>
> I can provice Dr. Watson logs if needed.
>
> Regards,
>
> Christer Jansson
> Telia Mobile AB
>
>
>
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Corinna Vinschen]

On Tue, Jan 16, 2001 at 07:41:15AM -0500, Erdely, Michael wrote:
> I've noticed this a lot.  With Windows 2000 Pro and Server, with and without
> SP1, as well (so it's not the specific version of NT/2000).  I've also
> noticed this when running sshd as part of inetd (running as both a specific
> account & SYSTEM) and with srvany (running as both a specific account &
> SYSTEM).
> 
> So far, switching back to Cygwin DLL version 1.1.5-7 is the only solution
> I've found.
> 
> One thought I had after reading
> http://cygwin.com/ml/cygwin/2001-01/msg00714.html was that it may be a
> problem with BASH and not with Cygwin.  So, I was wondering if anyone who
> _IS_ having this problem is _NOT_ using BASH as their shell in /etc/passwd.
> Also, if anyone is _NOT_ having this problem and _IS_ running BASH as their
> shell in /etc/passwd.  If you fall under the previous two categories, how
> are you running SSHD (SRVANY, INETD, specific account, SYSTEM, CYGWIN=ntsec,
> . . .).

Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
with Cygwin 1.1.7, sshd is started via SRVANY under my own account
which has the appropriate user rights and I don't have any problems
using ssh and sshd on the box. For testing purposes I'm sometimes
switching to starting sshd from inetd using LocalSystem account and
password authentication. No problem at all.

I'm really sorry but I don't know what I can do as long as I can't
reproduce any of the described effects.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Erdely, Michael]

Just curious, Corinna, but have you tested this on many machines?  I'm
curious as to whether you are testing on your development machine.  I've
installed and experienced this behavior with fresh installs, existing
machines, Cygwin upgrades, . . .

Have you tried a fresh, out of the box, Cygwin install and see how it
behaves?

Just curious.  I'm trying to find some commonality between machines that
exhibit the bad behavior and those that don't.

-ME

PS: I'm not being critical in the least here.  The Cygwin team, and with my
interest in SSH, especially you, Corinna, have my complete and utter
gratitude and respect.  I'd love to be more adept at programming to be able
to contribute to the projects.  Thank you for your hard work.  It is
definitely more than appreciated.

----- Original Message -----
From: "Corinna Vinschen" <cygwin@cygwin.com>
To: "cygwin" <cygwin@cygwin.com>
Sent: Tuesday, January 16, 2001 8:32 AM
Subject: Re: Cygwin commands crashes after ssh login


>
> Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
> with Cygwin 1.1.7, sshd is started via SRVANY under my own account
> which has the appropriate user rights and I don't have any problems
> using ssh and sshd on the box. For testing purposes I'm sometimes
> switching to starting sshd from inetd using LocalSystem account and
> password authentication. No problem at all.
>
> I'm really sorry but I don't know what I can do as long as I can't
> reproduce any of the described effects.
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                                mailto:cygwin@cygwin.com
> Red Hat, Inc.



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Henry S. Thompson]

Corinna Vinschen <cygwin@cygwin.com> writes:

> Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
> with Cygwin 1.1.7, sshd is started via SRVANY under my own account
> which has the appropriate user rights and I don't have any problems
> using ssh and sshd on the box. For testing purposes I'm sometimes
> switching to starting sshd from inetd using LocalSystem account and
> password authentication. No problem at all.
> 
> I'm really sorry but I don't know what I can do as long as I can't
> reproduce any of the described effects.

As someone else struggling to help solve this, first can I warmly
endorse Mike's kind words -- you've been tremendously helpful, that's
why we're frustrated your efforts on this one issue have so far been
in vain.

Following up on one tiny part of the above, when you say '... from
inetd _using LocalSystem account_', what does that last bit mean?  I
don't have a LocalSystem user in either /etc/passwd or Win2K Users. . .

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Larry Hall (RFK Partners, Inc)]

At 09:08 AM 1/16/2001, Henry S. Thompson wrote:
>Following up on one tiny part of the above, when you say '... from
>inetd _using LocalSystem account_', what does that last bit mean?  I
>don't have a LocalSystem user in either /etc/passwd or Win2K Users. . .

I believe Corinna is referring to the System account on your local machine
(i.e. not on the domain).


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Wei Ku]

> > Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
> > with Cygwin 1.1.7, sshd is started via SRVANY under my own account
> > which has the appropriate user rights and I don't have any problems
> > using ssh and sshd on the box. For testing purposes I'm sometimes
> > switching to starting sshd from inetd using LocalSystem account and
> > password authentication. No problem at all.
>
> Following up on one tiny part of the above, when you say '... from
> inetd _using LocalSystem account_', what does that last bit mean?  I
> don't have a LocalSystem user in either /etc/passwd or Win2K Users. . .

I have exactly the same question.  Would someone please post a more
pedagogical procedure of creating the LocalSystem account in W2K?  Unlike in
the case of NT4, I found no place to specify any "special rights" for the
user.  I have been trying to make OpenSSHD work (for a multi-user
environment started from inetd) for a week and have not gotten anywhere (see
the following error message produced right after keying the password.)

ssh_exchange_identification: read: Connection reset by peer.

Wei

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Christopher Faylor]

On Tue, Jan 16, 2001 at 10:51:01AM -0500, Wei Ku wrote:
>> > Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
>> > with Cygwin 1.1.7, sshd is started via SRVANY under my own account
>> > which has the appropriate user rights and I don't have any problems
>> > using ssh and sshd on the box. For testing purposes I'm sometimes
>> > switching to starting sshd from inetd using LocalSystem account and
>> > password authentication. No problem at all.
>>
>> Following up on one tiny part of the above, when you say '... from
>> inetd _using LocalSystem account_', what does that last bit mean?  I
>> don't have a LocalSystem user in either /etc/passwd or Win2K Users. . .
>
>I have exactly the same question.  Would someone please post a more
>pedagogical procedure of creating the LocalSystem account in W2K?  Unlike in
>the case of NT4, I found no place to specify any "special rights" for the
>user.  I have been trying to make OpenSSHD work (for a multi-user
>environment started from inetd) for a week and have not gotten anywhere (see
>the following error message produced right after keying the password.)

www.google.com seems to be very chatty on the subject of "LocalSystem".

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Corinna Vinschen]

On Tue, Jan 16, 2001 at 10:51:01AM -0500, Wei Ku wrote:
> > Following up on one tiny part of the above, when you say '... from
> > inetd _using LocalSystem account_', what does that last bit mean?  I
> > don't have a LocalSystem user in either /etc/passwd or Win2K Users. . .

LocalSystem == SYSTEM.

> I have exactly the same question.  Would someone please post a more
> pedagogical procedure of creating the LocalSystem account in W2K?  Unlike in

Nothing to create. SYSTEM already exists. It never shows up in any
user management console.

> the case of NT4, I found no place to specify any "special rights" for the
> user.

It's a MMC snap-in. There are three of them for local, domain and
domain controller rights.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Egor Duda]

Hi!

Tuesday, 16 January, 2001 Corinna Vinschen cygwin@cygwin.com wrote:

CV> Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
CV> with Cygwin 1.1.7, sshd is started via SRVANY under my own account
CV> which has the appropriate user rights and I don't have any problems
CV> using ssh and sshd on the box.

btw, did you notice that if you try to login to _different_ account in
this configuration, sending SIGINT by pressing Ctrl-C from client side
doesn't work?

i've traced this situation down some time ago, and the reason appeared
to  be  with  access  rights  to  "sigcatch"  semaphore.  is there any
workaround (except starting sshd under LocalSystem)?

CV> For testing purposes I'm sometimes switching to starting sshd from
CV>  inetd  using LocalSystem account and  password authentication. No
CV> problem at all. 

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Christopher Faylor]

On Tue, Jan 16, 2001 at 08:08:18PM +0300, Egor Duda wrote:
>Tuesday, 16 January, 2001 Corinna Vinschen cygwin@cygwin.com wrote:
>CV> Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
>CV> with Cygwin 1.1.7, sshd is started via SRVANY under my own account
>CV> which has the appropriate user rights and I don't have any problems
>CV> using ssh and sshd on the box.
>
>btw, did you notice that if you try to login to _different_ account in
>this configuration, sending SIGINT by pressing Ctrl-C from client side
>doesn't work?
>
>i've traced this situation down some time ago, and the reason appeared
>to  be  with  access  rights  to  "sigcatch"  semaphore.  is there any
>workaround (except starting sshd under LocalSystem)?

What's this?  Actual information from someone who has *debugged* the
problem?

Surely you meant to say something like "I know, I can't even use
CTRL-C!  What's up with that?  I had to drop back to B19!"  Mentioning
low level things like the "sigcatch" semaphore is way too much info.

You're starting a dangerous trend, Egor.  Watch out.

cgf

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
;-)

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Egor Duda]

Hi!

Tuesday, 16 January, 2001 Christopher Faylor cgf@redhat.com wrote:

CF> On Tue, Jan 16, 2001 at 08:08:18PM +0300, Egor Duda wrote:
>>btw, did you notice that if you try to login to _different_ account in
>>this configuration, sending SIGINT by pressing Ctrl-C from client side
>>doesn't work?
>>
>>i've traced this situation down some time ago, and the reason appeared
>>to  be  with  access  rights  to  "sigcatch"  semaphore.  is there any
>>workaround (except starting sshd under LocalSystem)?

CF> What's this?  Actual information from someone who has *debugged* the
CF> problem?

it  turned  out  that  i've actually skipped  the  most important part
of debugging  process  --  thinking  an acquired result over :) Thanks
to Corinna's hint, i see now that cygwin behaves exactly as it should.

CF> Surely you meant to say something like "I know, I can't even use
CF> CTRL-C!  What's up with that?  I had to drop back to B19!"  Mentioning
CF> low level things like the "sigcatch" semaphore is way too much info.

i've almost sent annotated strace log along with my letter, by stopped
myself. *that* would be dangerous trend indeed :-)

CF> You're starting a dangerous trend, Egor.  Watch out.

:-)  Do   you  mean  i'm provoking "DDoS attack" on sourceware cvs, as
everyone immediately start checking out cygwin sources? :-)

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Christopher Faylor]

On Wed, Jan 17, 2001 at 04:18:51PM +0300, Egor Duda wrote:
>CF> You're starting a dangerous trend, Egor.  Watch out.
>
>:-)  Do   you  mean  i'm provoking "DDoS attack" on sourceware cvs, as
>everyone immediately start checking out cygwin sources? :-)

Hmm.  We're in the slow process of moving sources.redhat.com to a T3.
Maybe that would be just the impetus we need to finally finish the
move.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Corinna Vinschen]

On Tue, Jan 16, 2001 at 08:08:18PM +0300, Egor Duda wrote:
> Hi!
> 
> Tuesday, 16 January, 2001 Corinna Vinschen cygwin@cygwin.com wrote:
> 
> CV> Personally I'm using tcsh and bash as login shell. I'm using W2K SP1
> CV> with Cygwin 1.1.7, sshd is started via SRVANY under my own account
> CV> which has the appropriate user rights and I don't have any problems
> CV> using ssh and sshd on the box.
> 
> btw, did you notice that if you try to login to _different_ account in
> this configuration, sending SIGINT by pressing Ctrl-C from client side
> doesn't work?
> 
> i've traced this situation down some time ago, and the reason appeared
> to  be  with  access  rights  to  "sigcatch"  semaphore.  is there any
> workaround (except starting sshd under LocalSystem)?

Works for me but my account used for starting sshd is in the local
admin group. Could you test this in your environment, too, and
report if that solves your problem?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin commands crashes after ssh login

[Egor Duda]

Hi!

Wednesday, 17 January, 2001 Corinna Vinschen cygwin@cygwin.com wrote:

>> btw, did you notice that if you try to login to _different_ account in
>> this configuration, sending SIGINT by pressing Ctrl-C from client side
>> doesn't work?

CV> Works for me but my account used for starting sshd is in the local
CV> admin group. Could you test this in your environment, too, and
CV> report if that solves your problem?

Uh,   you're  right. i was starting inetd from non-admin account. after
restarting it from any admin account everything works fine.

i've  just realized that doing otherwise, cygwin would allow one process
to  send  signals  to  other  process  started from different account.
unices don't allow this, and neither should cygwin.

i think you can add something like this to README file

== openssh-*.*.*.README ==
...
- If you want to be able to login to different user accounts you'll
  have to start sshd under system account or any other account that
  is able to switch user context. Note that administrators are _not_
  able to do that by default! You'll have to give the following
  special user rights to the user:
  "Act as part of the operating system"
  "Replace process level token"
  "Increase quotas"
  and if used via service manager
  "Logon as a service".

+  This user should also be a member of local "Administrators" group.
...
==========================

or   "we   recommend   you   to   make  this  user a member of  local
"Administrators" group, otherwise Ctrl-C won't work!" :-)

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

tcsh Win2000: command line editing does not work

[Brad Barber]

[Expanded version of previous message.  No reply to the first one.]

I've recently installed cygwin and the cygwin version
of tcsh on a new Windows 2000 computer.  It is a big 
improvement over the older version of tcsh (the one not 
bundled with cygwin).

Everything works well except for command editing.  If I insert
characters, the display overwrites and occasionally shifts right.
The underlying data is correct (i.e., the characters are inserted
into the line).   Command editing works fine with the bash
shell.

For example,

KANE:/home/bbarber> 123456789

if I insert "a" between the 1 and the 2, the "3" is overwritten

KANE:/home/bbarber> 1a2456789
1a23456789: Command not found.

But if I insert "a" between the 5 and the 6, I correctly get

KANE:/home/bbarber>  12345a6789 
12345a6789: Command not found.

It fails to work without any .tcshrc defined.  It also fails to work
on a friends Win2K system.  Unfortunately, it fails to work
most of the time.

I checked stty.  It leaves "echoe" and "echoctl" while bash turns
these off.  "stty -echoe" does not change the flag.

Any ideas?

						--Brad

KANE:/usr/bin> stty -a
speed 38400 baud; rows 60; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe -echok -echonl -noflsh -tostop echoctl -echoke


KANE:/home/bbarber> bash
bash-2.04$ stty -a
speed 38400 baud; rows 62; columns 100; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany
-imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe -echok -echonl -noflsh -tostop echoctl -echoke


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Corinna Vinschen]

On Thu, Mar 15, 2001 at 04:29:02PM -0500, Brad Barber wrote:
> It fails to work without any .tcshrc defined.  It also fails to work
> on a friends Win2K system.  Unfortunately, it fails to work
> most of the time.
> 
> I checked stty.  It leaves "echoe" and "echoctl" while bash turns
> these off.  "stty -echoe" does not change the flag.
> 
> Any ideas?

Sure. It's a known problem. It only happens in a console window, not
in xterm or other tty/pty connections.

Patches (probably to the Cygwin console code) welcome.
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Kazuhiro Fujieda]

>>> On Thu, 15 Mar 2001 23:15:08 +0100
>>> Corinna Vinschen <cygwin@cygwin.com> said:

> Sure. It's a known problem. It only happens in a console window, not
> in xterm or other tty/pty connections.

Tcsh uses the insert mode in the terminal capability.  Cygwin
console doesn't support it, nonetheless the termcap database
tells it supports the insert mode. Therefore this problem can be
solved by modifying the database as the following.

cygwin:\
	:xn@:op=\E[39;49m:Km=\E[M:im=:ei=:tc=linux:

> Patches (probably to the Cygwin console code) welcome.

I believe it is hard to implement the insert mode in the Cygwin DLL.
____
  | AIST      Kazuhiro Fujieda <fujieda@jaist.ac.jp>
  | HOKURIKU  School of Information Science
o_/ 1990      Japan Advanced Institute of Science and Technology

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Brad Barber]

At 11:00 AM Thursday 3/22/2001, Kazuhiro Fujieda wrote:
>>>> On Thu, 15 Mar 2001 23:15:08 +0100
>>>> Corinna Vinschen <cygwin@cygwin.com> said:
>
>> Sure. It's a known problem. It only happens in a console window, not
>> in xterm or other tty/pty connections.
>
>Tcsh uses the insert mode in the terminal capability.  Cygwin
>console doesn't support it, nonetheless the termcap database
>tells it supports the insert mode. Therefore this problem can be
>solved by modifying the database as the following.
>
>cygwin:\
>        :xn@:op=\E[39;49m:Km=\E[M:im=:ei=:tc=linux:

Is there a corresponding change I can make to .cshrc?  If not,
please let me know where the database file is.

Another display problem:

I noticed that new text is not automatically displayed at the
end of the display buffer.  For example, if I scroll back and then 
type 'Enter/Return', it displays the command prompt in the bottom
of the currently display page.  It should move back to the end of
buffer, and display the prompt on the next (blank) line.

Thanks for your help.
                                                        --Brad

P.S.: Does any one know of a converter for .cshrc to .zshrc or .bashrc?
I'd like to have one initialization file that I can deploy under multiple
shells.



>> Patches (probably to the Cygwin console code) welcome.
>
>I believe it is hard to implement the insert mode in the Cygwin DLL.
>____
>  | AIST      Kazuhiro Fujieda <fujieda@jaist.ac.jp>
>  | HOKURIKU  School of Information Science
>o_/ 1990      Japan Advanced Institute of Science and Technology
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Kazuhiro Fujieda]

>>> On Thu, 22 Mar 2001 12:45:21 -0500
>>> Brad Barber <bradb@atg.com> said:

> >cygwin:\
> >        :xn@:op=\E[39;49m:Km=\E[M:im=:ei=:tc=linux:
> 
> Is there a corresponding change I can make to .cshrc?  If not,
> please let me know where the database file is.

You can modify the existing entry in /etc/termcap,
or create ~/.termcap and insert this entry.
____
  | AIST      Kazuhiro Fujieda <fujieda@jaist.ac.jp>
  | HOKURIKU  School of Information Science
o_/ 1990      Japan Advanced Institute of Science and Technology

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Christopher Faylor]

On Fri, Mar 23, 2001 at 01:00:44AM +0900, Kazuhiro Fujieda wrote:
>>>> On Thu, 15 Mar 2001 23:15:08 +0100
>>>> Corinna Vinschen <cygwin@cygwin.com> said:
>
>> Sure. It's a known problem. It only happens in a console window, not
>> in xterm or other tty/pty connections.
>
>Tcsh uses the insert mode in the terminal capability.  Cygwin
>console doesn't support it, nonetheless the termcap database
>tells it supports the insert mode. Therefore this problem can be
>solved by modifying the database as the following.
>
>cygwin:\
>	:xn@:op=\E[39;49m:Km=\E[M:im=:ei=:tc=linux:
>
>> Patches (probably to the Cygwin console code) welcome.
>
>I believe it is hard to implement the insert mode in the Cygwin DLL.

It should be fairly easy to do this.  There is a Windows API that 
can accomodate horizontal scrolling, I think: ScrollConsoleScreenBuffer.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: tcsh Win2000: command line editing does not work

[Brad Barber]

At 04:56 PM Thursday 3/15/2001, Andrew Markebo wrote:
>Which tcsh are you using, probably not something compiled with cygwin
>and therefore might collide with cygwin runtime or similar.. 

It is 
        tcsh 6.10.00-2
as installed with the most recent
        Cygwin setup.exe

                                                --Brad

P.S.: i was mistaken about stty.  Both bash and tcsh return the
the same.  Command line editing on bash works fine.


>        /Andy
>
>/ Brad Barber <bradb@atg.com> wrote:
>| [Expanded version of previous message.  No reply to the first one.]
>| 
>| I've recently installed cygwin and the cygwin version
>| of tcsh on a new Windows 2000 computer.  It is a big 
>| improvement over the older version of tcsh (the one not 
>| bundled with cygwin).
>| 
>| Everything works well except for command editing.  If I insert
>| characters, the display overwrites and occasionally shifts right.
>| The underlying data is correct (i.e., the characters are inserted
>| into the line).   Command editing works fine with the bash
>| shell.
>| 
>| For example,
>| 
>| KANE:/home/bbarber> 123456789
>| 
>| if I insert "a" between the 1 and the 2, the "3" is overwritten
>| 
>| KANE:/home/bbarber> 1a2456789
>| 1a23456789: Command not found.
>| 
>| But if I insert "a" between the 5 and the 6, I correctly get
>| 
>| KANE:/home/bbarber>  12345a6789 
>| 12345a6789: Command not found.
>| 
>| It fails to work without any .tcshrc defined.  It also fails to work
>| on a friends Win2K system.  Unfortunately, it fails to work
>| most of the time.
>| 
>| I checked stty.  It leaves "echoe" and "echoctl" while bash turns
>| these off.  "stty -echoe" does not change the flag.
>| 
>| Any ideas?
>| 
>|                                               --Brad
>| 
>| KANE:/usr/bin> stty -a
>| speed 38400 baud; rows 60; columns 80; line = 0;
>| intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>;
>| eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
>| lnext = ^V; flush = ^O; min = 1; time = 0;
>| -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
>| -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
>| -iuclc -ixany -imaxbel
>| opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>| isig icanon iexten echo echoe -echok -echonl -noflsh -tostop echoctl -echoke
>| 
>| 
>| KANE:/home/bbarber> bash
>| bash-2.04$ stty -a
>| speed 38400 baud; rows 62; columns 100; line = 0;
>| intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q;
>| stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
>| -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
>| -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany
>| -imaxbel
>| opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>| isig icanon iexten echo echoe -echok -echonl -noflsh -tostop echoctl -echoke
>| 
>| 
>| --
>| Want to unsubscribe from this list?
>| Check out: http://cygwin.com/ml/#unsubscribe-simple 


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Earnie Boyd]

--- "David M. Karr" <dkarr@tcsi.com> wrote:
> 
> I'm sure this has something to do with line endings, but I don't
> understand what has to be done.
> 

Then use setup to install Cygwin on the other machine.  It does all that needs
to be done for those who don't know what to do.

Cheers,

=====
Earnie Boyd
mailto:earnie_boyd@yahoo.com

---         < http://earniesystems.safeshopper.com >         ---
--- Cygwin: POSIX on Windows < http://gw32.freeyellow.com/ > ---
---   Minimalist GNU for Windows < http://www.mingw.org/ >   ---

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
  Earnie> --- "David M. Karr" <dkarr@tcsi.com> wrote:
  >> 
  >> I'm sure this has something to do with line endings, but I don't
  >> understand what has to be done.

  Earnie> Then use setup to install Cygwin on the other machine.  It does all that needs
  Earnie> to be done for those who don't know what to do.

I did.  I installed Cygwin with "setup", then installed "pdksh".  The
given error is what I get when I try to execute "ksh".  I don't get
that when I try to use "bash".  However, on my own PC, where I
installed Cygwin & pdksh a couple of months ago, I don't see this
problem at all.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

new install of cygwin with pdksh doesn't work

[David M. Karr]

I have a relatively recent install of cygwin, along with pdksh-2.14.
I have scripts that reference "/bin/ksh" that work fine.

Today I've been setting up these tools on another PC, and now when I
execute "ksh", I get the following:

    ksh: /cygdrive/d/dmk/.bashrc[1]: syntax error: `in^M' unexpected

I'm sure this has something to do with line endings, but I don't
understand what has to be done.

In case it matters, here are my simple ".bashrc", ".bash_profile", and
".bashvars" files:

----------.bashrc: cut here------
case $- in
	 *i*)
		  if [ "$TERM" = "dumb" ] ; then
				alias ls="ls -aFC --color"
		  else
				alias ls="ls -aFC";
		  fi
		  PS1="[\H;] "

		  . $HOME/.bash_profile
		  ;;
esac
----------.bashrc: cut here------

----------.bash_profile: cut here------
umask 2

. $HOME/.bashvars
----------.bash_profile: cut here------

----------.bashvars: cut here------
export HISTSIZE=64
unset HISTFILE

export ENV=$HOME/.bashrc

export PAGER=less

export MPAGE="-4 -b Letter -H -X -c -f -z lp"

export PATH="$PATH:.://d/dmk/lisp/jde-2.1.8/lisp"

export PATH="$PATH:/usr/local/bin"

export TP_OPTS="-m DRAFT -i --n -C --f --F -S 2 -4"

function dospathinbash () {
	echo $(cygpath -w $1) | sed -e 's,\\,/,g'
}
export -f dospathinbash
----------.bashvars: cut here------
-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Christopher Faylor]

On Wed, Dec 20, 2000 at 02:39:08PM -0800, David M. Karr wrote:
>I have a relatively recent install of cygwin, along with pdksh-2.14.
>I have scripts that reference "/bin/ksh" that work fine.
>
>Today I've been setting up these tools on another PC, and now when I
>execute "ksh", I get the following:
>
>    ksh: /cygdrive/d/dmk/.bashrc[1]: syntax error: `in^M' unexpected
>
>I'm sure this has something to do with line endings, but I don't
>understand what has to be done.

Remove the ^Ms in .bashrc.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Christopher" == Christopher Faylor <cgf@redhat.com> writes:
  Christopher> On Wed, Dec 20, 2000 at 02:39:08PM -0800, David M. Karr wrote:
  >> I have a relatively recent install of cygwin, along with pdksh-2.14.
  >> I have scripts that reference "/bin/ksh" that work fine.
  >> 
  >> Today I've been setting up these tools on another PC, and now when I
  >> execute "ksh", I get the following:
  >> 
  >> ksh: /cygdrive/d/dmk/.bashrc[1]: syntax error: `in^M' unexpected
  >> 
  >> I'm sure this has something to do with line endings, but I don't
  >> understand what has to be done.

  Christopher> Remove the ^Ms in .bashrc.

I have none.  These are the exact same files I used on the other PC
that is working fine.  I copied them directly from the PC that doesn't
have the problem to the PC that does have the problem, without change.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[Christopher Faylor]

On Wed, Dec 20, 2000 at 03:49:32PM -0800, David M. Karr wrote:
>>>>>> "Christopher" == Christopher Faylor <cgf@redhat.com> writes:
>  Christopher> On Wed, Dec 20, 2000 at 02:39:08PM -0800, David M. Karr wrote:
>  >> I have a relatively recent install of cygwin, along with pdksh-2.14.
>  >> I have scripts that reference "/bin/ksh" that work fine.
>  >> 
>  >> Today I've been setting up these tools on another PC, and now when I
>  >> execute "ksh", I get the following:
>  >> 
>  >> ksh: /cygdrive/d/dmk/.bashrc[1]: syntax error: `in^M' unexpected
>  >> 
>  >> I'm sure this has something to do with line endings, but I don't
>  >> understand what has to be done.
>
>  Christopher> Remove the ^Ms in .bashrc.
>
>I have none.  These are the exact same files I used on the other PC
>that is working fine.  I copied them directly from the PC that doesn't
>have the problem to the PC that does have the problem, without change.

What are you using to verify this?  od -c should show you if your
supposition that there are no ^Ms in your file is correct.

I would not be surprised to find out that you are wrong and that your
.bashrc file has lines that end with ^M^J(\r\n).

Editing the file with 'vi -b' should also show any ^Ms.

If you really don't have any ^Ms in your file then I am at a loss as
to why they would show up in your error output.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: new install of cygwin with pdksh doesn't work

[David M. Karr]

>>>>> "Christopher" == Christopher Faylor <cgf@redhat.com> writes:
  Christopher> On Wed, Dec 20, 2000 at 03:49:32PM -0800, David M. Karr wrote:
  >>>>>>> "Christopher" == Christopher Faylor <cgf@redhat.com> writes:
  Christopher> On Wed, Dec 20, 2000 at 02:39:08PM -0800, David M. Karr wrote:
  >> >> I have a relatively recent install of cygwin, along with pdksh-2.14.
  >> >> I have scripts that reference "/bin/ksh" that work fine.
  >> >> 
  >> >> Today I've been setting up these tools on another PC, and now when I
  >> >> execute "ksh", I get the following:
  >> >> 
  >> >> ksh: /cygdrive/d/dmk/.bashrc[1]: syntax error: `in^M' unexpected
  >> >> 
  >> >> I'm sure this has something to do with line endings, but I don't
  >> >> understand what has to be done.
  >> 
  Christopher> Remove the ^Ms in .bashrc.
  >> 
  >> I have none.  These are the exact same files I used on the other PC
  >> that is working fine.  I copied them directly from the PC that doesn't
  >> have the problem to the PC that does have the problem, without change.

  Christopher> What are you using to verify this?  od -c should show you if your
  Christopher> supposition that there are no ^Ms in your file is correct.

  Christopher> I would not be surprised to find out that you are wrong and that your
  Christopher> .bashrc file has lines that end with ^M^J(\r\n).

  Christopher> Editing the file with 'vi -b' should also show any ^Ms.

  Christopher> If you really don't have any ^Ms in your file then I am at a loss as
  Christopher> to why they would show up in your error output.

Ok, now I have a little more useful information.  The file does have
"\r\n" line endings.  Even my original file, from the PC installation
which works.  So the Cygwin installed on the first PC (from a couple
of months ago) can deal with ^Ms, but the new install cannot.  I tried
creating an ordinary file with Emacs, and it also produces ^Ms (using
"vi -b" to verify).  I can't use this arrangement if the files
produced by Emacs are invalid with Cygwin.  Again, I don't have this
problem on the original installation.

So does this have something to do with one of the initial choices you
get when you run "setup", which is "Default Text File Type", choices
"Dos" or "Unix"?  In order to get this to work, do I have to
completely reinstall, selecting "Dos"?  I believe that when I
installed Cygwin on the first PC, I didn't get those choices.

-- 
===============================================================================
David M. Karr     ; dkarr@tcsi.com  ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJ12P (#12004)


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

[ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Paul Sokolovsky]

Hello cygwin,

      I would like to introduce to gnu-win32 community new (yet
another) POSIX "emulation" layer. It is product of some thoughts and
ideas that were spoken, and sufficiently criticized, on cygwin list.
Standard description follows:

"PW32 is implementation of (subset of) POSIX/Unix API for Win32 systems. Its main
concerns are efficiency and full platform coverage, including adequate support for low-end
Win9x systems. PW32 is based on DJGPP's runtime library by DJ Delorie. PW32 is licensed
under LGPL."

      PW32 is only month on public, but before that it was more than
year in development. That means it'd already has something to show,
though of course it's far from being complete. Also, as I hinted above,
it's based on solutions that might be considered questionable, if not
orthodox. Even besides that, I claim that their sole purpose is to get
rid of mean, chore problems plaguing existing implementations, and to
get efficient implementation. So, I took steps to describe these
traits, and provide means of coping with them and integrating with
"native" environment.

0.3.0 is second public and first 'full-fledged' (as for alpha)
release. Changes include:

* Many bugfixes.
* Tested and runs on 9x and NT. On 95, problems known and identified,
with workarounds provided.
* Binaries provided: build environment based on gcc-2.95.2-1-mingw32
(courtesy of Mumit Khan), ash, fileutils, textutils, sed, grep,
sh-utils, diffutils, make.
* Updated documentation.

  Also, PW32 is currently in active development, for example, now
two serious problems with 0.3.0 had been fixed (and available from CVS).


PW32 is hosted on SourceForge, http://pw32.sourceforge.net/

Place to discuss PW32 is mingw32 mailing list,
http://www.egroups.com/list/mingw32



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Chris Faylor]

Hmm.  I would like to receive opinions on whether people consider this
announcement to be off-topic.

We don't see any DJGPP announcments here.  We don't see any UWIN or Interix
traffic.  Maybe I'm wrong, but I don't think that Mikey announced here, either.
(How's that for giving a plug to all of cygwin's competitors?)

I don't think that announcements of (alternative) Posix-over-Win32 layers are
on topic here but if everyone else disagrees, my opinion can be changed.

cgf

On Mon, Mar 13, 2000 at 03:10:26PM +0200, Paul Sokolovsky wrote:
>I would like to introduce to gnu-win32 community new (yet another)
>POSIX "emulation" layer.  It is product of some thoughts and ideas that
>were spoken, and sufficiently criticized, on cygwin list.  Standard
>description follows:

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Dr. Volker Zell]

>>>>> "Chris" == Chris Faylor <cgf@cygnus.com> writes:

    Chris> Hmm.  I would like to receive opinions on whether people consider this
    Chris> announcement to be off-topic.

It's off-topic.

Ciao
  Volker


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Paul Sokolovsky]

Hello Chris,

Chris Faylor <cgf@cygnus.com> wrote:

CF> Hmm.  I would like to receive opinions on whether people consider this
CF> announcement to be off-topic.

CF> We don't see any DJGPP announcments here.  We don't see any UWIN or Interix
CF> traffic.  Maybe I'm wrong, but I don't think that Mikey announced here, either.
CF> (How's that for giving a plug to all of cygwin's competitors?)

CF> I don't think that announcements of (alternative) Posix-over-Win32 layers are
CF> on topic here but if everyone else disagrees, my opinion can be changed.

    I greatly appologize! I wanted to include these possible
appologies in original announcement, but just thought: after all, we
all doing same thing, namely gnu-win32 (btw, isn't that trademark of
Cygnus, the Red Hat company?). While this list is of course dedicated
and owned by cygwin, it's de-facto mother list of all
Unix/Gnu-on-win32 lists, and have grown others (such as mingw32) off
itself. I also think my little stuff indebted to cygwin by its birth,
and hoped I could use that wonderful possibility - to announce it
once, and rejoice cygwin people with that announcement. And of course, my
little stuff is not competitor of cygwin (competitor? ridiculous. have
years of work of many people were put into it? does it offer that level
of support?), but rather an (spiritual) offspring targeted at niche
intentinally left out by cygwin. After all, that's what free software
is all about.

   I once again would like to say that was one-time announcemnt for
information of gnu-win32 comminity. Under no circumstances I planned
to continue that announcing or start discussions here. If even that
was illicit, I would like to ask pardon from all cygwin community.

  Thank you for your support.

CF> cgf



--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Michael Hirmke]

Hi Chris,

>Hmm.  I would like to receive opinions on whether people consider this
>announcement to be off-topic.
>
[...]
>I don't think that announcements of (alternative) Posix-over-Win32 layers are
>on topic here but if everyone else disagrees, my opinion can be changed.

As long as an announcement is the only traffic generated by such an
alternative to Cygwin I'd be interested to read it in here.

>
>cgf

Bye.
Michael.
-- 
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: [ANN] PW32 the (alternative) Posix-over-Win32 layer 0.3.0 released

[Chris Faylor]

On Mon, Mar 13, 2000 at 11:56:00PM +0200, Michael Hirmke wrote:
>Hi Chris,
>
>>Hmm.  I would like to receive opinions on whether people consider this
>>announcement to be off-topic.
>>
>[...]
>>I don't think that announcements of (alternative) Posix-over-Win32 layers are
>>on topic here but if everyone else disagrees, my opinion can be changed.
>
>As long as an announcement is the only traffic generated by such an
>alternative to Cygwin I'd be interested to read it in here.

There is no way to guarantee that.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

uudecode?

[John Cooper]

Can anyone point me to a reliable version of the command line
uudecode.exe/uuencode.exe utilities for NT 4.0?

Thanks,

    --- John

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

Re: uudecode?

[Michael Hirmke]

Hi John,

>
>Can anyone point me to a reliable version of the command line
>uudecode.exe/uuencode.exe utilities for NT 4.0?

Don't know, what you mean by reliable, but you can get the
sharutils-4.2c package, which contains uuencode/uudecode among other
utilities
     - on ftp.franken.de
     - in /pub/win32/develop/gnuwin32/cygwin32/porters/Hirmke_Michael/B20
     - as sharutils-4.2c-cygwin-b20-bin.tar.gz
     - or sharutils-4.2c-cygwin-b20-bin.zip

>
>Thanks,
>
>    --- John

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://aquarius.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: uudecode?

[John Cooper]

mh@mike.franken.de (Michael Hirmke) writes:

 > >Can anyone point me to a reliable version of the command line
 > >uudecode.exe/uuencode.exe utilities for NT 4.0?
 > 
 > Don't know, what you mean by reliable, but you can get the sharutils-4.2c
 > package, which contains uuencode/uudecode among other utilities

These just don't work at all:

  $ cp c:/WINNT/NOTEPAD.EXE n.exe
  $ ./n.exe      # works fine!
  $ uuencode n.exe n.exe > n.uu
  $ rm n.exe
  $ ls n.*
  n.uu
  $ uudecode n.uu
  $ ls n.*
  n.exe*  n.uu
  $ ./n.exe
  zsh: exec format error: .\n.exe
  $
  $ ls -l n.exe
  -rwxrwxrwx   1 JCooper          Domain_Users      594 Jan 18 10:37 n.exe*
  $

Any ideas what's wrong with it?

Thanks,

    --- John

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

Re: uudecode?

[Glenn Spell]

John Cooper wrote:
> 
> mh@mike.franken.de (Michael Hirmke) writes:
> 
>  > >Can anyone point me to a reliable version of the command line
>  > >uudecode.exe/uuencode.exe utilities for NT 4.0?
>  > 
>  > Don't know, what you mean by reliable, but you can get the sharutils-4.2c
>  > package, which contains uuencode/uudecode among other utilities
> 
> These just don't work at all:

For decode only, you might try uu.com from:
< http://www.walbeehm.com/mrcode.html >.
(That was: http://www.walbeehm.com/mrcode.html ).

-glenn

-- 
            Glenn Spell <glenn@gs.fay.nc.us>
         Fayetteville, North Carolina, U. S. A.
  ____________________________________________________
  ... blue skies ... happy trails ... sweet dreams ...
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: uudecode?

[root]

Let's stop this uuencode/decode discussion.
Here are two small little programs in that old but powerful language we all
know somehow.

------------------------------------------------------cut here: uuencode.c
#include <stdio.h>
#define ENC(c) ((c) ? ((c) & 077) + ' ': '`')
static int uuencode(char *nom)  /* nom means 'name' in french :-) */
{
    int ch, n, idx;
    register char *p;
    char buf[80], outbuf[250];
    FILE *in;

    if ((in = fopen(nom, "rb")) == NULL)
        return 1;		/* please add some error checking/reporting */
    printf("begin 0666 %s\n",nom);/* note: no attempt to fake any permissions */
    while ((n = fread(buf, 1, 45, in)) != 0) {
        idx = 0;
        outbuf[idx++] = ENC(ch);
        for (p = buf; n > 0; n -= 3, p += 3) {
            ch = *p >> 2;
            ch = ENC(ch);
            outbuf[idx++] = ch;
            ch = ((*p << 4) & 060) | ((p[1] >> 4) & 017);
            ch = ENC(ch);
            outbuf[idx++] = ch;
            ch = ((p[1] << 2) & 074) | ((p[2] >> 6) & 03);
            ch = ENC(ch);
            outbuf[idx++] = ch;
            ch = p[2] & 077;
            ch = ENC(ch);
            outbuf[idx++] = ch;
        }
        outbuf[idx++] = '\n';
        outbuf[idx] = 0;
        printf("%s", outbuf);
    }
    printf("%c\nend\n", ENC(0));
    fclose(in);
    return 0;
}
int main(int argc, char *argv[]) // add error checking here if you feel like
{
    return uuencode(argv[1]);
}
---------------------------------------------------cut here uudecode.c
#include <stdio.h>
#include <string.h>
#define DEC(c)  (((c) - ' ') & 077)
static int uudecode(char *fname)
{
    register int n;
    register char ch, *p;
    char buf[2 * BUFSIZ],outname[512];
    FILE *out, *in = fopen(fname, "rb");
    if (in == NULL) {
        fprintf(stderr,"Impossible to open %s\n",fname);
        return 1;
    }
    while (fgets(buf, 80, in)) {
        if (!strncmp(buf, "begin", 5))
            goto decodeStart;
    }
    fprintf(stderr,"No 'begin' line found in %s\n",fname);
    return 1;
decodeStart:
    p = buf + sizeof("begin");
    while (*p == ' ' || *p == '\t')
        p++;
    while (*p >= '0' && *p <= '9') // ignore any permissions setting
        p++;
    while (*p == ' ' || *p == '\t')
        p++;
    strcpy(outname, p);
    p = outname;
    while (*p >= ' ') // This supposes file name chars are >= ' '
        p++;
    *p = 0;
    out = fopen(outname, "wb");
    if (out == NULL) {
        fprintf(stderr,"Impossible to open %s\n",outname);
        return 1;
    }
    while (1) {
        if (!fgets(buf, 80, in))
            break;
        if (!strncmp(buf, "end\r\n", 5))
            break;
        p = buf;
        n = DEC(*p);
        if (n <= 0)
            break;
        for (++p; n > 0; p += 4, n -= 3) {
            if (n >= 3) {
                ch = DEC(p[0]) << 2 | DEC(p[1]) >> 4;
                fputc(ch, out);
                ch = DEC(p[1]) << 4 | DEC(p[2]) >> 2;
                fputc(ch, out);
                ch = DEC(p[2]) << 6 | DEC(p[3]);
                fputc(ch, out);
            }
            else {
                if (n >= 1) {
                    ch = DEC(p[0]) << 2 | DEC(p[1]) >> 4;
                    fputc(ch, out);
                }
                if (n >= 2) {
                    ch = DEC(p[1]) << 4 | DEC(p[2]) >> 2;
                    fputc(ch, out);
                }
            }
        }
    }
    fclose(out);
    fclose(in);
    return 0;
}
int main(int argc, char *argv[]) // Add error checking here if you feel like
{
    return uudecode(argv[1]);
}

---------------------------------------------------------------------------
enjoy!
-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel 01 48.23.51.44
93430 Villetaneuse 			Fax 01 48.23.95.39
France
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: uudecode?

[John Cooper]

root@jacob.remcomp.fr (root) writes:

 > Let's stop this uuencode/decode discussion.  Here are two small little
 > programs in that old but powerful language we all know somehow.

This source simply doesn't work for me - it generates all sorts of different
characters at the beginning of encoded lines, rather than the "M" that I see
with most uuencoders.

I finally pulled over the sharutils-4.2 source, got that to build under NT and
then carefully enabled (or disabled) the binary flag on the fopen calls.  It
now seems to work fine - without mucking with mounts or using bash (I prefer
zsh).

Thanks for all the ideas...

    --- John

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

Re: uudecode?

[Pierre A. Humblet]

This has taken enough bandwidth that we might at least understand what
happened.

As stated in their README, the shareutils from ftp.franken.de require
binary mount. On a text mounted system the uuencode INPUT file gets
truncated at ^Z.
Ideally uuencode should binary open its input file AND setmode stdin to
binary (for use with cygwin shells, other shells always open stdin binary).
Similarly the output of uudecode should be binary.

It doesn't matter if the output of uuencode and the input of uudecode are
text or binary. Those programs encode the line length, usually taking in 45
characters at a time (they have to, to survive inclusion in e-mails).
uuencoded lines start with M because M is the 45th printable character
(above " "). Those 45 characters are expanded to 45 * 8/6 = 60 characters
per line, plus the length.

The uuencode.c program contributed in
http://www.cygnus.com/ml/gnu-win32/1999-Jan/0493.html has a bug: the first
ENC(ch) should have been ENC(n). That's why the uuencoded lines did not
start with M.  
There is also a bug in uudecode.c
if (!strncmp(buf, "end\r\n", 5))
will fail when the file ends with "end\n". The bug is not exposed because
the program normally terminates at the next to last line, which has zero
length.

Pierre

At 02:22 PM 1/20/99 +0000, John Cooper wrote:
>I finally pulled over the sharutils-4.2 source, got that to build under NT
and
>then carefully enabled (or disabled) the binary flag on the fopen calls.  It
>now seems to work fine - without mucking with mounts or using bash (I prefer
>zsh).

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

Re: uudecode?

[John Cooper]

root@jacob.remcomp.fr (root) writes:

 > Let's stop this uuencode/decode discussion.  Here are two small little
 > programs in that old but powerful language we all know somehow.

These also don't work (see below).

This doesn't look like a "mount" problem?  The cygwin FAQ states about mount:

  "The '-b' option to mount mounts the mountpoint in binary mode where text and
   binary files are treated equivalently. This should only be necessary for badly
   ported Unix programs where binary flags are missing from open calls."

... and your code does open the files in binary mode, so shouldn't it work
regardless of mount?

It even seems to fail when I do mount a directory in binary mode...

If nobody has a solution, I guess I'll try debugging it when I get time.

    --- John

  $ cp c:/winnt/NOTEPAD.EXE n.exe
  $ ls -l n.exe
  -rwxrwxrwx   1 JCooper          Domain_Users    45328 Jan 19 10:28 n.exe*
  $
  $ ./uuencode n.exe n.exe > n.uu
  $ ls -l n.uu
  -rw-rw-rw-   1 JCooper          Domain_Users    62479 Jan 19 10:28 n.uu
  $
  $ ./uudecode n.uu
  $ ls -l n.exe
  -rwxrwxrwx   1 JCooper          Domain_Users      261 Jan 19 10:28 n.exe*
  $

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

Re: uudecode?

[John Cooper]

"John Cooper" <John.Cooper@citrix.com> writes:

 > These also don't work (see below).

Oddly, if I use the combination of the sharutils uuencode.exe and the
uudecode.exe that I compiled from the source posted here, it works.

Other combinations don't seem to work...

I've also hacked the uudecode source to read from stdin when given no args, so
I can use uudecode.exe with Emacs' call-process-region.  At last uuencoded
attachments from Outlook can be quickly decoded from pGnus!

    --- John

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

Re: uudecode?

[Corinna Vinschen]

John Cooper wrote:
> 
> Can anyone point me to a reliable version of the command line
> uudecode.exe/uuencode.exe utilities for NT 4.0?

Try sharutils-4.2 from http://www.gnu.org/software/software.html

It compiles out of the box.

Corinna


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

long long vs long

[Graham Murray]

This is probably a silly question, but rather than having long long for
64 bit, why was long not made 64bit? The standard (AFAIK) states that
short <= int <= long.  So, it should be possible for long to be 64 bit
rather than 32. This would give a simple progression from 8bit chars to
64bit longs.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Graham Murray said:
> 
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

   This is a frequent question.  I am told that while it would
be thoreticaly a good idea, so much existing code would break as
to make it unviable.  (This from a member of the C9x committee.)

   Regards,
       Harry.

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

Re: long long vs long

[Michael H. Warfield]

Graham Murray enscribed thusly:
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

	Unfortunately the standard also specifies the length of several
types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.
The int type is NOT a specific length but is platform dependent, so an int
on earlier (XENIX and MS-DOS) systems use to be 16 bits while on modern
systems it's 32 bits.  Specifically, an int is defined as the "native"
integer number representation.  Of course, all of these types are "signed"
and have "unsigned" equivalences.  And before have the list jumps on me,
yes I know that unsigned and signed char's get into some interesting
ambiguities, particularly with old code that assumed that a char was
unsigned...

	Most code uses "int" where it wants the native number
representation.  That same code uses "short" and "long" where it wants
specific field lengths.  Imagine the havock that will transpire in code
with masks such as "foo = bar & 0xffff0000L" if you were to expand
long to be 64 bits.  The porting nightmare would make a sequel to
"Nightmare on Elm Street".

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Harry Broomhall]

Michael H. Warfield said:
> 
[SNIP]

> 	Unfortunately the standard also specifies the length of several
> types.

  Really?  Can you give the paras where it does this?  AFAIK
short, int and long are nowhere defined in length.

   Regards,
      Harry.

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

Re: long long vs long

[Matthew Donadio]

Michael H. Warfield wrote:
> Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

Not to be picky, but to quote K&R II pg. 36:

"Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16
bits, longs are at least 32 bits, and short is no longer than int, which
is no longer than long."

Also, chars are not limited to be only 8 bits, but they must be at least
8 bits.  I routinely work on processors (C40, C44) where CHAR_BIT is
32.  This results in the pecularity that 

	sizeof(char) = sizeof(long) = 1

which is perfectly legal.  I think there is a lot more code in the world
that asumes that CHAR_BIT is 8 than sizeof(long) is 4.

-- 
Matt Donadio (donadio@isptechinc.com) | 43 Leopard Rd, Suite 102
Sr. Software Engineer                 | Paoli, PA 19301-1552
Image & Signal Processing, Inc.       | Phone: +1 610 407 4391
http://www.isptechinc.com             | FAX:   +1 610 407 4405
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Timothy Writer]

"Michael H. Warfield" <mhw@alcove.wittsend.com> writes:

> Graham Murray enscribed thusly:
> > This is probably a silly question, but rather than having long long for
> > 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> > short <= int <= long.  So, it should be possible for long to be 64 bit
> > rather than 32. This would give a simple progression from 8bit chars to
> > 64bit longs.
> 
> 	Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

The standard says no such thing.  In section 5.2.4.2.1 Sizes of integral
types <limits.h>, it says

        The values given below shall be replaced by constant expressions
    suitable for use in #if preprocessing directives....  Their
    implementation defined values shall be EQUAL or GREATER [emphasis
    mine] in magnitude (absolute value) to those shown, with the same
    sign.

    -- number of bits for smallest object that is not a bit field (byte)
       CHAR_BIT				8

    ....

    -- minimum value for an object of type short int
       SHRT_MIN			   -32767

    -- maximum value for an object of type short int
       SHRT_MAX			   +32767

    ....

    -- minimum value for an object of type int
       INT_MIN			   -32767

    -- maximum value for an object of type int
       INT_MAX			   +32767
  
    ....

    -- minimum value for an object of type long int
       LONG_MIN		      -2147483647

    -- maximum value for an object of type long int
       LONG_MAX		      +2147483647

The first paragraph clearly states that these values are implementation
defined and that the sample values are suitable minimums.

Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
integer types, designated as signed char, short int, int, and long int."  It
then goes on to say, "In the list of signed integer types above, the range of 
values of each type is a subrange of the values of the next type in the
list."

In other words,

    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

and

    sizeof(char)  == 1
    sizeof(short) >= 2
    sizeof(int)   >= 2
    sizeof(long)  >= 4

While I agree that there is a large body of code that assumes long is 32
bits, such code is not portable.  And not because of a flaw in the Standard,
but because the programmer(s) responsible either didn't know the above or
didn't care.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Matthew Donadio]

Timothy Writer wrote:
>     sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> and
>     sizeof(char)  == 1
>     sizeof(short) >= 2
>     sizeof(int)   >= 2
>     sizeof(long)  >= 4

Not necessarilly.  By definition sizeof(char) is always 1 no matter what
CHAR_BIT is defined to be.  But the values for the other sizeof's are
not correct for all machines.

For example, on the TMS320C3x and TMS320C4x families, the minimum
addressable memory unit is 32 bits, so CHAR_BIT for this machine is 32. 
It also happens that all other intergral types (short, int, and long)
are 32 bits (the exact size of char), so

sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) == 1

Weird, but legal.

-- 
Matt Donadio (donadio@isptechinc.com) | 43 Leopard Rd, Suite 102
Sr. Software Engineer                 | Paoli, PA 19301-1552
Image & Signal Processing, Inc.       | Phone: +1 610 407 4391
http://www.isptechinc.com             | FAX:   +1 610 407 4405
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Larry Hall]

At 01:48 PM 7/23/98 -0400, Timothy Writer wrote:
>Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
>integer types, designated as signed char, short int, int, and long int."  It
>then goes on to say, "In the list of signed integer types above, the range of 
>values of each type is a subrange of the values of the next type in the
>list."
>
>In other words,
>
>    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
>
>and
>
>    sizeof(char)  == 1
>    sizeof(short) >= 2
>    sizeof(int)   >= 2
>    sizeof(long)  >= 4
>

Sorry but this doesn't seem to follow.  I agree with the interpretation of
the standard, namely:

  sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

However, this does NOT imply what follows (the sizeof lines after the "and".)
The implication from the standard is:

  sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

AND

  sizeof(char)  == 1
  sizeof(short) >= 1
  sizeof(int)   >= 1
  sizeof(long)  >= 1

which someone on this list pointed out previously.  I think the key words 
here are that "the range of values of each type is a subrange of the values 
of the next type in the list."  Are we getting a little too far off topic 
for this list?





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                    http://www.rfk.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Timothy Writer]

Larry Hall <lhall@rfk.com> writes:

> At 01:48 PM 7/23/98 -0400, Timothy Writer wrote:
> >Furthermore, in section 6.1.2.5 the Standard states, "There are four signed
> >integer types, designated as signed char, short int, int, and long int."  It
> >then goes on to say, "In the list of signed integer types above, the range of 
> >values of each type is a subrange of the values of the next type in the
> >list."
> >
> >In other words,
> >
> >    sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> >
> >and
> >
> >    sizeof(char)  == 1
> >    sizeof(short) >= 2
> >    sizeof(int)   >= 2
> >    sizeof(long)  >= 4
> >
> 
> Sorry but this doesn't seem to follow.  I agree with the interpretation of
> the standard, namely:
> 
>   sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> 
> However, this does NOT imply what follows (the sizeof lines after the "and".)
> The implication from the standard is:
> 
>   sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
> 
> AND
> 
>   sizeof(char)  == 1
>   sizeof(short) >= 1
>   sizeof(int)   >= 1
>   sizeof(long)  >= 1
> 
> which someone on this list pointed out previously.  I think the key words 
> here are that "the range of values of each type is a subrange of the values 
> of the next type in the list."  Are we getting a little too far off topic 
> for this list?

This follows from the earlier section of the standard I posted which states
the minimum ranges for each type, namely -127 to +127 for signed char, -32767
to +32767 for signed short, etc.  These imply that char is at least 8 bits,
short is at least 16 bits, and int and long are at least 32 bits.  Assuming a
char is exacly eight bits (it's not clear to me whether the standard requires
that or not) it follows that:

    sizeof(char)  == 1
    sizeof(short) >= 2
    sizeof(int)   >= 2
    sizeof(long)  >= 4

As to whether we're getting off topic.  Clearly this group is about
portability and I was disturbed by the number of misinformed posters
spreading incorrect information about something so fundamental to porability.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Benjamin Riefenstahl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2360 bytes --]

Hi Michael,


Michael H. Warfield wrote:
>         Unfortunately the standard also specifies the length of several
> types.  Specifically char is 8 bits, short is 16 bits, and long is 32 bits.

No, it only specifies the *minimum* ranges that each type must cover and
it gives some relations like all values representable by "short" must
also be representable by "int" and "long" etc. The net result for most
current architectures are the conditions (I hope I don't miss anything
important)

  sizeof(char) == 1  // that's a definition actually, not a condition
  sizeof(char) * CHAR_BITS >= 8
  sizeof(short) * CHAR_BITS >= 16
  sizeof(int) * CHAR_BITS >= 16
  sizeof(long) * CHAR_BITS >= 32
  sizeof(int) >= sizeof(short)
  sizeof(long) >= sizeof(int)

The language standard does not say that "int" must be similar to one of
"short" or "long", so an implementation that does

  sizeof(short) * CHAR_BITS == 16
  sizeof(int) * CHAR_BITS == 32
  sizeof(long) * CHAR_BITS == 64

is prefectly comforming.

The main argument for a new type "long long" as I understood it in the
Newsgroup discussions was that there was just too much code out there
that relies on binary compatibility for the "long" type. A compiler that
wants binary compatibility *and* a 64 bits type must introduce a new
type.

One argument against was that the current standard guarantees that
"long" is the type with the largest range of them all. This makes code
like this legal and portable:

  size_t size = sizeof(someobject);
  fprintf( somefile, "%lu", (unsigned long) size );

with the guarantee that the cast will not truncate the value. The new
type can change this code without warning, because with a new type
size_t might be an alias for "long long" instead of maximally "long".
This was probably considered a rather obscure point by some. But than I
sometimes feel like portability issue often are about rather obscure
points, which is probably why they get missed so often.

I can only recommend to search the comp.std.c newsgroup for the topic in
Dejanews.


so long, benny
======================================
Benjamin Riefenstahl (benny@crocodial.de)
Crocodial Communications EntwicklungsGmbH
Ruhrstraße 61, D-22761 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Nicholas R LeRoy]

On Jul 21,  8:01am, Graham Murray wrote:
> Subject: long long vs long
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

Several reasons, actually.

Technically, it doesn't make sense, at least in the PC world, where
all processors are <=32bits.  Any 64-bit operation takes 2 separate
accesses and math, etc., becomes more complicated (and requires more
instructions and time).

Probably the more pervasive reason, however, is that there exists A
LOT of code out there which expects sizeof(long)==4.  It's sort-of an
un-official C standard.  In particular, legacy code dealing with
networking, etc., is frequently very loaded with such assumptions.
IIRC, the original CRAY C compiler used a 32-bit long and a 64-bit
int, just because so much code had this expectation.  IMHO: C should
have included standard data sizes, as well as it's generic types.  It
would have made many things a lot simpler.

Just my $.02 worth.

-Nick

-- 
+-------------------------------+--------------------------------------------+
| /`--_   Nicholas R LeRoy      | In a world without fences, Who needs Gates?|
|{     }/ Norland Corporation   |        ---- Experience Linux! ----         |
| \ *  / W6340 Hackbarth Rd     | http://www.linux.org | http://www.ssc.com  |
| |___| Fort Atkinson, WI 53538 +--------------------------------------------+
|      nick.leroy@norland.com   | #include <disclaimer.h>                    |
| http://www.norland.com/~nleroy | These are my own ideas, not my employer's. |
+----------------------------------------------------------------------------+
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hi Graham,

You wrote:

>This is probably a silly question, but rather than having long long for
>64 bit, why was long not made 64bit? The standard (AFAIK) states that
>short <= int <= long.  So, it should be possible for long to be 64 bit
>rather than 32. This would give a simple progression from 8bit chars to
>64bit longs.
No because the standard says
short == 16 bit
long  == 32 bit
int   == 16 or 32 depending on the machine's architecture

For example: Under DOS int is 16 bit while under Win32 und UN*X it is
32 bit.
So there's no way for long to be 64 bit while conforming to the
standard.

bye

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

Re: long long vs long

[Brian Osman]

Michael Weiser wrote:
> 
> No because the standard says
> short == 16 bit
> long  == 32 bit
> int   == 16 or 32 depending on the machine's architecture
> 
> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> 32 bit. So there's no way for long to be 64 bit while conforming to > the standard.
> 
> bye
> 
> Michael

Hmmm. I don't have a copy of the standard laying around, but I do have
Kernighan & Ritchite (2nd ed.) which says

Section 2.2:
...
Each compiler is free to choose appropriate sizes for its own hardware,
subject only to the restriction that shorts and ints are at least 16
bits, longs are at least 32 bits, and short is no longer than int, which
is no longer than long.
...

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

Re: long long vs long

[Michael Weiser]

Hello Brian,

You wrote:

>Each compiler is free to choose appropriate sizes for its own hardware,
>subject only to the restriction that shorts and ints are at least 16
>bits, longs are at least 32 bits, and short is no longer than int, which
>is no longer than long.
>...
I've already been intensively kicked for that mistake. ;)

Sorry...

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

Re: long long vs long

[Harry Broomhall]

Michael Weiser said:
> 
[SNIP]

> No because the standard says
> short == 16 bit
> long  == 32 bit
> int   == 16 or 32 depending on the machine's architecture
> 
> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> 32 bit.
> So there's no way for long to be 64 bit while conforming to the
> standard.

  Oh dear - this seems to be a common belief.  Can you give the
para in the standard where it says this?

  Regards,
      Harry.

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

Re: long long vs long

[Michael Weiser]

Hi Harry,

You wrote:

>> No because the standard says
>> short == 16 bit
>> long  == 32 bit
>> int   == 16 or 32 depending on the machine's architecture
>> 
>> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
>> 32 bit.
>> So there's no way for long to be 64 bit while conforming to the
>> standard.
>  Oh dear - this seems to be a common belief.  Can you give the
>para in the standard where it says this?
Unfortunately not. I didn't know that this matters so much.

BTW: Do you love splitting hairs? ;)

bye

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

Re: long long vs long

[Harry Broomhall]

Michael Weiser said:
> 
> Hi Harry,
> 
[SNIP]
> Unfortunately not. I didn't know that this matters so much.
> 
> BTW: Do you love splitting hairs? ;)

     No - but I *do* dislike wrong information!  <grin> And for
portable programming (which I have to do a lot of) you have to
be *very* clear on the rules.

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

Re: long long vs long

[Mumit Khan]

Long long vs long debate ...

Please take this elsewhere! There's comp.lang.c, which is a much better
forum than this mailing list.

I implore you to spare the rest of us from this inane discussion. Would 
be nice if some of the posters would bother opening up a standard C 
reference before posting.

Regards,
Mumit

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

Re: long long vs long

[sjm]

It was written:
 > Long long vs long debate ...
 > 
 > Please take this elsewhere! There's comp.lang.c, which is a much better
 > forum than this mailing list.
 > 
 > I implore you to spare the rest of us from this inane discussion. Would 
 > be nice if some of the posters would bother opening up a standard C 
 > reference before posting.

Suggestion: Add "Re: long long vs long" to your kill file or filter or
whatever you use. Alternatively consider deleting anything with that subject
without reading. I measured the time on my keyboard for deleting similar email
messages. Using vm under emacs I was able to delete in an average of .3
seconds per message if I did not bother to read the message. That's frankly
what I do with 95% of the traffic on this list. If it takes you longer I
suggest changing mailers. 

Also I have found that not reading mail makes it impossible to be annoyed by
the innanity of that mail because I cannot then tell if the mail is innane or
not. Fortunately I have never seen a mailer that forced me to read mail on an
uninteresting topic.

In other words I suggest you lighten up. This is a support group, not a
private list for insiders. Since gcc supports "long long" the argument could
be made that this is a vaguely on point topic. I could also make an arguement
based on its relatedness to portability. Less on point topics have been
discussed here without complaint.

As long as there is resistance to turning this list into a newsgroup where it
would be easier to split into subgroups then I have little sympathy for
complaints about off point discussion. Since this is the only forum for
discussing cygwin related stuff we shouldn't be too restrictive about how
closely related the discussion must be.

Steve Morris
sjm@judgement.com

PS. I agree that we have beaten this one nearly to death and will personally
be relieved when the topic finally dies out.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Christopher G. Faylor]

In article <9807261625.AA18550.cygnus.gnu-win32@frodo>,
sjm <sjm@judgement.com> wrote:
>
>It was written:
> > Long long vs long debate ...
> > 
> > Please take this elsewhere! There's comp.lang.c, which is a much better
> > forum than this mailing list.
> > 
> > I implore you to spare the rest of us from this inane discussion. Would 
> > be nice if some of the posters would bother opening up a standard C 
> > reference before posting.
>
>Suggestion: Add "Re: long long vs long" to your kill file or filter or
>whatever you use. Alternatively consider deleting anything with that subject
>without reading. I measured the time on my keyboard for deleting similar email
>messages. Using vm under emacs I was able to delete in an average of .3
>seconds per message if I did not bother to read the message. That's frankly
>what I do with 95% of the traffic on this list. If it takes you longer I
>suggest changing mailers. 

I agree with whoever posted this.  The "long long" topic has very little
to do with gnu-win32.  When a message thread starts moving outside of
the purpose of a mailing list, the polite thing to do is to move it
elsewhere.

>As long as there is resistance to turning this list into a newsgroup where it
>would be easier to split into subgroups then I have little sympathy for
>complaints about off point discussion. Since this is the only forum for
>discussing cygwin related stuff we shouldn't be too restrictive about how
>closely related the discussion must be.

Resistance?  Where is there resistance?  If you'd like to spearhead the
campaign to turn this into a newsgroup, please feel free to do so.

The fact that this is not a newsgroup is one more reason why off-topic
threads such as this one should be squashed.  Some people who are
subscribed to the gnu-win32 mailing list are actually paying for their
connections.  There's no reason for such people to pay for "long long"
discussions.
-- 
cgf@cygnus.com             "Everything has a boolean value, if you stand
http://www.cygnus.com/      far enough away from it."  -- Galena Alyson Canada
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hi Harry,

You wrote:

>[SNIP]
>> Unfortunately not. I didn't know that this matters so much.
>> 
>> BTW: Do you love splitting hairs? ;)
>
>     No - but I *do* dislike wrong information!  <grin> And for
>portable programming (which I have to do a lot of) you have to
>be *very* clear on the rules.
Okay, got me. As I've never seen a system that uses longs with more or
less than 32 bits I simply thought that it's pretty useless to argue
about whether the standard says this or that when nearly all code
relys on that fact. But after reading this thread on the list it seems
to me that there are even a lot systems with incredibly long longs and
so I now think you're right. ;)

Yours

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

Re: long long vs long

[Timothy Writer]

michael@weiser.saale-net.de (Michael Weiser) writes:

> Hi Harry,
> 
> You wrote:
> 
> >> No because the standard says
> >> short == 16 bit
> >> long  == 32 bit
> >> int   == 16 or 32 depending on the machine's architecture
> >> 
> >> For example: Under DOS int is 16 bit while under Win32 und UN*X it is
> >> 32 bit.
> >> So there's no way for long to be 64 bit while conforming to the
> >> standard.
> >  Oh dear - this seems to be a common belief.  Can you give the
> >para in the standard where it says this?
> Unfortunately not. I didn't know that this matters so much.
> 
> BTW: Do you love splitting hairs? ;)

In defense of the original poster, this is not splitting hairs.  You yourself 
invoked the _Standard_ to assert:

    1.  short is 16 bits and long is 32 bits
    2.  a conforming implementation cannot use a 64 bit long

Both statements are incorrect and such commonly held misbeliefs are a
frequent source of portability problems.  Since this group is very much about
portability, its important not to spread misinformation where portability is
concerned.

BTW, I'm not speaking from an "Ivory tower".  I recently had the job of
porting an application from NT to Digital UNIX with, you guessed it, 64 bit
longs.  The code is full of assumptions that a short is exactly 16 bits and a
long is exactly 32 bits.  Furthermore, the programmers never use int because
they don't know its size.  Needless to say the port was costly.  So, you see,
such distinctions do matter.

-- 
Tim Writer                                              Tim.Writer@ftlsol.com
FTL Solutions Inc.
Toronto, Ontario, CANADA
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: long long vs long

[Michael Weiser]

Hello Timothy,

You wrote:

[SNIP]
>> Unfortunately not. I didn't know that this matters so much.
>> 
>> BTW: Do you love splitting hairs? ;)
>
>In defense of the original poster, this is not splitting hairs.  You yourself 
>invoked the _Standard_ to assert:
>
>    1.  short is 16 bits and long is 32 bits
>    2.  a conforming implementation cannot use a 64 bit long
>
>Both statements are incorrect and such commonly held misbeliefs are a
>frequent source of portability problems.  Since this group is very much about
>portability, its important not to spread misinformation where portability is
>concerned.
Okay okay, I said Jehova and now everyone is throwing stones at me. ;)


I now know that my statement about the standard was thoughtless,
sorry. In my little world I thought that longs are 32 bits and that
almost all code relys on this. I simply didn't know about the world
around my little universe. :)

So sorry and till the next mindless mistake...

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

Re: long long vs long

[massimo morara]

Can be useful (I hope so)

http://www.UNIX-systems.org/version2/whatsnew/login_64bit.html


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

Re: long long vs long

[Andrew Sharp]

Graham Murray wrote:
> 
> This is probably a silly question, but rather than having long long for
> 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> short <= int <= long.  So, it should be possible for long to be 64 bit
> rather than 32. This would give a simple progression from 8bit chars to
> 64bit longs.

You're right, it is a silly question.  ~:^)  I did a lot of 64bit unix
kernel porting work a few years back, and the reason that something
other than 'long' had to be used is that there is about 6 trillion lines
of C code in the world that would seriously break if long's suddenly
became 64 bits, because coders have been using 'long' for more than a
decade with the belief that they are the same size as 'int'.  Avoiding
the discussion of why they didn't use 'int' all those times, suffice it
to say that a new type was created for the sake of expediency.  Everyone
who has written code that might require some fixin' if long's changed to
64 bits, raise your hand.

The irony is that types like 'long long' are usually accomplished in
some basic header, not as a base compiler type.  The base compiler 64bit
types are almost always of the form '_int64' or some such.  It seems we
just can't ever separate int's and long's!

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

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Earnie Boyd]

>From: Scott Blachowicz <sab@seanet.com>
>Date: 06 Jan 1998 11:25:43 -0800
>
[snip]
>So, why IS it that the coolview code requires text=binary mode mounts
>anyways?

Let me remind you that the purpose of the cygnus gnu-win32 project is to 
port UNIX code.  Most of the UNIX world programs choke on the \r\n 
combination.  Therefore text=binary is the easiest solution.

>-- 
>Scott Blachowicz                <sab@seanet.com>


-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------

Check out these great gnu-win32 related sites:
ftp://ftp.cygnus.com/pub/gnu-win32/latest/           (ftp site)
http://www.cygnus.com/pubs/gnupro/                   (Comercial Page)
http://www.cygnus.com/misc/gnu-win32/                (Project Page)
http://www.cygnus.com/ml/gnu-win32                   (Mail Archives)
http://www.itribe.net/virtunix/winhelp-man-pages/    (HTML Man Pages)
http://www.lexa.ru/sos                               (Sergey Okhapkin)
ftp://www.lexa.ru/pub/domestic/sos/                (Sergey's ftp site)
http://www.fu.is.saga-u.ac.jp/~colin/gcc.html        (Colin Peters)
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ (Mumit Khan)
http://gnu-win32.paranoia.ru                         (Chuck Bogorad)
ftp://ftp.deninc.com/pub                       (Den Internet Services)


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Scott Blachowicz]

"Earnie Boyd" <earnie_boyd@hotmail.com> writes:

> Let me remind you that the purpose of the cygnus gnu-win32 project is to 
> port UNIX code.  Most of the UNIX world programs choke on the \r\n 
> combination.  Therefore text=binary is the easiest solution.

Yes, I realize that.  But it seems like there are some concessions being
made to the folks who claim that the tools ought to interoperate more
easily with the DOS tools (e.g. accepting file paths like "c:/windows").
So, I keep hoping that someone will come up with some clever scheme to do
away with this text=binary mount stuff (which seems to be one of the most
awkward things about trying to use the gnu-win32 stuff).

I keep hoping to be able to find some affordable (read: negligible
monitary cost :-)) alternative to MKS sh (or whatever) to give me a Unix
toolset that can interoperate with the Windows developers and development
tools that I need to.
-- 
Scott Blachowicz                <sab@seanet.com>

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

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Fergus Henderson]

On 07-Jan-1998, Earnie Boyd <earnie_boyd@hotmail.com> wrote:
> From: Scott Blachowicz <sab@seanet.com>
> >So, why IS it that the coolview code requires text=binary mode mounts
> >anyways?
> 
> Let me remind you that the purpose of the cygnus gnu-win32 project is to 
> port UNIX code.  Most of the UNIX world programs choke on the \r\n 
> combination.  Therefore text=binary is the easiest solution.

I think you misspelt "work-around".

-- 
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Jeffrey C. Fried]

Porting code from Unix to the PC should NOT require the same line
termination mode since most Unix code which reads text uses fread/getc
which automatically handle the end-of-line.  And from the replies of most
people i would argue that most of us would prefer to work in the native
mode of the operating system in which we are running rather than having to
constantly convert files between the two models simply because we use tools
from both operating systems under NT/95.  For examples of this
compatibility look at many of the GNU tools which handle text, the file
handling will work under both operating systems without any change because
they use text mode I/O which is platform independent once all files have
been converted to the form of the native OS.

... jeff

At 05:28 AM 1/7/98 PST, Earnie Boyd wrote:
>>From: Scott Blachowicz <sab@seanet.com>
>>Date: 06 Jan 1998 11:25:43 -0800
>>
>[snip]
>>So, why IS it that the coolview code requires text=binary mode mounts
>>anyways?
>
>Let me remind you that the purpose of the cygnus gnu-win32 project is to 
>port UNIX code.  Most of the UNIX world programs choke on the \r\n 
>combination.  Therefore text=binary is the easiest solution.
>
>>-- 
>>Scott Blachowicz                <sab@seanet.com>
>
>
>-        \\||//
>---o0O0--Earnie--0O0o----
>-earnie_boyd@hotmail.com-
>------ooo0O--O0ooo-------
>
>Check out these great gnu-win32 related sites:
> ftp://ftp.cygnus.com/pub/gnu-win32/latest/           (ftp site)
> http://www.cygnus.com/pubs/gnupro/                   (Comercial Page)
> http://www.cygnus.com/misc/gnu-win32/                (Project Page)
> http://www.cygnus.com/ml/gnu-win32                   (Mail Archives)
> http://www.itribe.net/virtunix/winhelp-man-pages/    (HTML Man Pages)
> http://www.lexa.ru/sos                               (Sergey Okhapkin)
> ftp://www.lexa.ru/pub/domestic/sos/                (Sergey's ftp site)
> http://www.fu.is.saga-u.ac.jp/~colin/gcc.html        (Colin Peters)
> http://www.xraylith.wisc.edu/~khan/software/gnu-win32/ (Mumit Khan)
> http://gnu-win32.paranoia.ru                         (Chuck Bogorad)
> ftp://ftp.deninc.com/pub                       (Den Internet Services)
>
>
>______________________________________________________
>Get Your Private, Free Email at http://www.hotmail.com
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>
>
--
Jeffrey C. Fried      jcfried@ix.netcom.com

   Because a liar tells the truth does not mean the truth is a lie.

NOTICE: I charge $500.00 for each unsolicited advertisement i receive as email
to cover the cost of my time to review and possibly respond to your
advertisement.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Scott Blachowicz]

"Jeffrey C. Fried" <jcfried@ix.netcom.com> writes:

> from both operating systems under NT/95.  For examples of this
> compatibility look at many of the GNU tools which handle text, the file
> handling will work under both operating systems without any change because
> they use text mode I/O which is platform independent once all files have
> been converted to the form of the native OS.

A problem is that the open() call in MS-land has a binary/text mode flag,
but Unix open() calls generally don't (since there is typically no
binary/text mode distinction made).  So, you always end up having
problems with porting arbitrary Unix code over to MS-land when the Unix
code calls open() without specifying a mode AND the default mode doesn't
match what the Unix code was expecting.

Part of the problem with specifying the default text file type on a
per-mount basis is that it frequently isn't the right basis for specifying
it.  I may have mounts where I want both style of line termination - maybe
it's more related to what kind of file I'm writing.  Using the mount point
is kind of a best guess heuristic, I guess.  What we need is omniscent
software that just knows what I want and does it :-)).

Maybe it'd be nice of the mount mode were irrelevant when reading an
existing file, but just controlled what happens when you write a file to
the file system.  Maybe the reading operations could track what kind of
line termination is being used on a file, then succeeding write operations
could use the same style (unless overridden by the open() flags)?  That
sounds weird...and probably unworkable...just food for thought.

How do the MS-land programs that understand both line terminations work?
They probably just accept either on input, then do \r\n on output, right?

Oh, Idunno...
-- 
Scott Blachowicz                <sab@seanet.com>

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

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Larry Hall (RFK Partners Inc)]

At 10:34 AM 1/8/98 -0800, you wrote:
>Maybe the reading operations could track what kind of
>line termination is being used on a file, then succeeding write operations
>could use the same style (unless overridden by the open() flags)?  That
>sounds weird...and probably unworkable...just food for thought.

Not necessarily.  Various programs do this, including vim and, I think, NTEmacs.

>How do the MS-land programs that understand both line terminations work?
>They probably just accept either on input, then do \r\n on output, right?

Precisely.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                             
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Scott Blachowicz]

> >Maybe the reading operations could track what kind of
> >line termination is being used on a file, then succeeding write operations
> >could use the same style (unless overridden by the open() flags)?  That
> >sounds weird...and probably unworkable...just food for thought.
> 
> Not necessarily.  Various programs do this, including vim and, I think, NTEmacs.

Yes, NTEmacs does, but I was trying to think of the difficulties involved
in doing a filter program.  It'd be nice if the line termination for the
output file could somehow match its input file....so either the filter
program would have to use the right fopen() flags to designate the right
kind of text output file or the fopen() could intuit the right value by
looking at recent open()/read()'s...that's what I meant by
"weird"/"unworkable".
-- 
Scott Blachowicz                <sab@seanet.com>

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

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTEmacs)

[Benjamin Riefenstahl]

Scott Blachowicz wrote:
> > >Maybe the reading operations could track what kind of
> > >line termination is being used on a file, then succeeding write operations
> > >could use the same style (unless overridden by the open() flags)?  That
> > >sounds weird...and probably unworkable...just food for thought.

That would be nice, but not necessary for my purposes. I would be
content if all tools that do text would understand all ASCII text file
input. If that was garanteed for all tools than their output format
could be an arbitrary choice (any one of Unix, DOS, Mac).

OTOH given that I do not have source for some of my tools (esp the OS
supplied), I prefer the output in the native format i.e. DOS. Actually,
thinking about it, I'd say that I would even prefer output in DOS format
over preserving the old format.
======================================
Benjamin Riefenstahl (benny@crocodial.de)
Crocodial Communications EntwicklungsGmbH
Ophagen 16a, D-20257 Hamburg, Germany
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTE

[Michael Hirmke]

Larry Hall (RFK Partners Inc) [lhall@rfk.com] wrote:

[...]
>Not necessarily.  Various programs do this, including vim and, I think,
>NTEmacs. 
>
>>How do the MS-land programs that understand both line terminations work?
>>They probably just accept either on input, then do \r\n on output, right?
>
>Precisely.

Nope, vim for example reads files in "textmode" or "notextmode" and
also writes them in the same manner. This is true for the Cygnus
compiled vim and for the VC++ compiled one under Windows.
Otherwise you would destroy all your Unix style line breaks, when
reading and writing a file with it.

>
>
>Larry Hall                              lhall@rfk.com

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://minimike.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Why text=binary mounts (Re: Gnu-win32 (b18), coolview and NTE

[Larry Hall]

Michael Hirmke wrote:
> 
> Larry Hall (RFK Partners Inc) [lhall@rfk.com] wrote:
> 
> [...]
> >Not necessarily.  Various programs do this, including vim and, I think,
> >NTEmacs.
> >
> >>How do the MS-land programs that understand both line terminations work?
> >>They probably just accept either on input, then do \r\n on output, right?
> >
> >Precisely.
> 
> Nope, vim for example reads files in "textmode" or "notextmode" and
> also writes them in the same manner. This is true for the Cygnus
> compiled vim and for the VC++ compiled one under Windows.
> Otherwise you would destroy all your Unix style line breaks, when
> reading and writing a file with it.
> 
> >
> >
> >Larry Hall                              lhall@rfk.com
> 
> Bye.
> Michael.
> --
> Michael Hirmke           | Telefon +49 (911) 557999
> Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
> 90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
>                          | WWW     http://minimike.franken.de/
> -
> For help on using this list (especially unsubscribing), send a message to
> "gnu-win32-request@cygnus.com" with one line of text: "help".

Michael,

This is taken out of context.  vim works as you describe however I
was not insinuating that vim worked as "MS-land" programs.  I was 
considering the original poster's definition of "MS-land" programs
as native Win32 programs and not ports of software to this platform
or others.  If anyone else got the impression I meant otherwise, 
please accept my apologies.


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